摘  要: 对RTCP的可扩缩性问题进行分析,探讨了一种RTCP可扩缩性的改进策略,并将其应用于大型的动态多播组中。

　　关键词: RTCP  可扩缩性  动态多播组

　　为了解决Internet上多媒体通信所面临的问题,IETF提出了实时传输协议(RTP)标准,为用户提供端到端连续媒体数据的实时服务。实时控制协议(RTCP)是RTP的控制部分,主要用于发送者改变数据传输速率来适合网络当前状态。RTP和RTCP能在中小型会话中工作得非常好。但随着多媒体需求的持续增长,拥有上千个成员的MBone会话将成为平常事,并且成员数会动态涨落。这时,RTCP可扩缩性的问题将变得十分明显。

　　本文在详细分析这些问题的基础上,探讨了一种应用于大型动态多播组的RTCP可扩缩性的改进策略。

1  RTCP协议介绍

　　RTCP协议和RTP一起提供流量控制和拥塞控制服务。在RTP会话期间,将控制包周期地发送给所有的连接者,应用与数据包相同的分布机制。RTCP执行以下4种控制功能。

　　(1)QoS监控和拥塞控制。发送音频(或视频)数据的发送者会产生一个SR包,包中含有所发送的包数和字节数统计等信息。接收者可据此估计出实际的数据率。会话成员向所有参与会话活动的音频和视频源发送RR包,包中含有所接收的最高包序列号、丢失的包数、包间隔抖动测量值以及计算源端和目的端之间来回时间(Round-Trip-Time,RTT)所需的时间戳。

　　(2)标志媒体间的同步。RTCP的SR包中含有实际时间和相应的RTP时间戳,可用于不同媒体间的同步。

　　(3)提供标志信息。RTP数据包只能通过随机产生的32位标志符来标识源,而RTCP的源描述SDES数据包为每个对话成员提供了全局惟一的标志符信息,可以满足复杂应用的需要。

　　(4)会话规模估计和规划。参与会话的每个成员周期地发送RTCP包,各站点可据此估计或计算出参与会话的人数,及时调节实时监控的信息量,使得控制信息量和媒体业务量达到平衡。

　　RTCP数据包有以下5种包类型:①SR源报告包,用于发送和接收活动源的统计信息。②RR接收者报告包,用于接收非活动站的统计信息。③SDES源描述包,用于报告和用户相关的信息。④BYE用户离开系统报告包。⑤APP特殊应用包。

2  RTCP可扩缩性分析

　　RTCP应用于大型的多播组特别是动态的多播组时,其可扩缩性问题十分突出。

　　(1)拥塞:通常期望多播会话在某个时间点能及时地容纳组成员的快速增长。然而当大量用户几乎在同一时间加入同一个会话时,每个用户都认为他是惟一的用户,他们将在相当短的时间内发送一个初始的RTCP包,致使RTCP包溢出,发生拥塞。对于那些以低带宽连接的成员,这将直接导致部分成员的初始包丢失,影响对组大小的估计。由于成员离开会话时会以多播方式发送一个BYE包给组内的所有成员,所以大量用户同时离开多播组也会发生拥塞。

　　(2)状态存储:为了估计组的大小,主机必须根据多播组的反馈报告来计数该多播组中的成员。为了保证每个终端系统仅被计数一次,需要存储其惟一的标识符(SSRC)。一旦多播组急剧增大将需要巨大的存储空间。这使得RTCP状态存储的可扩缩性成为一个重要问题。

　　(3)延迟:随着组的增加,从某个特定用户得到RTCP报告的时间将变得非常长(例如:在一个大约3 000成员的组中,相互发送一个RTCP包大约需要一个小时)。如此长的间隔意味着来自某个特定用户的QoS问题的反馈报告将变得毫无意义。

　　(4)过早停机:当大量成员同时离开时可能产生的另一个问题就是在用户还没有全部离开应用程序时程序就停止了。这是由于在现行的标准中,一个用户如果在持续的5个RTCP包的间隔内不发送RTP或RTCP包,他就被停止了。在一个动态组中,间隔本身就是动态的。当大量用户同时离开组时,他们的BYE包使得组的大小的估计值急剧降低。这就导致了停机间隔的缩短。如果用户离开的人数足够多,则该停机间隔将降低到使得残留的用户也将被停止。

　　除了以上提到的这些问题外,由于目前越来越多的实时的适应性应用程序使用基于接收者的速率适应机制,而非基于发送者的速率适应机制,这也使得RR中的一些域的功能也出现了问题。

3 RTCP可扩缩性的改进策略

　　从RTCP的工作情况和RR的功能可以发现反馈(Feedback)在其中起到的重要作用,RTCP的许多扩缩性问题都与它有关。以下提到的这种方法不需要每个成员都计算整个多播组的大小,也不需要广播RR,从而有效地解决了RTCP中由大量包的多播带来的种种不便于扩缩的问题,更有效地利用了RR。

　　本文论述的这种策略要使用本地域及其成员的结构树图如图1所示。这里所指的成员是在同一个RTP会话中所有的接收者或发送者。该结构将成员动态地组织到一个多层次的本地域(Local Region)中。

　　在每个本地域中都有一个Aggregator(AG),它的子节点可以是AG、LAG或者普通的成员(用空心圈表示)。AG1是第一层的AG,AG2属于第二层,是AG1的子节点。AG接收其子节点发送的RR,产生统计表,并发送给Manager。由AG或LAG发给Manager的RR称为AGR。LAG是处在LAN中的AG,它与AG的功能相同。同一个LAN中只有一个LAG。Manager是整个层次结构的根,也可以看作是AG0,它接收来自既非AG也非LAG的直接子节点的RR,也接收AGR。Manager是惟一没有子节点数量限制的AG。如果某子节点不能被其双亲AG接收,则它会被Manager接收。

4 应用于大型动态多播组的工作过程

　　下面从一个RTP会话的建立开始,具体说明该策略在大型动态多播组中的应用。

4.1 初始工作

　　一个RTP会话开始后,首先通告2个多播地址:第一个地址传输RTP数据包,第二个传输RTCP控制包。然后,Manager加入多播的控制组。

4.2 Manager的作用

　　Manager是整个层次结构的根,仅存在于控制组中,不对数据组起任何作用。它对加入或删减成员及各种角色选举结果的信息进行管理。

　　Manager在每个间隔期间分析AGR中的数据,将有用的统计表记入日志,据此诊断、估计可能或已发生问题的区域,监视数据在多播组中的分布。收集和分析统计数据,帮助估计每个区域的接收质量,发现单个会话内的热点区域。所以,应该被高速地连入网络。

4.3 本地域的建立

　　本地域的建立在Manager加入以后进行,主要包括新成员的加入和LAG、AG的选举。

4.3.1 普通成员的加入及AG的选举

　　当一个新成员加入会话时,首先执行一个扩展的环搜索。新成员通过增加TTL的值来重复搜寻双亲AG直到它找到一个邻近的双亲。TTL是IP包中的一个域,发送者根据想要包到达距离的长短,对TTL域初始化。每经过一个路由器TTL减1,当TTL=0时,该包被丢弃。TTL=1的广播包仅用于对同一局域网内成员的发送。新节点寻找双亲的信息交换过程如图2所示。首先,它广播一个TTL值较小且大于1的“Search-for-Parent”的请求,如果一段时间内没有答复,它将以一个大一点的TTL再做一次扩展的环搜索。依此类推,直到它在现有的AG中接收到一个“Potential-Child-Acceptance”回应。

　　新成员(NM)接收到候选双亲的回复后,对每个候选双亲(CP)的AG进行判定,以确定自己是可能的子节点(PC)还是侯选(CC)AG。新成员角色判断的流程图如图3所示。

　　每个双亲AG所能有的直接成员(包括非AG和AG)的最大数量分别用MAX1和MAX2表示。这种信息通过以下方式传递:当会话刚开始仅有Manager时,如果有成为AG的新节点加入,则Manager就将这些信息传递给AG,AG再将这些从Manager得到的初始信息传给它们的子AG。初始的管理信息都是通过这种方式发送的。

　　N和M是某个特定的值,N限制了结构树的高度,当树高≥N时,新成员不会成为AG。M是对到新成员距离的限制,它保证了一个离双亲很近的成员,不能成为AG。

　　新成员收到多个候选双亲的回复(实箭头)时的选择过程描述图如图4所示。此时,选择带有最大TTL值的那个候选双亲作为双亲,该双亲到新成员的距离最短。然后向没被选中的双亲发送“Reject-Parent”消息(虚箭头)。如果新产生的AG没有任何子节点,则双亲就把该AG恢复为普通子成员。

　　被接收的成员向选定的双亲单播“Accept-Child”消息,存储接收到的“Potential-Child-Acceptance”消息。对选定的双亲要做些修改:增加子节点的数量;存储原始TTL的剩余值,此剩余值即为选定双亲到新加入的子节点的距离。如果接收的新成员是AG,则双亲还要增加它的AG数目。

4.3.2 LAG的选举

　　当一个新的LAN成员加入某个会话时,本地先多播(TTL=1)一个“搜索LAG”包,询问所在的LAN是否存在LAG。如果LAG存在,则所有的成员(包括LAG)本地多播一个“LAG存在”的回应(包括LAG的IP地址)。为了避免回复报告的溢出,采用随机的退出时钟来控制报告的发送:每个成员附带一个随机的退出时钟。延迟最小的成员最先终止它的时钟,并立即发送回复消息。一旦得到回复消息,其他成员就停止发送回复,并取消这些成员的时钟。

　　如果一段时间内没收到回复,则认为该LAN中还没有LAG,这时它被认为是该LAN中参加这个会话的第一个成员,且被选为LAG。接着开始搜索自己的双亲AG。一旦有一个LAG加入,不管它的双亲AG有多少个子节点,都能立刻被接收。LAG在它所在的局域网内没有成员数量的限制。

4.4 各成员的离开

4.4.1 AG的崩溃或离开

　　AG周期性地对本地多播更新消息给它所有的子节点(AG的TTL值=离它最远的子节点的TTL)来通知它还存在。如果子节点在一段时间内接收不到这样的消息,就假设AG已经崩溃。如果AG离开组,就向其所有子节点本地多播一个RTCP BYE包。不管哪种情况,该AG的每个子节点都将重新开始一个扩展的找寻双亲的过程。

4.4.2 LAG的崩溃或离开

　　发现LAG崩溃或离开的过程与发现AG崩溃或离开的过程是类似的。LAG也是通过一个信息包的周期性多播来证明自己的存在,如果离开就多播BYE包。一旦发现LAG不存在,则LAN中的成员开始选择一个新的LAG。每个成员都本地多播一个“要成为LAG”的请求。这里同样使用可以阻止多播请求溢出的随机退出时钟。当某个成员的时钟终止,就多播一个包括IP地址的“LAG存在”的消息。一旦接收到这个消息,LAN中其他的成员就停止自己“要成为LAG”的请求,接收那个成员作为新的LAG,并存储它的IP地址。这就直接决定了一个新的LAG。确定了新的LAG后要通知祖先AG,并修改有关信息。

4.4.3 一般成员的崩溃或离开

　　一个既非AG又非LAG的普通成员离开时,只需向它的双亲AG发送BYE包。然后相关的AG作一些修改:更新相应的记录表,在它双亲AG的子节点数量中减掉1,并修改相应祖先AG的信息。

4.5 Manager的离开

　　当所有的成员都离开会话,或者会话结束时,Manager失去了存在的意义,会自动离开会话。

5  总  结

　　这里描述的改进机制并不能完全解决关于大型动态多播组中RTCP扩缩性的问题,只能从某些方面减轻问题。关于扩展的RTCP一些更为细致的工作正在研究之中。在具体的模拟实践中需要不断地改进该策略以期能更好地服务于不断发展的网络多媒体应用。

参考文献

1   Schulzrinne H,Casner S,Frederick R et al.RTP: A　Transport Protocol for Real-time Applications.RFC 1889,1996

2   Aboba B.Alternatives of Enhancing RTP Scalability.draft-aboba-rtpscale-02.txt,1996

3   Rosenberg R,Schulzrinne H.Timer Reconsideration for Enhanced RTP Scalability. draft-ietfavt-reconsider-00.ps,1997

4   Marakby R E,Hutchison D.Scalability Improvement of the RTCP Leading to Management Facilities in the Internet.in:Proc of the third IEEE Symposium on Computers and Communications(ISCC′98),Athens,Greece,1998

5   Friedman T,Caceres R,Almeroth K et al.RTCP Reporting Extensions.Internet Engineering TaskForce,2002