专利名称：在计算机和通信网络中执行多播注册和资源预留的方法
技术领域：
本发明涉及一种在计算机和通信网络中执行多播注册和资源预留的方法，特别是介质访问子层的多播，如IEEE 802.3以太网的多播注册和资源预留，根据本发明，接收者能够通过发送单个消息来达到多播注册和资源预留的目的，从而能够快速、高效地提供多播服务质量的支持。
背景技术：
现有的以太网多播协议主要有IEEE 802.1D中规定的多播注册协议GMRP(GARP多播管理协议)和Cisco公司的CGMP(Cisco组管理协议)，其中GMRP基于IEEE 802.1D中定义的通用属性注册协议GARP，它的运行过程如下想要注册成为某个多播组G成员的设备D生成一个GMRP报文，并把该报文发到它所在的局域网上，其中a)报文的目的地址为GMRP多播地址01-80-C2-00-00-20。
b)报文包含多播组G的介质访问子层(MAC)地址。
c)当设备D所在局域网的网桥收到该GMRP报文之后，把收到该报文的端口标记为多播组G的转发端口，并把该报文向其他所有处于活动状态的端口转发。
其它网桥也作类似处理，这样，该GMRP报文就类似广播报文那样被发到整个局域网上。
CGMP是Cisco公司提出的，用于Cisco网桥和路由器之间交换二层和三层多播注册信息的协议。当Cisco路由器收到三层的多播注册消息后，用CGMP协议通知Cisco的交换机，这样建立三层多播组的同时也在二层建立了多播组。
GMRP和CGMP只提供多播注册，不提供资源预留。
IEEE的驻地以太网RSE研究小组最近提出了简单预留协议SRP，该协议的主要目的是为同步流提供资源预留。本申请和SRP的主要不同之处在于，SRP在多播注册的时候不进行资源是否满足需求的检查，只有发送者开始发送数据之后才知道带宽是否不足；本申请在多播注册的时候同时进行资源检查，只有当资源满足需求时才进行多播注册。
在现有技术中，只包含多播注册的技术，如GMRP和CGMP等，均不能提供服务质量的保证，由于目前越来越多的应用如视频播放、VoIP有着严格的带宽或延迟要求，因此在以太网中提供服务质量保证势在必行。
简单预留协议SRP在多播注册的时候不进行资源是否满足需求的检查，只有发送者开始发送数据之后才知道带宽是否不足，这样会造成网络状态的不一致性。对于有服务质量需求的流来说，一旦被接纳，则说明该流的服务质量一定能够得到保证。而SRP协议不具有这种特征，即使多播请求被接纳，也不一定能够提供相应的质量保证，这使得SRP协议不适合为以太网提供服务质量保证。
为了解决以太网中多播服务质量的保证问题，我们提出了一种新的综合多播和资源预留的解决方案。该方案中，接收者可以通过发送单个消息来达到多播注册和资源预留的目的，从而能够快速，高效地提供多播服务质量的支持。
发明内容
本发明的目的是提出一种在计算机和通信网络中执行多播注册和资源预留的方法，根据本发明，接收者能够通过发送单个消息来达到多播注册和资源预留的目的，从而能够快速、高效地提供多播服务质量的支持。
为了实现上述目的，根据本发明，提出了一种在计算机和通信网络中执行多播注册和资源预留的方法，所述方法包括以下步骤当多播数据的接收者要加入多播组时，所述接收者生成多播加入消息，并向多播数据的发送者发送所述多播加入消息；当接收者与发送者之间的多播数据转发路径上的网桥接收到所述多播加入消息时，判断所述网桥是否存在与所述多播加入消息相对应的多播表项；在所述网桥不存在与所述多播加入消息相对应的多播表项的情况下，所述网桥进一步检测是否有足够的资源满足多播加入消息的资源请求；如果存在足够的资源，则所述网桥创建针对所述多播加入消息的多播表项，并接受所述多播加入消息且继续向多播数据的发送者转发；否则，则拒绝所述多播加入消息。
优选地，所述方法还包括步骤在所述网桥存在与所述多播加入消息相对应的多播表项的情况下，所述网桥判断所述多播表项的转发端口列表是否包含接收所述多播加入消息的端口，如果断定所述转发端口列表不包含接收所述多播加入消息的端口，则在转发端口列表中创建所述端口，并在所述端口处为所述多播加入消息预留资源。
优选地，所述方法还包括步骤当多播数据的接收者要离开所述多播组时，所述接收者生成多播离开消息，并向所述多播数据的发送者发送所述多播离开消息；当接收者与发送者之间的多播数据转发路径上的网桥接收到所述多播离开消息时，判断所述网桥是否存在与所述多播离开消息相对应的多播表项；在所述网桥存在与所述多播离开消息相对应的多播表项的情况下，将接收所述多播离开消息的端口从所述多播表项的所述转发列表中删除，并将所述多播离开消息继续向多播数据的发送者转发。
优选地，在将接收所述多播离开消息的端口从所述多播表项的所述转发列表中删除的步骤之后，还包括步骤如果经过删除后的转发列表为空，则删除与所述转发列表相对应的多播表项。
优选地，所述拒绝所述多播加入消息的步骤包括由所述网桥产生针对所述多播加入消息的否定应答并向所述接收者转发所述否定应答。
优选地，当网桥接收到否定应答时，将所述否定应答向自身多播表项中的所有转发端口进行转发。
优选地，接收到针对所述多播加入消息的否定应答的网桥从其自身中删除与所述多播加入消息相对应的多播表项。
优选地，在网桥接收到所述多播离开消息之后，所述网桥释放为与所述多播离开消息相对应的多播数据预留的资源。
本发明使以太网系统具有了多播资源预留的能力。由于本发明把多播注册和资源预留结合在一起，因此大大降低了网络中需要传递的消息数目以及网络设备需要维护的状态数目。另外，综合多播和资源预留的解决方案还有助于降低网络中状态不一致的比率。
通过参考以下结合附图对所采用的优选实施例的详细描述，本发明的上述目的、优点和特征将变得显而易见，其中图1是示出了网络拓扑图；图2是示出了设备R1发送多播加入消息的示意图；图3是示出了网桥B2建立多播表项，并转发多播加入消息的示意图；图4是示出了网桥B1建立多播表项，并转发多播加入消息的示意图；图5是示出了设备R1接收肯定应答消息的示意图；图6是示出了设备R3发送多播加入消息的示意图；图7是示出了网桥B3建立多播表项，并转发多播加入消息的示意图；图8是示出了设备R3接收肯定应答消息的示意图；图9是示出了设备R1发送多播离开消息的示意图；图10是示出了网桥B2删除端口状态和多播表项，并转发多播离开消息的示意图；图11是示出了网桥B1删除端口状态示意图；以及图12是示出了全网状态的定期刷新的示意图。
具体实施例方式
为了在以太网中提供服务质量保证，提出了根据本发明的综合多播和资源预留的方法，该方法包括以下几个部分。
以太网网桥的多播变量定义网桥使用多播表项来记录多播组的注册和资源预留信息。每一个表项所包含的变量如下√接收端口即该多播组的上游网桥所对应的端口。上游的控制信息和多播数据都应该来自接收端口。
√转发端口列表一组端口。当网桥接收到来自上游的多播数据时，应该把该数据向转发端口列表中的所有端口进行转发。
√刷新定时器(RTimer)控制着网桥向上游定期发送刷新消息的定时器。当RTimer超时后，网桥向上游发送刷新消息。
√状态表明该表项当前所处的状态。其中■“等待状态”表明网桥已经为该多播组建立了多播表项，但它还没有收到来自上游网桥的加入确认信息；■“完成状态”表明网桥已经为该多播组建立了多播表项，且它已经收到来自上游网桥的加入确认信息。
√转发端口列表中的每个端口也对应着一个定时器，即端口超时定时器(PTimer)。当PTimer超时后，网桥则把该端口从转发端口列表中删除。
网络中传递的消息定义多播加入消息接收者使用多播加入消息来通知网桥和发送者它想要接收某类多播数据。除此外，接收者和网桥还定期发送多播消息，从而保持上游网桥和发送者的状态。
除了要加入的多播组的信息外，多播加入消息中还包括资源请求信息，以便网桥或发送者能够根据该信息进行资源预留。
多播离开消息接收者和网桥使用多播离开消息通知上游网桥和发送者它们不想再接收某类多播数据。
肯定应答消息发送者或网桥使用肯定应答消息通知接收者已经成功加入多播组否定应答消息发送者或网桥使用否定应答消息通知接收者加入多播组失败以太网网桥的行为定义处理多播加入消息当网桥接收到多播加入消息后，首先检测自己是否有和该消息对应的表项。如果没有找到对应的表项，或者接收到多播加入消息的端口不在该表项的转发端口列表中，则网桥进一步检测是否有足够的资源满足多播加入消息的资源请求。根据检测结果，网桥做如下操作如果网桥没有足够的资源满足多播加入消息的资源请求，则该网桥生成一个否定应答消息，把该消息发往多播加入消息的发送者，并丢弃加入消息。
如果网桥有足够的资源，则该网桥的行为取决于网桥是否有对应表项，以及该表项的状态，具体的来说 如果网桥没有对应表项，则创建一个表项，其中表项的状态为“等待”，表项的接收端口为多播加入消息的目的MAC地址对应端口，表项的转发端口列表中包含且只包含接收多播加入消息的端口。表项创建以后，网桥为转发端口列表中的每个端口启动一个定时器(PTimer)，并在端口为该多播组保留资源。最后，网桥把该多播加入消息向多播加入消息的目的MAC地址对应端口进行转发。
如果网桥包含对应表项，且该表项的状态为“等待”，则该网桥检查在该表项的转发端口列表是否已经包含接收多播加入消息的端口。如果不包含，则网桥把该端口加入到转发端口列表中，启动该端口的定时器，并在端口为该多播组保留资源；如果包含，则该网桥重启该端口的定时器。最后，网桥该多播加入消息向多播加入消息的目的MAC地址对应端口进行转发。
如果网桥包含对应表项，且该表项的状态为“完成”，则该网桥检查在该表项的转发端口列表是否已经包含接收多播加入消息的端口。
如果不包含，则网桥把该端口加入到转发端口列表中，启动该端口的定时器，并在端口为该多播组保留资源。接着，该网桥生成一个肯定应答消息，并把该消息发往多播加入消息的发送者； 如果包含，则该网桥重启该端口的定时器。
处理多播离开消息当网桥接收到多播离开消息后，它首先检测自己是否有和该消息对应的表项。并根据结果做以下操作。
如果网桥没有对应表项，或者接收多播离开消息的端口不在对应表项的转发端口列表中，则丢弃该多播离开消息； 如果网桥包含对应表项，且接收多播离开消息的端口在对应表项的转发端口列表中，则该网桥从转发端口列表中删除该端口，并释放在该端口上为该多播组保留的资源。如果删除后转发端口列表为空，则意味着目前已经没有设备需要网桥保留该多播组的注册信息，因此网桥删除该表项，并把多播离开消息向该消息的目的MAC地址对应端口进行转发。
处理肯定应答消息当网桥接收到肯定应答消息后，它首先检测自己是否有和该消息对应的表项。并根据结果做以下操作。
如果网桥没有对应表项，或者接收多播离开消息的端口和对应表项的接收端口不一致，则丢弃该多播离开消息；
如果网桥对应表项的状态为“等待”，且接收多播离开消息的端口和对应表项的接收端口相同，则网桥把该表项的状态改为“完成”，并启动刷新定时器RTimer。最后，该网桥把肯定应答消息向该消息的目的MAC地址对应端口进行转发。
如果网桥对应表项的状态为“完成”，且接收多播离开消息的端口和对应表项的接收端口相同，则网桥检查该消息的目的MAC地址是否是自己的MAC地址，如果不是，该网桥把肯定应答消息向该消息的目的MAC地址对应端口进行转发。
处理否定应答消息当网桥接收到肯定应答消息后，它首先检测自己是否有和该消息对应的表项。并根据结果做以下操作。
如果网桥没有对应表项，或者接收多播离开消息的端口和对应表项的接收端口不一致，则丢弃该多播离开消息； 如果网桥包含对应表项，且接收多播离开消息的端口和对应表项的接收端口相同，则该网桥把该消息向对应表项的转发端口列表中的所有端口转发，并删除该表项，释放所有相关的资源。
处理时钟超时当定时器PTimer超时后，网桥的行为和从该定时器对应端口收到定时器对应表项的多播离开消息相同。
当定时器RTimer超时后，网桥重新启动RTimer，并向RTimer对应表项的多播组的发送者发送多播加入消息。该消息的目的地址为多播组发送者的MAC地址，源地址为网桥的MAC地址。
发送者的行为定义处理多播加入消息当发送者接收到多播加入消息后，首先检测自己是否有和该消息对应的表项。如果没有找到对应的表项，则发送者丢弃该消息。不做任何操作。
如果发送者有对应表项，且接收到多播加入消息的端口在该表项的转发端口列表中，则发送者重启该端口对应的PTimer。
如果发送者有对应表项，且接收到多播加入消息的端口不在该表项的转发端口列表中，则进一步检测是否有足够的资源满足多播加入消息的资源请求。根据检测结果，做如下操作√如果发送者没有足够的资源满足多播加入消息的资源请求，则生成一个否定应答消息，把该消息发往多播加入消息的发送者，并丢弃加入消息。
√如果发送者有足够的资源，则网桥把该端口加入到转发端口列表中，启动该端口的定时器PTimer，并在端口为该多播组保留资源。接着，该发送者生成一个肯定应答消息，并把该消息发往接收者。
处理多播离开消息当发送者接收到多播离开消息后，首先检测自己是否有和该消息对应的表项。如果没有找到对应的表项，则发送者丢弃该消息。不做任何操作。
如果发送者有对应表项，且接收到多播加入消息的端口在该表项的转发端口列表中，则该网桥从转发端口列表中删除该端口，并释放在该端口上为该多播组保留的资源。
如果发送者有对应表项，且接收到多播加入消息的端口不在该表项的转发端口列表中，则发送者丢弃该消息。不做任何操作。
处理肯定应答消息当发送者接收到肯定应答消息后，丢弃该消息，不做任何操作。
处理否定应答消息当发送者接收到否定应答消息后，丢弃该消息，不做任何操作。
接收者的行为定义处理多播加入消息当接收者接收到多播加入消息后，丢弃该消息，不做任何操作。
处理多播离开消息当接收者接收到多播离开消息后，丢弃该消息，不做任何操作。
处理肯定应答消息当接收者接收到肯定应答消息后，启动RTimer，并准备接收多播数据。
处理否定应答消息当接收者接收到否定应答消息后，删除相应的多播表项。
a.发明的实施例我们使用图1中的拓扑来详细说明本发明的实施过程，图中详细给出了网桥的每个端口(用小圆圈表示)。为了能够更清楚地表示资源预留，端口后面还用多个长方形格子给出了该端口资源的占用情况。格子的颜色为深色则表示资源已经被预留，否则表示该资源可用。
设备加入多播组当接收者R1想要接收多播组1的数据时，它生成一个多播加入消息，消息中包括该多播数据的多播组信息，以及需要请求的资源，并把该多播加入消息发送给多播数据的发送者，如图2所示。
当接收者R1所在子网的网桥B2接收到该多播加入消息后，按照处理规则对该消息进行处理。由于B2目前没有该多播表项，且B2的端口p2.2有足够的资源，因此B2创建该表项，把端口p2.1作为该表项的接收端口，并把端口p2.2添加到转发端口列表中，并在端口p2.2上为该多播组保留资源；最后，网桥B2把该消息通过端口p2.1进行转发。如图3所示。
当网桥B1接收到该多播加入消息后，按照处理规则对该消息进行处理。其处理过程和B2类似，即添加多播表项，把端口p1.1作为接收端口，把端口p1.2添加到转发端口列表中，并保留资源，并通过端口p1.1转发该消息。如图4所示。
当发送者S1接收到该多播加入消息后，首先检测是否有足够的资源满足多播加入消息的资源请求。由于发送者有足够的资源，因此把该端口加入到转发端口列表中，启动该端口的定时器PTimer，并在端口为该多播组保留资源。接着，发送者生成一个肯定应答消息，并把该消息发往接收者。肯定应答消息经过网桥B1和B2，最终到达接收者R1。如图5所示。
当另一个接收者R3想要加入多播组时，它同样生成一个多播加入消息，并把该多播加入消息发送给多播数据的发送者。如图6所示。
当接收者R3所在子网的网桥B3接收到该多播加入消息后，由于B3目前没有该多播表项，且B3的端口p3.2有足够的资源，因此B3创建该表项，把端口p3.1作为该表项的接收端口，并把端口p3.2添加到转发端口列表中，并在端口p3.2上为该多播组保留资源；最后，网桥B3把该消息通过端口p3.1进行转发。如图7所示。
当网桥B1接收到该多播加入消息后，检测端口p1.3上是否有足够的资源满足多播加入消息的资源请求。由于B1有足够的资源，因此把该端口加入到转发端口列表中，启动该端口的定时器PTimer，并在端口为该多播组保留资源。由于B1已经有该多播表项，因此B1直接回复肯定应答消息，而无需继续向上转发。肯定应答消息经过网桥B3，最终到达接收者R3。如图8所示。
设备离开多播组当设备R1想要离开网络时，它生成一个多播离开消息，消息中包括该多播数据的多播组信息，并把该多播加入消息发送给多播数据的发送者，如图9所示。
当接收者R1所在子网的网桥B2接收到该多播离开消息后，把端口p2.2从转发端口列表中删除。由于删除后转发端口列表为空，因此网桥B2删除多播表项，并把该消息通过端口p2.1进行转发，如图10所示。
当网桥B1接收到该多播加入消息后，把端口p1.2从转发端口列表中删除。由于删除后转发端口列表还包含p1.3，因此网桥B1并不转发该消息，如图11所示。
状态的定期刷新为了使得本方法能够适应网络拓扑变更和设备当机等意外情况，转发端口列表中的每个端口都有对应的定时器。如果一段时间该端口没有收到多播加入消息，则定时器超时，从而网桥可以把相应端口从转发端口列表中删除。为了防止正常情况下定时器超时，除发送者外所有多播树上的成员都需要定期向上游设备发送多播加入消息，如图12所示。
本发明使以太网系统具有了多播资源预留的能力。由于本发明把多播注册和资源预留结合在一起，因此大大降低了网络中需要传递的消息数目以及网络设备需要维护的状态数目。另外，综合多播和资源预留的解决方案还有助于降低网络中状态不一致的比率。
尽管以上已经结合本发明的优选实施例示出了本发明，但是本领域的技术人员将会理解，在不脱离本发明的精神和范围的情况下，可以对本发明进行各种修改、替换和改变。因此，本发明不应由上述实施例来限定，而应由所附权利要求及其等价物来限定。
权利要求
1.一种在计算机和通信网络中执行多播注册和资源预留的方法，所述方法包括以下步骤当多播数据的接收者要加入多播组时，所述接收者生成多播加入消息，并向多播数据的发送者发送所述多播加入消息；当接收者与发送者之间的多播数据转发路径上的网桥接收到所述多播加入消息时，判断所述网桥是否存在与所述多播加入消息相对应的多播表项；在所述网桥不存在与所述多播加入消息相对应的多播表项的情况下，所述网桥进一步检测是否有足够的资源满足多播加入消息的资源请求；如果存在足够的资源，则所述网桥创建针对所述多播加入消息的多播表项，并接受所述多播加入消息且继续向多播数据的发送者转发；否则，则拒绝所述多播加入消息。
2.根据权利要求1所述的方法，其特征在于在所述网桥存在与所述多播加入消息相对应的多播表项的情况下，所述网桥判断所述多播表项的转发端口列表是否包含接收所述多播加入消息的端口，如果断定所述转发端口列表不包含接收所述多播加入消息的端口，则在转发端口列表中创建所述端口，并在所述端口处为所述多播加入消息预留资源。
3.根据权利要求1所述的方法，其特征在于还包括步骤当多播数据的接收者要离开所述多播组时，所述接收者生成多播离开消息，并向所述多播数据的发送者发送所述多播离开消息；当接收者与发送者之间的多播数据转发路径上的网桥接收到所述多播离开消息时，判断所述网桥是否存在与所述多播离开消息相对应的多播表项；在所述网桥存在与所述多播离开消息相对应的多播表项的情况下，将接收所述多播离开消息的端口从所述多播表项的所述转发列表中删除，并将所述多播离开消息继续向多播数据的发送者转发。
4.根据权利要求3所述的方法，其特征在于在将接收所述多播离开消息的端口从所述多播表项的所述转发列表中删除的步骤之后，还包括步骤如果经过删除后的转发列表为空，则删除与所述转发列表相对应的多播表项。
5.根据权利要求1所述的方法，其特征在于所述拒绝所述多播加入消息的步骤包括由所述网桥产生针对所述多播加入消息的否定应答并向所述接收者转发所述否定应答。
6.根据权利要求5所述的方法，其特征在于当网桥接收到否定应答时，将所述否定应答向自身多播表项中的所有转发端口进行转发。
7.根据权利要求5所述的方法，其特征在于接收到针对所述多播加入消息的否定应答的网桥从其自身中删除与所述多播加入消息相对应的多播表项。
8.根据权利要求3所述的方法，其特征在于在网桥接收到所述多播离开消息之后，所述网桥释放为与所述多播离开消息相对应的多播数据预留的资源。
全文摘要
根据本发明，提出了一种在计算机和通信网络中执行多播注册和资源预留的方法，所述方法包括以下步骤当多播数据的接收者要加入多播组时，所述接收者生成多播加入消息，并向多播数据的发送者发送所述多播加入消息；当接收者与发送者之间的多播数据转发路径上的网桥接收到所述多播加入消息时，判断所述网桥是否存在与所述多播加入消息相对应的多播表项；在所述网桥不存在与所述多播加入消息相对应的多播表项的情况下，所述网桥进一步检测是否有足够的资源满足多播加入消息的资源请求；如果存在足够的资源，则所述网桥创建针对所述多播加入消息的多播表项，并接受所述多播加入消息且继续向多播数据的发送者转发；否则，则拒绝所述多播加入消息。
文档编号H04L29/06GK1996932SQ20051013591
公开日2007年7月11日 申请日期2005年12月31日 优先权日2005年12月31日
发明者吴起, 黄周松 申请人:北京三星通信技术研究有限公司, 三星电子株式会社