欢迎到
继IP电话后，IP视频业务已成为运营商必争之地。
然而，要想实现运营级的IP视频业务，传统的IP协议是无法胜任的。
为了实现运营级的视频业务，IP协议必须改进！
在IP网上实现视频传输，除了需要解决宽带接入问题和研制更有效的压缩算法外，对传统IP协议的改进必不可少。在这些改进中，IP QoS和IP组播是最重要的两个部分。
传统IP：承载视频很困难
在早期，IP网络只跑数据业务（比如www或者E-mail）时，这种处理方式是适用的。但当IP网络上传输的报文不再仅仅是数据业务，还包括了对实时性要求很高的语音和视频时，就需要IP协议能够对不同报文做不同的对待，就此引入QoS。
另外，传统的IP通信是在一个源IP主机和一个目标IP主机之间（单播）或者一个源IP主机和网络中所有的IP主机之间（广播）进行的。在视频广播应用中，要将信息发送给网络中的多个而非所有IP主机。在传统IP协议里，要么采用广播方式，要么由源IP主机分别向网络中的多个目标IP主机发送IP包。前一种方式不仅会将信息发送给不需要的IP主机而浪费带宽，也可能由于路由回环引起一场严重的广播风暴；而后一种方式由于IP包的重复发送而白白浪费掉大量带宽，也增加了服务器的负载。可以说传统的IP通信技术不能有效地解决单点发送多点接收的问题。
QoS：为视频传输保驾护航
在传统的IP网络中，所有的报文都无区地的等同对待，每个路由器对所有的报文采用先入先出的策略（FIFO）处理，它尽最大的努力（Best-Effort）将报文送到目的地，见图1。
为了实现QoS，需要改变传统IP网络的FIFO队列传输报文机制，转而采用优先级队列（Priority Queueing, PQ）机制，见图2。
PQ机制对报文进行分类，将所有报文分成最多至4类，分别属于PQ的4个队列中的一个。然后，按报文的类别将报文送入相应的队列。PQ的4个队列分别为高优先队列、中优先队列、正常优先队列和低优先队列，它们的优先级依次降低。在报文出队的时候，PQ首先让高优先级队列中的报文出队并发送，直到高优先队列中的报文发送完，然后发送中优先队列中的报文。同样，直到发送完，然后是正常优先队列和低优先队列。这样，分类时属于较高优先级队列的报文将会得到优先发送，而较低优先级的报文将会在发生拥塞时被较高优先级的报文抢先。使得实时业务（如Video）的报文能够得到优先处理，非实时业务（如E-mail）的报文在网络处理完实时业务后的空闲中得到处理。既保证了实时业务的优先，又充分利用了网络资源。
当前的IP协议能够支持三种QoS模型。
Best-Effort是一个单一的服务模型，也是最简单的服务模型。应用程序可以在任何时候，发出任意数量的报文，而且不需要事先获得批准，也不需要通知网络。对Best-Effort服务，网络尽最大的努力来发送报文，但对时延、可靠性等性能不提供任何保证。 Best-Effort服务是现在Internet的缺省服务模型，它适用于绝大多数网络应用，如FTP、E-mail等，它通过先入先出（FIFO）队列来实现。
Intserv是一个综合服务模型，它可以满足多种QoS需求。这种服务模型在发送报文前，需要向网络申请特定的服务。这个请求是通过信令（Signal）来完成的。传送QoS请求的信令是RSVP（资源预留协议），它将应用程序的QoS需求通知给路由器。应用程序首先通知网络它自己的流量参数和需要的特定服务质量请求，包括带宽、时延等。应用程序一般在收到网络的确认信息，即网络已经为这个应用程序的报文预留了资源后，发送报文。而应用程序发出的报文应该控制在流量参数描述的范围内。
网络在收到应用程序的资源请求后，执行资源分配检查（Admission Control），即基于应用程序的资源申请和网络现有的资源情况，判断是否为应用程序分配资源。一旦网络确认已经为应用程序的报文分配了资源，则只要应用程序的报文被控制在流量参数描述的范围内，网络就会承诺满足应用程序的QoS需求。而网络将为每个流（Flow，由两端的IP地址、端口号、协议号确定）维护一个状态，并基于这个状态执行报文的分类、流量监管（Policing）、排队及其调度，来满足对应用程序的承诺。
Diffserv是一个多服务模型，它可以满足不同的QoS需求。与Intserv不同，它不需要信令，即应用程序在发出报文前，不需要通知路由器。对Diffserv，网络不需要为每个流维护状态，它根据每个报文指定的QoS，来提供特定的服务。可以用不同的方法来指定报文的QoS，如IP包的优先级位（IP Precedence)、报文的源地址和目的地址等。网络通过这些信息来进行报文的分类、流量整形、流量监管和排队。
通常在配置Diffserv时，边界路由器通过报文的源地址和目的地址等对报文进行分类，对不同的报文设置不同的IP优先级，而其他路由器则只需要用IP优先级位来进行报文的分类。
IP组播：使视频广播成为可能
IP组播技术允许源IP主机将IP信息包发送到IP网络上的任意一组目标主机上，可以有效地解决单点发送多点接收、多点发送多点接收的问题。在实际使用IP组播技术时，首先需要定义一个组播地址（Group Address），每个组播地址代表源IP主机与目的IP主机之间的一个会话（Session）。目的IP主机可以使用组播地址告诉路由器，该主机希望加入或退出那一个组播组，IP组播协议能初始化或终止从源IP主机到该目标IP主机的数据流。然后，源IP主机就可以使用组播地址发送分组。源IP主机可以不知道任何有关目的IP主机的信息，如IP目标主机在什么位置等，它只要知道组播地址即可。
由于组播地址资源非常有限，控制组播地址分配的IANA倾向于为特定网络协议的使用确定单独的IP组播地址，也就是说剩余的IP组播地址是以动态的、合作的方式被整个网络使用。组播应用要求有一个地址管理服务机制来管理和分配组播地址。目前组播应用有三种方法可以获得组播地址，包括硬编地址、声明地址、以及计算推导等等。
IP组播在实际应用中需要解决由于不同目的主机所处不同网络环境而带来的问题。因特网是由许多网络连接起来构成的一个世界范围的大型网络，而构成因特网的许多局部网络之间，在数据传输速度、稳定性、可靠性等方面存在巨大的差异，同时因特网中发生拥塞的时间、地点也是随机的、不可预测的。IP组播应用应能适应这样不同的网络环境，提供用户满意的组播服务。
当网络不能满足现有的数据发送速率时，单播应用可以使用传送层的TCP协议来自动调节数据发送速率（尽管较低的数据发送速度可能不满足CBR需求），或者在应用层使用回馈循环机制来调节数据本身（如改变数据的分辨率、使用有损压缩技术等）以达到降低数据发送速率的目的。而IP组播应用有多个目的主机，上述方法显然不能照搬。首先不管是TCP协议还是回馈循环机制都要求目的主机向源主机汇报接收情况（如：数据丢失、传送错误等），如果许多目的主机同时向发送者发出数据丢失报告，源主机很可能被一场严重的“应答报文风暴”淹没。同时一个组播组中，不同的目的主机其网络带宽和接收能力有很大的差异，如果发送者按照最低接收能力目的主机的要求来调节发送速度，那么它只能提供较差的服务。为解决上述问题，人们提出了许多方法来支持异种目的主机，其中比较著名的有应答报文抑制机制（如果一个接收者发现报文错误或丢失，它并不立即向发送者发送应答报文，而是等待一个随机时间，在这段时间内如果监听到别的接收者向发送者发送报文出错应答，就不再发送应答报文，否则该接收者向发送者发送报文出错应答），和设立托管节点机制（将网络中的部分目的主机设计成局部托管节点，作为源主机和本局部网络所有目 的主机之间的桥梁和中转站。托管结点可以对出错的报文进行重发，也可以对源主机发来的组播包进行重新编码，以降低数据传送速率，还可以向源主机发送应答报文）。