RSVP 协议和资源预留

6.3.1综合服务Internet

        第二章已述及，Internet是一个无连接网络，只提供一种承载业务：尽力传送(besteffort)业务。也就是说，网络并不保证向应用数据流提供所需的带宽，也不保证数据流的传送时延和丢失率等质量指标。对于FTP数据等非实时业务，尽力传送能够满足要求，但是对于音频或视频等实时通信应用，网络必须能支持具有一定QoS的端到端承载业务。为此，可有下述两种方法。

       一种是超量工程法(overengineering)，即在网络规划时预留足够的带宽，使得任何时候都能获得可接受的QoS。这种方法十分简单，不需要资源预留协议和接纳控制功能，但是要求部署足够多的路由 器和高速链路，保证即使在忙时网络资源也有足够的余最。它可用于网络资源便宜同时网络最大业务屈又可预测的情况。

       另一种方法就是综合服务Internet 方法，由IETF 综合服务(intserv)工作组定义。它需定义呼叫接纳控制功能和资源预留协议，如RSVP。利用RSVP消息，端点应用程序可以提出数据传送全程必须保留的网络资源（如带宽、缓冲区大小等），同时也确定了沿途各路由器的传输调度策略，藉此，可以对每个数据流的QoS逐个进行控制。不难看出，上述概念和面向连接的呼叫连接建立过程相似，RSVP类似于连接控制信令，因此，常称RSVP是Internet中的信令协议。

       为了支持不同特性的应用，必须对其QoS 进行分类。IETF提出了多种不同等级的QoS服务类型，包括：承诺速率服务、保护式尽力传送服务、QoS确保服务和负荷受控服务，目前只有后两种服务在网上真正实现。QoS确保服务必须确保数据流的可用带宽，保证其达到规定的端到端时延指标和丢失率指标，主要用于对实时性要求很高的音频和视频等应用。负荷受控服务并不提供严格的定鼠性能保证。当网络负荷很轻时，所有数据流都按尽力服务方式处理；当网络负荷增加时，应使请求负荷受控服务的数据流的QoS不出现明显的下降，而尽力传送的数据流的QoS将愈盖恶化。这种服务主要用于允许一定量时延和丢失率波动的应用，如各种自适应实时应用。两种服务方式都要求对应用数据流进行管制，对于超量部分原则上按尽力传送方式处理。

RSVP协议支持上述两种服务，在实用上，以支持QoS确保服务为主。

6.3.2RSVP功能原理

       RSVP的一般机理如图6.10所示。为了启动资源预留，发送方首先发出PAIB消息，消息中包含数据流标识（即目的地地址）以及数据流业务特征，该消息沿着所选路由逐跳传送，通知沿途各路由器准备预留资源。接收方收到此消息后，根据业务特征和所需的QoS计算出所需的资源，回送RESV消息，消息中包含的主要参数就是请求预留的带宽。在多点到多点通信的一般情况下，还可指定预留请求对应的发送方以及多个预留请求在某路由器会聚后聚合数据流的预留方式(style)。RESV沿原路返回，沿途各路由器只有在收到RESV后才执行资源预留操作。发送方收到RESV消息后，开始发送用户数据流。由于可用资源有保证，该数据流的传送必能达到接收方要求的QoS。

图6.10  RSVP的一般机理

        由上述过程可知，在RSVP中，真正的资源预留操作是由接收方启动的，这和电信网络中的呼叫建立方向正好相反。之所以这样设计的原因是在有许多叶节点的多播情况下，可使协议实现大为简化，可适应多播群成员动态增减变化，并可支持各接收方请求不同QoS的异质请求情况。

       RSVP采用单向数据流资源预留机制，如果是双向数据流，则两个方向需独立执行上述过程。

       RSVP位于IP之上，其在协议栈中的地位与管理协议(ICMP、IGMP)和路由协议相当，分配的协议标识号为46。图6.11示出在综合业务Internet中端点主机和路由器中执行的协议栈。其中，RTP/UDP用于传送实时数据流，CSC/TCP用于传送通信控制信令。

图6.11  综合服务Internet中的协议栈

             RSVP既支持点到点数据流，也支持点到多点和多点到多点数据流的资源预留。图6.12给出点到多点情况下的资源预留情况。图中，端点A向端点B、Cl、Q、D!、压发送数据流，为此，A利用和媒体数据流同样的多播地址向各接收端点发送PATH消息。Cl 、C2和Dl、D2回送的RESV消息分别在路由器R2和R3聚合，端点B和局域网C、D回送的RESV消息在路由器R1聚合成一个RESV消息送回发送端点A。

图6.12   点到多点情况下的资源预留

       由于装载RSVP消息的IP数据包是和用户数据包在同一路径上传送的，因此常称RSVP为带内信令。这就要求有安全措施防止RSVP消息遭受恶意攻击，包括预留消息发起者的鉴权和消息本身的完整性保护。

       和传统电信网信令协议另一个不同之处是，电信网信令建立的连接状态都是硬状态，此状态在呼叫过程中保持不变，直至信令消息命令呼叫释放为止。而RSVP采用的是软状态，需要定期刷新。为此，要求端点周期性发送PATII和RFSV消息，以保证传送路径上的各路由器维持其预留状态。如果超时未收到RSVP消息，路由器中预留的资源就将释放。这样设计的原因一是简化出错处理，因为许多出错情况都可以通过超时机制予以克服；二是当路由发生变化时，不再使用的老路由上的路由器将由于超时而自动释放预留的资源。

       通过资源预留保证QoS的实现机制统称为业务量控制(traffiecontrol)，它由三部分组成；接纳控制和策略控制、分组分类器及分组调度器，如图6.13所示。当路由器收到RSVP预留请求时，首先向接纳控制和策略控制模块发出请求，前者确定本节点是否有足够的资源支持所请求的带宽，后者由运营部门设定，决定该用户是否允许进行资源预留，以防止无权或过度占用资源。只有当两个控制模块均通过后，才能为指定的数据流保留资源。其后，分组分类器根据请求为该数据流设定类别；分组调度器设置在输出端口，根据分组类别调度各分组的传送，保证各类分组获得其分配的带宽。

图,613  业务流控制机制

由此可得RSVP的主要特点为：

．支持单播和多播数据流。

．单向资源预留。

．面向接收方，即由媒体流的接收方进行资源预留。

．基于软状态，因此可动态适应路由变化和多播组成员的变化。

．针对一个会话（即一对运输层地址）进行预留。

 

6.3.3预留方式和聚合

       在多点通信情况下，RSVP允许接收方规定不同的预留方式，预留方式将直接影响到同一会话的不同分支发起的资源预留会合后， 路由器如何处理预留的聚合(aggregation)。

       在RSVP中，预留方式称为“风格”(style)，它包括两类选项。一类是选择如何处理对同一会话中的不同发送方数据流的预留请求，可以是对每个发送方建立一个独立的资源预留，也可以是所有选定的发送方共享一个预留。另一类是选择发送方，可以采取显式列表的方式列出所有选定的发送方，也可以为通配(wildcani)方式，表示所有发送方都选中。二者组合，可以得到表6.5所示的三种预留方式。

表6.5 资源预留方式

        其中，SE和WF方式适用于音频媒体，因为电话会议一般同时只有1个人在讲话，为了可靠起见，接收方请求预留的带宽可设为定发送方带宽的二倍，即可同时收听两个人的讲话。FF方式适用于视频媒体，因为多媒体会议中常要求同时展现多个会场的画面。

       三种预留方式的常用标记方式为：

. WF(*{Q}) ：其中，＊表示通配，Q表示保证QoS需要预留的参数。

. FF(S{Q})  或F(S1{Q1}，S2{Q2}...)；其中，S表示指定的发送方。

· SE((S1  ,S2, …）{Q}）：其中，(S1  ,S2,…）为选定的发送方列表。

       现以图6.14所示路由器为例，说明对于三种预留方式如何进行预留聚合.假设，从任一发送方Si 发来的分组需复制送到(c)、(d)接口，（d）接口为广播式LAN接口，再经不同路由器送到接收方R2和R3 。预留带宽基本单位为B。

1.WF预留方式

图6.14 予留聚合的路由器示例

       设，R1、R2,、R3分别发出带宽为4B、3B和2B的通配预留请求。则，路由器应为(C)接口链路预留带宽4B,(d)接口链路预留3B；然后经(a)、（b)接口向上一跳路由器转发RESV消息，请求通配预留4B的资源，以满足最高要求者R1  的需要。上述资源预留和转发请求的情况如表6.6所示。

表6.6  WF预留方式示例

 

2.FF预留方式

       此时，路由器在为下游链路预留资源时，应为每个发送源单独进行预留，因为这些发送方可能同时发送数据流。如果在链路接口上收到多个对同一发送方的资源请求，则应根据最大请求值预留资源。在向上游节点转发RESV消息时，其预留请求值应取为所有下游节点对该发送方请求的最大值。表6.7为FF预留方式的示例。

表6.7   FF预留方式示例

3.SE预留方式

       在SE方式中，路由器为下游链路预留资源时，预留的数量应为自该接口收到的所有预留请求的最大值，为之预留的发送方应为自该接口收到的所有预留请求指定的发送方的和集。在向上游节点转发RESV消息时，其指定的发送方应为这样一些端点的集合，这些端点既是该接口的上游发送方，又至少是某一下游预留请求指定的一个发送方。RE.SV的预留请求值应取为所有相关下游预留请求值的最大值，这些下游预留请求指定的发送方中至少应包含一个该接口的上游发送方。表6.8给出SE方式下的资源预留和请求转发情况示例。

表6.8  SE预留方式示例

6.3.4预留协议和消息

1.消息格式和类型

   RSVP消息由一个公共头部和若干个对象构成。图6.15为头部格式。各字段的意义为：

• Vers:RSVP版本号。

• Flags：标志域，尚未定义。

图6.15  HSVP消息头部

• RSVP校验和：为整个RSVP消息的校验和。

• 发送TIL:消息发送时的IP层ITL值。

• RSVP长度：包括公共头部和可变长度对象部分的总长度，单位为字节。

• 消息类型：定义了7个消息，其类型号消息名及其作用如表6.9所示。各消息的发送方向如图6.16所示。

表6.9    RSVP消息

图6.16  RSVP消息传送方向

图6.17  RSVP消息对象格式

       所谓对象就是RSVP消息的参数。对象格式如图6.17所示。其中，类编号（Class-Num）就是消息参数类型；类型式（C-type）指示该RSVP消息使用的下层协议型式，目前定 义两种型式：IPV4和IPV6，对应的C-type值分别为1和2。对于不同的下层协议型式，其对象内容编码也随之不同。

       RSVP共定义了15个对象参数，其中每个RSVP消息都必须包含的必备参数是“会话”(session)对象，它指示该消息是为哪个数据流进行资源预留的。会话对象由三个数据单元组成：数据流的目的地地址、协议标识和端口号。其中，目的地地址可为单播或多播1P地址；对于多播会话来说，由于不同会话其多播地址总是不相同的，因此可以不包含端口号，单播会话则必须包含端口号；对于音频和视频等实时媒体流来说，协议标识通常为UDP。其余对象参数及其含义将结合消息在下面予以说明。

2.Path消息及其处理

Path消息包含以下参数信息：

．前一跳地址(Phop)：转发该Path消息的前一个具有RSVP能力的节点的[P 地址。该地址随着压th消息的前传,EB每个支持RSVP的路由器予以更新。

．发送方标识(SenderTemplate)：发送方的IP地址，还可包含其端口号。

．发送方业务流特性(SenderTspec)：即数据流的话务特性描述，包括峰值速率、最大数据报长度、漏桶参数等。

．通告信息(Adspec)：任选参数，在消息前传过程中由每个支持RSVP的路由器更新，用以向接收方通告路径端到端传送的固有特性，供接收 方计算预留资源使用。如果发送方发出的Path消息中不含通告信息，则称为简单的“单程”(OnePass)预留模型；如果包含通告信息，则称为＂带通信告息的单程”(OPWA-OnePassWrthAdvertis­ing)预留模型。采用OPWA，预留资源昼的计算更为精确，可以确保获得所需要的QoS。

       每个支持RSVP的路由器收到Path消息后，首先检查消息的合法性。如果发现消息有错，则丢弃该消息，且向上游回送PathErr消息，以通告发送方采用适当的措施。

       如果消息合法，路由器更新其存储的“路径状态＂，该状态的内容就是Path消息的4个参数。如果收到的是关于该发送方会话的第一个Path消息，则路由器创建路径状态。其中，参数Adspec收到后应交给本地业务星控制模块，经其计算后返回更新的Adspec，装入转发至下游的Path消息，并存入路径状态。状态中存储Phop参数的目的是供其后收到下游发来的Resv  消息时，作为该消息的下一跳地址，这样确保Rsev消息和Path消息走同一路径。正因为如此，我们称Path消息的基本作用就是建立路径，这也是该消息的名字由来。

       路由器收到Path消息后的另一操作是复位并重新启动状态清除定时器(cleanuptimer)，这是RSVP软状态机制的需要。该机制还要求发送方周期发送Path消息，以刷新状态。刷新周期应小于状态清除定时值（设为1/K)，这样，即使连续丢失K-1个Path消息也不会造成状态清除。为了防止因网络拥塞而丢失Path消息，建议配置时为RSVP消息保留一定量的最小网络带宽。

       当路径状态发生变化或路由协议需要改变数据转发路径的转出端口时，路由器也可自行生成Path消息并向下游发送。

最后说明一下Adspec 对象参数的内容和意义。该对象内容由两部分组成：缺省通用参数部分；确保服务或者负荷受控服务部分。

缺省通用参数部分包括以下参数：

．最小路径时延：其值为路径中各段链路的传播时延之和。接收方从所要求的端到端时延指标中减去此值就得到端到端排队时延的上限。根据此上限值就可算得需预留的带宽。

．路径带宽：其值为路径中各段链路带宽的最小值。接收方请求的预留带宽值不允许超过此值。

．全部中断比特：该比特指示路径中是否包含不支持RSVP的路由器。发送方发出Path消息时该比特复位。如果在途中遇到不支持RSVP的路由器，则RSVP将该比特置位。接收方发现该比特憤位，就知道Adspec值不准确，仅具参考意义。

．综合业务(IS)跳计数器：路径中每经过一个支持RSVP/IS功能的路由器，该计数器加1。

．路径最大传输单元(PathMTU)：其值为路径中各段链路MTU的最小值。最大传输单元(MTU)的单位为字节。在综合业务Intern门中，为了确保所需的QoS，数据流分组在传送过程中不能分段。为此，接收方回送的Resv消息中Tspec参数中的最大传输单元(M)不能超过收到的Path消息中Adspec中的PathMTU。如果接收方收到多个发送方送来的Path消息，且对于这些发送方都需要预留资源，则应取所有PathMTU中的最小值作为M值。

       Adspec中，确保服务部分和受控负荷服务部分二者只能取其一，未取到者表示该类服务不可用。在多播会话中，利用此特性可强制 所有接收方选用相同类型的服务。目前RSVP尚不支持多播会话中的异质服务。这两类服务的Adspec参数也是供接收方计算预留资源使用，具体参数不再细述。

3.Resv消息及其处理

Resv消息包含以下参数信息：

．预留方式指示：FF、SE或WF。

．筛选说明(Filterspec）：用以标识对哪个或哪些发送方进行资源预留，其格式和Path消息中的发送方标识相同。此参数仅用于FF和SE预留方式。

．数据流说明(F1owspec)：由Tspec和Rspec两项组成。Tspec指示业务流特性，和Path消息中的发送方业务流特性相同，只是M要由Adspec中的PathMTU代之。Rspec称为预留说明，主要内容就是接收方根据所要求的端到端时延指标和Adspec中的参数计算得到的预留带宽R。

．预留证实(ResvConf)：为任选参数，其值为接收方的IP地址。如果消息中包含此参数，在单播情况下，就是指不发送方在收到Resv消息后，向接收方回送预留证实消息，表示资源预留成功。在多播情况下，就是指示预留会聚点回送预留证实消息，它只表明从接收方直全该会聚点的资源预留已经成功，们是并不能保证从该会聚点至发 送方的资沥预留定成功。

       Resv消息沿若Path消息历经的路由逆向回传。每个路由器收到Resv消息后，将执行如下操作：

       首先，将Flowspec传给业务植控制模块，以确定节点是否接纳此预留。如果不予接纳，则向接收方回送ResvErr消息，指示预留失败，该路山器中已有的预留资源保持不变。

       如果准予接纳，则设定分组分类器配置参数，以便在数据传送时选出由筛选说明指定的数据分组。同时根据预留方式，指示对应的链路保留资源。对于租用线链路，只要设定分组调度器参数即可，对

于具有QoS能力的链路，如ATM或LAN链路，则应与链路层协商确保其支持所需带宽。最后，向上游转发Resv消息。至此，我们说该路由器已建立了预留状态。

       最后说明一点，Resv消息中的预留说明(Rspec)除了预留带宽R外，还有一个数据单元S，称为“松弛项＂，其单位为ms。它表示如果令程所有路由器都按请求保留带宽R，则所得的端到端时延将比要求的时延指标值小S亳秒，即指示QoS的富裕量。它可使路由器预留资游有更大的灵活性，在某些情况下还可增加端到端资源预留成功的概率。

        例如，如图6.18所示，对于某数据流，接收方根据Path消息中的Tspec和Adspec参数算得需预留带宽RI=2.5Mbit/s，此时松弛项SI=0。由此构成的Resv消息传至路由器RT3时，由于该路由器只有2Mbit/s的可用带宽，因此预留被拒绝，向接收方回送ResvErr消息。现将预留请求值增加为R2=3Mbit/s，此时松弛项SI>0。如图

图6.18  S=0时预留请求失败

        6..19所示，Resv消息到达路由器RT3后，由于时延特性尚有富余量，RT3有可能将预留值改为R2=2Mbit/s。如果经计算，增加的时延值di< S1，则预留成功。此时，RT3向上游转发的Resv消息中的Rspec参数，置R2=2Mbit/s,S2=S1-dl，路由器RT2和RTl也只需保留2Mhit/s带宽。这样得到的端到端时延将不大于每个路由器均保留2.5Mhit/s带宽时的时延。

图6.19 S>O时预留请求成功

4.预留终结

       虽然通信结束或参会者退出会话后预留资源可通过超时机制自动释放，但是为了避免资源无效占用，RSVP还定义了由终结消息显式释放预留的机制。计有两个终结消息：PathTear 和ResvTear，它们可由端系统（发送方或接收方）发出，也可由路由器在状态超时时发出。一旦发出，终结消息将一跳接一跳往前传。PathTear消息由启动点发出后，沿下游方向传送至所有接收方，各路由器收到此消息后将删除其保留的路径状态和相关的预留状态。ResvTear消息由启动点发出后，沿上游方向向所有发送方传送，各路由器收到此消息后将删除其保存的预留状态。如果ResvTear消息传送至某路由器，经聚合后已不再影响聚合后的预留参数，则ResvTear消息将停止向上游传播。

6.3.5H.323系统的资源预留

1.一般机制

为了保证实时多媒体通信的质屋，H.323 版本3给出了利用

RSVP 实现运输层资源预留的信令过程，它主要包括下述三个方面。

(1)增强的RAS过程

当端点向网闸发出接纳请求时，应在ARQ消息中指明其是否具有资源预留能力。网闸根据端点信息和它所掌握的网络状态信息在下述三种选择中择一作出决定：

． 允许端点自行进行H.323会话的资源预留。

．由网闸代表端点进行资源预留。

．不需要进行资源预留，尽力传送服务就足够了。

        决策结果经ACF消息传给端点，端点据此建立呼叫。虽然通过网闸选路信令方式，媒体数据流路由也可经过网闸转接，但是实际上媒体信道一般都是在收发端点之间直接选路，并不通过网闸，这也是RSVP资源预留希望的最佳路由方式，因为它可以在呼叫路由全程实现资源预留。

        如果端点指示其不能进行资源预留，而网闸决定资源预留必须由端点自行控制，此时网闸应向端点回送ARJ消息。

上述功能是通过H.225.0版本3RAS信令新设的传送QoS(trans­portQoS)字段完成的。

       需要注意的是，ARQ消息中的带宽(bandwidth)字段指的是该呼叫所有信道所需的带宽，它和端点是否采用RSVP信令无关。在呼叫进行过程中此带宽需改变时，端点应通过BRQ消息向网闸报告，这也和是否使用RSVP无关。

(2)增强的能力交换过程

        为了执行RSVP过程，收发端点必须都具有RSVP支持功能。为此，什建立媒体信道之前，端点之间必须通过能力交换过程确认双方都具有此能力。H.245版本5在终端能力集(TerminalCapabilitySet)消息和打开逻辑信道(OpenLogicalChannel)消息中均定义了qOSCapa­叫ity数据单元。该数据单元的主要内容为：

． qOSMode：指示终端是支持确保QoS服务还是负荷受控服务。

．其它RSVP参数：即端点的传送资源能力，如漏桶大小、允许峰值速率、最大分组长度等。

       在终端能力集消息中，其它RSVP参数是该端点关于所有媒体流的聚合能力，并不是对于某一媒体流特定的能力，因此对于对端来说并无意义。在能力交换阶段有意义的只是qOSMode字段，端点必须对该字段置位，以向对方通告自己具有RSVP能力。如果发送端点没有从接收端点收到RSVP能力指示，就不能在建立逻辑信道时

使用RSVP。

(3)增强的逻辑信道控制过程

        其基本要点是在逻辑信道打开过程中应包含Path和Resv消息过程，在逻辑信道关闭过程中应包含PathTear和ResvTear消息过程。

这里说明一点，RSVP的Path和Resv等消息和媒体数据流使用的是相同的IP地址／端口对，但是由于实时媒体流是封装在UDP消息之中的，而RSVP消息并非UDP消息，因此端点很容易对二者予以区别。

下面着重说明在采用RSVP协议时的逻辑信道控制过程。

2.逻辑信道打开和资源预留建立过程

      图6.20示出点到点情况下的RSVP逻辑信道建立的信令过程。其建立步骤为：

      ①发送端点(EPI)向接收端点(EP2)发送“打开逻辑信道”(OpenlogicalChannel)消息，在消息的qOSCapahility数据单元中标明该信道的RSVP参数以及EPl支持的综合业务类别。

图6.20单播RSVP逻辑信道打开的信令过程

       ②EP2创建RSVP会话，向EPI发送证实消息OpenlogicalChan-nelAck，消息中包含EP2为该逻辑信道选定的端口号。

       EP2可以指示在RSVP预留过程完成后才开始接受媒体数据流。此时，EP2可将open1ogicalCharmelAck消息中的“流量控制为零”(flowcontralToZero)字段置为“真”,EPl见此标志后将不会发送媒体数据流。

       ③EPl和EP2执行RSVP资源预留过程。

       ④EP2收到ResvConfirm消息后，获知预留成功，向EPl发送“流星控制命令”(flowControlCommand)消息，消息中的最大比特率置为无限制。EPl收到此指示后即可开始发送媒体数据流。

       如果RSVP预留失败而EP2决定尽力传送服务不可接受，则可发送“请求信道关闭”(requestCharmelClose)消息，其关闭理由字段指明是RSVP失败。该消息还可包含qOSCapahility数据单元，用以告诉EPl目前路径实际可用的资源。EPI据此可以决定是否更换一个较低速率的编译码器和／或采用较低速率的数据格式，然后重新启动逻辑信道打开过程。

       端点选择QoS确保还是负荷受控服务方式可由端点设备制造商自行决定，但是为了解决互操作性问题，规定所有H.323端点必须能支持负荷受控服务方式。

3.逻辑信道关闭和预留终结过程

       对于发送方来说，在发送“关闭逻辑信道”(closeLogicalChannel)消息之前，必须首先发送PathTear消息。对于接收方来说，在收到关闭逻辑信道消息后，应发送ResvTear消息。

4.多播逻辑信道的资源预留

      图6.21给出多播RSVP逻辑信道打开的信令过程，图中只示出其中一个接收方。其步骤为：

图6.21  多播RSVP逻辑信道打开的信令过程

       ①发送端点EPl向EP2发送“打开逻辑信道“消息。尽管是多播情况，H.245逻辑信道打开过程仍是点到点的过程。只是接收者的端口号将由发送方在信道打开消息中指定，而不是像点到点情况下由接收方在打开证实消息中回送。

       ②Ep2利用IGMP的“报告”(Report)消息加入多播组，和多播树相连。

       ③EP2向EPl回送打开证实消息，也可置“流量控制为零”字段为“真＂。但是由于该多播通信还有其它接收方，为了不中断至其它接收方的通信，EPl 可以决定不中断在已打开信道上的 数据流传送。也就是说，在多播情况下，E眨可能在RSVP预留完成前收到一些尽力传送的数据。

       ④执行RSVP预留过程，逻辑信道关闭过程和点到点情况相同，只是En  在发送ResvTear消息后还需发送IGMP的“离开”(Leave)消息，以脱离多播组。

       最后需要说明一点，H.323建议要求所有RSVP的Resv 消息都使用FF预留方式。这点对于点到点呼叫来说自然是不言而喻的。对于多播呼叫来说，建议认为WF和SE的共享预留机制对于同时只可能有一个发送方发送数据的多播应用是合适的，但是在分布式多点H.323呼叫中，没有机制能够限制同时只有一个信源发送数据，而在集中式多点H.323呼叫中，MCU是唯一的多播信源，也就不存在预留共享的问题。