《ipv6对实时通信和流传输的支持》由会员分享，可在线阅读，更多相关《ipv6对实时通信和流传输的支持（75页珍藏版）》请在金锄头文库上搜索。
1、2019/2/20,1,第4单元 IPv6对实时通信和流传输的支持,2019/2/20,2,第4单元 IPv6对实时通信和流传输的支持,4.1 定义和概念 4.1.1 定义流标记和优先级 4.1.2 流和策略路由 4.1.3 流不是虚电路 4.2 支持预留 4.2.1 特别的服务 4.2.2 使用RSVP和流 4.2.3 使用逐跳选项,2019/2/20,3,第4单元 IPv6对实时通信和流传输的支持,4.3 等级式编码和优先级 4.3.1 等级式传输 4.3.2 大的组播组不需要优先级 4.3.3 源相对优先级可能引发拥塞 4.3.4 自适应的应用 4.3.5 监察网络使用 4.3.6 修改
2、优先级域 4.4 实时传输协议 4.5 资源预留协议,2019/2/20,4,第4单元 IPv6对实时通信和流传输的支持,作为下一代IP协议的提案之一的SIP（简单IP协议）最初假定维持64位的边界。最早的版本包含两个64位地址，分别用于源和目的地，还有一些诸如分组长度、载荷类型和跳段计数这样的辅助域。然而这些辅助域不需要64位这么长，结果剩下32位未用。当时征求各种专家的意见，如何最佳地使用这些位。一些人建议插入一个检验和，另一些人则希望有更长的长度域或跳段计数域。然而最有说服力的需求是流标识符，可用以标识实时流，通过某种预留协议分配资源和优先级。如果我们要在Internet上提供高质量的多
3、媒体通信，就需要对流做适当的处理。SIP的设计者采纳了这一建议。经过两年多的讨论和提炼，结果产生了对IPv6流标记和优先级类别的定义。,2019/2/20,5,4.1 定义和概念,IPv6规范对流进行了定义。定义在措词上很小心，避免隐含任何具体的特征。“流是从一个特定的源发往一个特定的（单播或组播）目的地的一个分组序列；对于这些分组，源请求中间的路由器做特别的处理。”事实上，流的定义隐含地来自对流标记本身的定义。流是来自同一个源前往同一目的地且具有相同流标记的分组的集合。,2019/2/20,6,4.1.1 定义流标记和优先级,我们把组成一个流的一系列分组用20位的流标记标识。没有必要让Int
4、ernet上的所有分组都属于流。事实上很有可能在过渡阶段大多数分组都不会明确地标记属于流。数据由诸如SMTP邮件程序、FTP文件传送程序或HTTP Web浏览器这样的经典应用产生。这些应用程序是为IPv4设计的，将被升级既能处理IPv4地址，也能处理IPv6地址，但可能不会被修改加入IPv4不支持的流处理过程。对应的分组将使用由20个0位组成的零流标记。 当传输要求某种特别的处理时，例如对于具有严格的实时限制条件的应用，将使用流标记。,2019/2/20,7,4.1.2 流和策略路由,流标记可以结合路由选择头一起使用。事实上，明确地采用源路由通过相同的一组中继器的所有分组需要特别的处理。这并不
5、意味着经过相同的源路由的所有分组属于同一个应用：它们可能属于不同的视频流，或者属于混合的音频、视频和数据流。,2019/2/20,8,4.1.2 流和策略路由,多媒体通信可能持续相当长的时间。在此期间源路由选择的需求可能改变。在一天内的某些时段，该单位的第二个连接提供商可能给出比其主要提供商更好的价格。想要利用这种价格优惠的客户，比如说，可以在下午1点之前使用标准的路由选择，然后插入一个路由选择头，在下午1点至2点之间强行使用第二种路由。从应用的角度看问题，这些分组一直属于同一个流。但是IPv6规范明确指出，如果源路由选择改变了路由，流标记也必须改变。在我们的例子中，在下午1点至2点之间传送的
6、分组的流标记跟1点之前或2点之后传送的分组不同。,2019/2/20,9,4.1.3 流不是虚电路,IPv6的流不同于X.25或ATM中的虚电路。IPv6分组的路由选择仅受对目的地址的选择的影响，或者受在分组中插入的路由选择头的影响。加流标记不会对路由选择有任何影响。 建议在IPv6基本头中加上流标记的大多数专家在头脑中都有资源预留的想法。他们注意到，传统的分组交换不支持诸如话音或视频传输这样的严格的实时应用。他们认为，资源预留是对基本的分组交换的必要增强。,2019/2/20,10,4.2 支持预留,以传统的数字电话为例，模拟话音信号以8kHz的速率采样，每个样本使用8个二进制位数字化，结果
7、产生64kbps的数据流。这个信号可以作为相继的分组在Internet上传送。诸如vat这样的流行程序把这个数据流分组化，典型的分组包装160个样本，代表20毫秒的话音。它们通过Internet每秒发送50个分组。如果传输是合理地稳定，那么接收方可以解包话音样本，并回放没有失真的话音信号。但是，当网络拥塞时，话音质量会降低。某些分组会经历长的队列。这将产生很长的播放延迟，降低通信的交互性。还有一些分组会丢失，这将产生噼啪声。,2019/2/20,11,4.2 支持预留,延迟和噼啪声的缘由是分组交换的传统调度策略。这种调度先来先服务，就像在银行办理业务需要排队那样。预留过程旨在为某种特别标识的分
8、组建立一个特别的行道。人们相信，在分组交换机上可以实施特别的调度策略来保证分组的稳定流动。IETF制定了一个资源预留协议，称作RSVP。IPv6流标记可以跟这个协议结合使用。,2019/2/20,12,4.2.1 特别的服务,传统的分组交换机并不想跟分组队列混在一起。当有一个分组到达时，它被传递给路由选择模块，该模块检查其目的地址，确定外出线路。如果该线路可用，分组就被立即传输。否则，就把分组放在队列中，等待以后传输。这种策略叫做先到先服务。在每个外出线路的前面都有单个队列。,2019/2/20,13,4.2.1 特别的服务,2019/2/20,14,4.2.1 特别的服务,然而，这种传统做法
9、并非强制性的。代替每个外出接口仅一个队列的做法，交换机可以把分组分类。例如，它们可以给与实时分组队列比数据分组队列要大的优先级。但是仅此还不够。如果我们需要实时保证，我们必须保证每秒发送50个分组的队列每秒能够被访问50次。使用队列理论的术语，我们必须保证，一个队列的服务速率等于或高于其到达速率。达到这一目标的一个方法是让每个实时通信有一个队列，并且还有一个用于所有数据分组的缺省队列。,2019/2/20,15,4.2.1 特别的服务,2019/2/20,16,4.2.1 特别的服务,例如有4个实时流。可以把流标记跟源地址结合在一起使用，表明哪个分组属于哪个流。在缺省条件下，没有被识别为一个实
10、时流的一部分的分组划归缺省的数据队列。使用预留过程宣告实时流，并把它们的需求通知路由器。每个实时流将以符合它们的需求的速率被服务。实时数据流将不会遭遇不可预料的队列延迟，也将不会经历拥塞。而在另一方面，数据队列仅得到尽力而为的服务。作为给实时流预留传输资源的结果，数据传输仅得到剩余带宽和处理能力。它将经历比较长的延迟和比较频繁的拥塞。,2019/2/20,17,4.2.2 使用RSVP和流,在Internet中选择的预留协议叫做RSVP。RSVP的主要假定是诸如高速视频传输这样的组播应用最需要资源预留。这些应用有某些独特的特性，比如说，大量的接收方可能对应不同的传输条件，它们还可能属于不同的域
11、。结果RSVP是一个由接收方驱动的协议。它由接收方决定选择它们希望接收的哪一个源，以及它们想要预留多少带宽并为之付费。它们通过向网络发送RSVP报文来做这类选择。源通过沿着常规的数据报文的通路定期地发送PATH报文使得预留成为可能。通过这些PATH报文，Internet路由器获悉正在进行的通信的情况。 RSVP报文将在由PATH报文标记的反向通路上传播，从而保证资源是在用以传播数据的正确的链路上预留。,2019/2/20,18,4.2.2 使用RSVP和流,典型的RSVP报文会说明接收方要倾听的源地址，数据发往的组播组地址和一些服务质量参数（例如要保留的数据速率）。它还会包含一个过滤描述，描述
12、接收方要选择的数据的框架文件。例如，在A和B之间同时进行文件传送和音频会话。此时，希望为音频预留64kbps的带宽，但肯定不希望看到文件传送竞争使用那个预留带宽从而破坏声音的质量。这就是过滤描述要达到的目的。,2019/2/20,19,4.2.2 使用RSVP和流,在IPv4中描述过滤器需要考虑层次差异的问题，涉及到分层原则的违犯，即在网络层的工作调用更高层的参数。在我们的例子中，文件传送使用TCP，音频使用UDP。但是仅仅对协议类型进行过滤是不够的，因为可能同时存在多个UDP和TCP应用。我们在描述过滤的工作中需要使用TCP和UDP端口。,2019/2/20,20,4.2.2 使用RSVP和
13、流,其实，层次违犯并非主要的过失。许多网络设计人员对于用UDP端口补充描述他们的源和目的地址的效果非常满意。但是对于IPv6，端口号深埋在分组内部，位于长的扩展头菊花链之后。这会使得过滤编码非常低效。更糟的是，如果分组是加密的，端口号根本不可见。这就是可以让IPv6流标记起作用的地方。代替对端口号的指定，接收方在他的过滤器中叙述它要给以特权的特定的流标记。这一信息呈现在分组的靠前部位，并且易于访问，使得分类过程易于实现。 必须指出，RSVP并非IPv6可以实现的惟一的预留过程。一些研究人员相信他们可以用逐跳选项的形式定义一个给定流的服务质量需求。这个选项将在一些分组中传送。路由器会记住相关的参
14、数，并把它们跟该流相关联。,2019/2/20,21,4.3 等级式编码和优先级,发送方应该总是试图从可提供的容量得到最好的服务质量。诸如TCP慢启动这样的算法正是为正常的数据传送做这样的事情。它们保持管道几乎一直是充满的，同时避免由太频繁的丢失引起的TCP效率的降低。它们可以尝试评估可提供的容量，然后调整样本速率和压缩比率，使得依然保持在那个容量之内。但是至少有两种情况使得这种适配不能够有效地执行： （1）应用程序发现可提供的容量需要花一些时间。如果网络状态改变的速度比适配期还要快，那么我们会看到循环，短暂的拥塞和分组丢失。 （2）通向大的组播组的不同成员的通路可能具有不同的容量，仅当适配成
15、这些容量中的最低值时才能保证不会丢失分组，在实践中这会导致可能的最坏服务。,2019/2/20,22,4.3 等级式编码和优先级,对于这个问题业已提出的解决方案是结合两种技术：等级式编码和相对优先级。相应地，初始IPv6规范用如下描述定义了一个优先级域：“在IPv6头中的4位优先级域使得一个源能够标识它的分组相对于发自同一源的其它分组的投递优先级。” 其思想是多媒体源要发送标有不同优先级的多个分组。在拥塞的情况下，中间的路由器会自动丢弃那些标着较低优先级的分组，使得接收方在当前的网络条件下总能得到可能的最好的接收。 后来的研究表明，对大的组播组的等级式传输可以不使用网络级优先级来实现，并且那样
16、的优先级丢弃会使得实现起来比较困难。现在的优先级域处于修改状态，并从源相对优先级转向网络全局优先级。,2019/2/20,23,4.3.1 等级式传输,假定我们要发送一个声音信号。声音用高保真的麦克风捕获并且以16位精度44kHz频率采样。我们可以把传输组织成等级式分组： *一个基本分组，包含以5.5kHz做的信号子采样 *一个补充分组，包含以5.5kHz和11kHz采样之间 的差值。 *两个更多的分组，包含在11kHz和22kHz采样之 间的差值。 *四个分组，包含在22kHz和完全精度的44kHz采样之间的 差值。,2019/2/20,24,4.3.1 等级式传输,如果我们使用源相关的优先级，每个分组将有一个不同的优先级编码，因此，如果链路拥塞，44kHz分组被首先丢弃，然后是22kHz分组，再往后是11kHz。通过这种方式，我们保证： *即使网络很快地改变其状态，该用户的带宽份额 将总是被比较重要的数据占用。 *即使一个组播组的成员有非常不同的容量，它们 也将都得到适配其本地通路的最好的服务质量。,2019/2/20,25,4.3.1 等级式传输,简言之，等级式编码使得应用程
