保活报文的发送方法和设备的制作方法

文档序号:7766130阅读:273来源:国知局
专利名称:保活报文的发送方法和设备的制作方法
技术领域
本发明涉及通信领域,具体而言,涉及一种保活报文的发送方法和设备。
背景技术
OAM (Operations, Administration and Maintenance,运行管理维护)协议为运营
商提供了一种实时监测链路状态、快速定位链路故障位置以及故障类型的机制,适用于 所有网元的以太网口,例如,将此协议用于接入网网元,用在以太网最后一英里的链路 监控、链路测试以便及时发现链路故障。该协议的主要功能有远端故障指示,远端环 回,链路监控。链路的控制、检测以及激活信息都是由OAM协议数据单元(OAMPDU)承载 的,并且OAMPDU仅在对等的OAM实体间的单一链路上发送,不会被转发。运行OAM 协议的设备在每个状态周期性地发送特定的0AMPDU,默认发送周期是Is。初始状态 时,设备启动一个Is的定时器,设置每秒最大可发送的OAMPDU数,例如,将每秒最大 可发送的OAMPDU的数目置为10。当进入到OAMPDU发送等待状态时,其中发送流程 触发条件之一为定时器超时且前一秒内最大发送报文数目不为10。即发送超时,但 在前一周期内发送了一个或者多个0AMPDU,则发现状态流程重新复位,重置定时器, 重置每秒最大可发送的报文数目。此条件下的复位和重置会引起OAMPDU发送流程的 频繁重起,从而导致OAM发现协商过程因为收包超时而失败,之后又因为发送流程复位 正常,又协商成功。频繁的重启导致发现协商不停地在成功和失败之间震荡,发现协商 的震荡又导致其它的OAM检测功能如环回,链路控制都不可用。下面以路由器和交换机对接为例说明上述发现协商的震荡产生过程,其中,路 由器用A表示,交换机用B表示,双方端口配置为周期都为5s,链路超时定时器都为 6,环回报文超时定时器为6,如图1所示的保活报文发送方法,该方法包括以下步骤步骤S102,A,B的端口都使能OAM功能,双方发现并协商成功;A,B双方每隔一个周期(5s)都会发送一个保活报文给对方,以此来探测链路状 况。A发送一个保活报文给B,B收到后,重置本地链路超时定时器为6,同时发送一个 保活报文给A;步骤S104,A在设定周期内开启环回功能,发送环回报文给B; B收到上述环 回报文后,计算此次和上次收到报文的时间间隔,若小于本地链路超时定时器,则确定 本地链路超时定时器没有超时,重置本地链路超时定时器为6,同时发送一个保活报文给 A;步骤S106,达到下一个周期5s开始时,即上一个发送周期超时,下一个发送周 期开始,准备发送保活报文,但是检测到在前1个周期内发送过多个报文,所以不再发 送保活报文,直接复位,重置发包定时器和最大可发送报文数目,等待下一个周期。步骤S108,到下一个周期IOs开始时,A继续发送保活报文,B收到后计算此 次和上次收到报文的时间间隔,大于本地链路超时时间6,所以断开A、B之间已建立的发现链接。步骤S110,到下一个周期15s开始时,A、B重新协商,A发送报文给B,B回
报文给A,两边重新协商成功,到下一个周期,两边又开始相互发送保活报文。然后A 又发起环回报文,就不断的重复上述步骤S102-S110。由于上述步骤S106中,A检测到上一个周期发送过多个报文,则在本周期内不 再发送保活报文给B,这种处理方式使A、B间的链路一会协商成功,一会断开,发现协 商总是处在震荡状态中。这样就导致其它的如环回,链路控制功能都不可用,链路监控 的数据将不准确。

发明内容
本发明的主要目的在于提供一种保活报文的发送方法和设备,以至少解决上述 发现协商容易发生震荡的问题。根据本发明的一个方面,提供了一种保活报文的发送方法,包括本端设备与 对端设备协商并确定保活报文的发送方式,所述发送方式包括按周期触发的第一发送方 式、按周期与事件结合触发的第二发送方式;所述本端设备根据确定的所述发送方式实 时监测当前情况;所述本端设备监测出所述当前情况满足确定的所述发送方式,向对端 设备发送保活报文。根据本发明的另一方面,提供了一种保活报文的发送设备,包括协商与确定 模块,用于与对端设备协商并确定保活报文的发送方式,所述发送方式包括按周期触发 的第一发送方式、按周期与事件结合触发的第二发送方式;监测模块,用于根据所述协 商与确定模块确定的所述发送方式实时监测当前情况;发送模块,用于所述监测模块监 测出所述当前情况满足确定的所述发送方式,向对端设备发送保活报文。通过本发明,采用协商确定的发送方式发送保活报文,解决了因为保活报文发 送超时或者超时时间设置过短引起的协商震荡问题,增强了链路的稳定性,从而保证了 系统其他功能正常使用。


此处所说明的附图用来提供对本发明的进一步理解,构成本申请的一部分,本 发明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。在附图 中图1是根据相关技术的保活报文发送方法流程图;图2是根据本发明实施例1的保活报文发送方法流程图;图3是根据本发明实施例2的保活报文发送方法流程图;图4是根据本发明实施例3的保活报文发送方法流程图;图5是根据本发明实施例4的保活报文发送设备的结构框图。
具体实施例方式下文中将参考附图并结合实施例来详细说明本发明。需要说明的是,在不冲突 的情况下,本申请中的实施例及实施例中的特征可以相互组合。
本发明实施例是对IEEE802.3AH协议中OAM协议的OAM发送状态机部分的协 议进行的改进,在超时后且前一个周期内发送了一个或者多个OAMPDU的情况下,采取 相应的措施,确保两端设备收到的OAMPDU不超时,从而避免了某些情况下发现协商过 程的震荡,确保了其它功能的稳定使用。基于此,提供了一种保活报文的发送方法和设 备。实施例1图2示出了根据本发明实施例的保活报文的发送方法流程图,该方法包括以下 步骤步骤S202,本端设备与对端设备协商并确定保活报文的发送方式,该发送方式 包括按周期触发的第一发送方式、按周期与事件结合触发的第二发送方式;例如,本端设备与对端设备相互发送协商报文,其中,该协商报文携带有保活 报文的发送方式指示信息;本端设备与对端设备根据收到的协商报文中的指示信息确定 保活报文的发送方式。优选地,本端设备与对端设备根据收到的协商报文中的指示信息确定保活报文 的发送方式包括如果本端设备与对端设备发送的协商报文中的指示信息相同,本端设 备与对端设备确定保活报文的发送方式为指示信息对应的发送方式;如果本端设备与对 端设备发送的协商报文中的指示信息不相同,本端设备与对端设备确定保活报文的发送 方式为以下之一所述第一发送方式、原协议发送方式或第二发送方式。上述协商报文可以为OAM info报文,保活报文的发送方式指示信息占用 OAMinfo报文的OAM配置字段的第五、第六两位表示。例如,在Information OAMPDU 中将Local Information TLV的OAM Configuration字段的第六、第五两位保留位作为info 报文发送类型位即infotype,且该位提供配置,取值分别为00,01,10。若infotype为00,则表示使用协议现有的info报文发送机制,即上述原协议发送 方式。若infotype为01,即上述第一发送方式,表示周期性的发送info报文。即不管 前一个周期发送了多少OAMPDU,超时后,到了一个新的周期,继续发送info报文;该 方式是通过按时的发送info报文来避免接收的超时。若infotype为10,即上述第二发送方式,则表示发送完非info报文后,可以重置
报文发送定时器和计数器;这种重置报文发送定时器触发info报文的发送方式,实际上 就是缩短了 info报文发送的时间。该方式是通过缩短发包时间来保证报文的及时发送, 从而避免对端接收的超时。当两个对接的设备的都启用802.3AH的OAM的功能后,双方开始发送 Information报文进行发现协商,并确定一个info报文的发送方式,处理过程如下1.若两个设备只有一个支持infotype,或者两个设备都不支持infotype,则按照 协议原来的实现,不做任何修改。对不支持的一方来说,收到的infotype不管为何值都直接忽略。不支持的一方 发出的info报文的infotype位为00,支持的一方收到后,将自己的infotype置位00。这 样就将infotpye统一成00,即按照协议原有的实现继续运行。2.若两个设备都支持infotype,且设置的值都一致。
两个设备发送的info报文中的infotype都为01,则发现协商成功后都按照第一发 送方式发送info报文。两个设备发送的info报文中的infotype都为10,则发现协商成功 后都按照第二发送方式发送info报文。3.若两个设备都支持infotype,但设置的值不一致。两个设备发送的info报文中的infotype不一致,一个为01,一个为10时,可以
规定双方选举小的01作为info报文的发送方式,协商成功后按照第一发送方式发送info 报文;当然,也可以规定双方选举大的10作为info报文的发送方式,或者选取原协议发 送方式。协商成功后,按照第二发送方式发送info报文。步骤S204,该本端设备根据确定的发送方式实时监测当前情况;步骤S206,该本端设备监测出当前情况满足确定的发送方式,向对端设备发送 保活报文。若本端设备确定的发送方式为第一发送方式,且监测出当前时刻满足第一发送 方式中的设定周期时,向对端设备发送保活报文。若本端设备确定的发送方式为第二发 送方式,且监测出当前时刻满足第二发送方式中的设定周期,或者监测出向对端设备发 送非保活报文完成时,向对端设备发送保活报文。为了方便实现,本端设备上设置有周期定时器;基于此,本端设备根据确定的 发送方式实时监测当前情况包括本端设备通过周期定时器实时监测当前情况是否满足 确定的发送方式。对应第二发送方式,若监测出向对端设备发送非保活报文完成时,可 以通过重置该周期定时器触发向对端设备发送保活报文。本实施例的设备采用协商确定的发送方式发送保活报文,解决了因为保活报文 发送超时或者超时时间设置过短引起的协商震荡问题,增强了链路的稳定性,从而保证 了系统其他功能正常使用。实施例2本实施例以路由器和交换机对接为例,其中,路由器用A表示,交换机用B表 示,双方端口配置为周期都为5s,链路超时定时器都为6,环回报文超时定时器为6。 本实施例中A,B都启用OAM功能并发现协商成功,同时,A,B按照实施例1中的方 式协商确定的保活报文的发送方式为第一发送方式,即发送类型infotype为01。参见图 3所示的保活报文发送方法,该方法包括以下步骤步骤S302,A,B的端口都使能OAM功能,双方发现并协商成功;A,B双方每隔一个周期(5s)都会发送一个保活报文给对方,以此来探测链路状 况。A发送一个保活报文给B,B收到后,重置本地链路超时定时器为6,同时发送一个 保活报文给A;步骤S304,A在设定周期内开启环回功能,发送环回报文给B; B收到上述环 回报文后,计算此次和上次收到报文的时间间隔,若小于本地链路超时定时器,则确定 本地链路超时定时器没有超时,重置本地链路超时定时器为6,同时发送一个保活报文给 A;步骤S306,达到下一个周期5s开始时,即上一个发送周期超时,下一个发送周 期开始,尽管检测到前一个周期发送超时,并且在前一个周期内发送了多个OAM报文, 本周期到达后,仍然向B发送保活报文。
步骤S308,到下一个周期IOs开始时,A继续发送保活报文,B收到后计算此 次和上次收到报文的时间间隔,小于本地链路超时时间6,则确定本地链路超时定时器没 有超时,重置本地链路超时定时器为6,同时向A发送保活报文。步骤S310,到下一个周期15s开始时,A继续发送保活报文给B,B收到后,计 算此次和上次收到报文的时间间隔小于本地链路超时定时器,没有超时。重置本地链路 超时定时器为6,同时发送一个保活报文给A。该方案是每到一个新的周期都正常发送保活报文,而不管前一个周期发了多少 报文;这样就避免了因为保活报文发送超时或者超时时间设置过短引起的协商震荡,增 强了链路的稳定性,从而保证了其他功能正常使用。实施例3本实施例以路由器和交换机对接为例,其中,路由器用A表示,交换机用B表 示,双方端口配置为周期都为5s,链路超时定时器都为6,环回报文超时定时器为6。 本实施例中A,B都启用OAM功能并发现协商成功,同时,A,B按照实施例1中的方 式协商确定的保活报文的发送方式为第二发送方式,即发送类型infotype为10。参见图 4所示的保活报文发送方法,该方法包括以下步骤步骤S402,A,B的端口都使能OAM功能,双方发现并协商成功;A,B双方每隔一个周期(5s)都会发送一个保活报文给对方,以此来探测链路状 况。A发送一个保活报文给B,B收到后,重置本地链路超时定时器为6,同时发送一个 保活报文给A;步骤S404,A在设定周期内开启环回功能,发送环回报文给B; B收到上述环 回报文后,计算此次和上次收到报文的时间间隔,若小于本地链路超时定时器,则确定 本地链路超时定时器没有超时,重置本地链路超时定时器为6,同时发送一个保活报文给 A;步骤S406,达到3s时,A监测到环回报文发送成功后,向B发送保活报文。B 收到后,计算此次和上次收到报文的时间间隔小于本地链路超时定时器6,没有超时,则 重置本地链路超时定时器为6,同时发送一个保活报文给A ;本实施例中,A监测到环回报文发送成功后,A可以立刻重置本地发包定时器以 及最大发送报文数目,定时器重置后,图中的3s时刻就是一个新的周期的开始。定时器 重置后3s就是一个新的周期的开始,则发送保活报文给B ;步骤S408,到新的周期8s时,A继续发送保活报文给B,B收到后,计算此次 和上次收到报文的时间间隔小于本地链路超时定时器,没有超时。重置本地链路超时定 时器为6,同时发送一个保活报文给A ;本实施例是在发送周期内若有多个非info报文的发送,则非info发送完后,通过 重置发包定时器来缩短保活报文的发包时间,从而保证了保活报文的发送,避免了对端 因为接收超时或者超时时间设置过短引起的协商震荡,增强了链路的稳定性,从而保证 了其他功能正常使用。实施例4图5示出了根据本发明实施例的保活报文的发送设备的结构框图,该设备包 括
协商与确定模块52,用于与对端设备协商并确定保活报文的发送方式,该发送 方式包括按周期触发的第一发送方式、按周期与事件结合触发的第二发送方式;监测模块54,与协商与确定模块52相连,用于根据协商与确定模块确定的发送 方式实时监测当前情况;发送模块56,与监测模块54相连,用于监测模块监测出当前情况满足确定的发 送方式,向对端设备发送保活报文。其中,协商与确定模块52包括协商报文发送单元,用于与对端设备相互发送协商报文,其中,该协商报文携 带有保活报文的发送方式指示信息;确定单元,用于根据收到的协商报文中的指示信息确定保活报文的发送方式。 例如如果本端设备与对端设备发送的协商报文中的指示信息不相同,本端设备与对端 设备确定保活报文的发送方式为以下之一所述第一发送方式、原协议发送方式或第二 发送方式。上述协商报文可以为OAM info报文,保活报文的发送方式指示信息占用 OAMinfo报文的OAM配置字段的第五、第六两位表示。例如,在Information OAMPDU 中将Loeal Information TLV的OAM Configuration字段的第六、第五两位保留位作为info 报文发送类型位即infotype,且该位提供配置,取值分别为00,01,10。若infotype为00,则表示使用协议现有的info报文发送机制,即上述原协议发送 方式。若infotype为01,即上述第一发送方式,表示周期性的发送info报文。即不管 前一个周期发送了多少OAMPDU,超时后,到了一个新的周期,继续发送info报文;该 方式是通过按时的发送info报文来避免接收的超时。若infotype为10,即上述第二发送方式,则表示发送完非info报文后,可以重置
报文发送定时器和计数器;这种重置报文发送定时器触发info报文的发送方式,实际上 就是缩短了 info报文发送的时间。该方式是通过缩短发包时间来保证报文的及时发送, 从而避免对端接收的超时。当两个对接的设备的都启用802.3AH的OAM的功能后,双方开始发送 Information报文进行发现协商,并确定一个info报文的发送方式,处理过程如下1.若两个设备只有一个支持infotype,或者两个设备都不支持infotype,则按照 协议原来的实现,不做任何修改。对不支持的一方来说,收到的infotype不管为何值都直接忽略。不支持的一方 发出的info报文的infotype位为00,支持的一方收到后,将自己的infotype置位00。这 样就将infotpye统一成00,即按照协议原有的实现继续运行。2.若两个设备都支持infotype,且设置的值都一致。两个设备发送的info报文中的infotype都为01,则发现协商成功后都按照第一发 送方式发送info报文。两个设备发送的info报文中的infotype都为10,则发现协商成功 后都按照第二发送方式发送info报文。3.若两个设备都支持infotype,但设置的值不一致。两个设备发送的info报文中的infotype不一致,一个为01,一个为10时,可以规定双方选举小的01作为info报文的发送方式,协商成功后按照第一发送方式发送info 报文;当然,也可以规定双方选举大的10作为info报文的发送方式,或者选取原协议发 送方式。协商成功后,按照第二发送方式发送info报文。基于上述第一发送方式,发送模块56可以包括第一判断单元,用于协商与确定模块确定的发送方式为第一发送方式时,判断 监测出的当前时刻是否满足第一发送方式中的设定周期;第一发送单元,用于第一判断单元的判断结果为是时,向对端设备发送保活报 文。基于上述第一发送方式,发送模块56可以包括第二判断单元,用于协商与确定模块确定的发送方式为第二发送方式时,判断 监测出的当前时刻是否满足第二发送方式中的设定周期,或者判断是否监测出向对端设 备发送非保活报文已完成;第二发送单元,用于第二判断单元的判断结果为是时,向对端设备发送保活报 文。为了方便实现,上述设备上设置有周期定时器;基于此,上述监测模块54用于 通过周期定时器实时监测当前情况是否满足确定的发送方式。本实施例的设备采用协商确定的发送方式发送保活报文,解决了因为保活报文 发送超时或者超时时间设置过短引起的协商震荡问题,增强了链路的稳定性,从而保证 了系统其他功能正常使用。以上实施例是在对已有OAM报文发送流程改动及影响最小的情况下规避了发现 协商的震荡,可以避免一些特殊情况下引发的超时问题,避免了发现协商的来回震荡, 提高了 OAM链路监控和检测的效率以及准确性。另外,通过本端设备与对端设备双方 协商保活报文的发送方式,还可以完全兼容原有协议的处理。显然,本领域的技术人员应该明白,上述的本发明的各模块或各步骤可以用通 用的计算装置来实现,它们可以集中在单个的计算装置上,或者分布在多个计算装置所 组成的网络上,可选地,它们可以用计算装置可执行的程序代码来实现,从而,可以将 它们存储在存储装置中由计算装置来执行,并且在某些情况下,可以以不同于此处的顺 序执行所示出或描述的步骤,或者将它们分别制作成各个集成电路模块,或者将它们中 的多个模块或步骤制作成单个集成电路模块来实现。这样,本发明不限制于任何特定的 硬件和软件结合。以上所述仅为本发明的优选实施例而已,并不用于限制本发明,对于本领域的 技术人员来说,本发明可以有各种更改和变化。凡在本发明的精神和原则之内,所作的 任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
权利要求
1.一种保活报文的发送方法,其特征在于,包括本端设备与对端设备协商并确定保活报文的发送方式,所述发送方式包括按周期触 发的第一发送方式、按周期与事件结合触发的第二发送方式;所述本端设备根据确定的所述发送方式实时监测当前情况;所述本端设备监测出所述当前情况满足确定的所述发送方式,向对端设备发送保活 报文。
2.根据权利要求1所述的方法,其特征在于,所述本端设备与对端设备协商并确定保 活报文的发送方式包括本端设备与对端设备相互发送协商报文,其中,所述协商报文携带有保活报文的发 送方式指示信息;所述本端设备与对端设备根据收到的所述协商报文中的指示信息确定所述保活报文 的发送方式。
3.根据权利要求2所述的方法,其特征在于,所述本端设备与对端设备根据收到的所 述协商报文中的指示信息确定所述保活报文的发送方式包括如果所述本端设备与所述对端设备发送的所述协商报文中的指示信息相同,所述本 端设备与所述对端设备确定所述保活报文的发送方式为所述指示信息对应的发送方式;如果所述本端设备与所述对端设备发送的所述协商报文中的指示信息不相同,所述 本端设备与所述对端设备确定所述保活报文的发送方式为以下之一所述第一发送方 式、原协议发送方式或第二发送方式。
4.根据权利要求2所述的方法,其特征在于,所述协商报文为运行管理维护信息 OAM info报文,所述保活报文的发送方式指示信息占用所述OAM info报文的OAM配置 字段的第五、第六两位表示。
5.根据权利要求1所述的方法,其特征在于,所述本端设备监测出所述当前情况满足 确定的所述发送方式,向对端设备发送保活报文包括所述本端设备确定的所述发送方式为所述第一发送方式,且监测出当前时刻满足所 述第一发送方式中的设定周期时,向对端设备发送保活报文。
6.根据权利要求1所述的方法,其特征在于,所述本端设备监测出所述当前情况满足 确定的所述发送方式,向对端设备发送保活报文包括所述本端设备确定的所述发送方式为所述第二发送方式,且监测出当前时刻满足所 述第二发送方式中的设定周期,或者监测出向所述对端设备发送非保活报文完成时,向 所述对端设备发送保活报文。
7.根据权利要求1-6任一项所述的方法,其特征在于,所述本端设备上设置有周期定 时器;所述本端设备根据确定的所述发送方式实时监测当前情况包括所述本端设备通 过所述周期定时器实时监测当前情况是否满足确定的所述发送方式。
8.—种保活报文的发送设备,其特征在于,包括协商与确定模块,用于与对端设备协商并确定保活报文的发送方式,所述发送方式 包括按周期触发的第一发送方式、按周期与事件结合触发的第二发送方式;监测模块,用于根据所述协商与确定模块确定的所述发送方式实时监测当前情况;发送模块,用于所述监测模块监测出所述当前情况满足确定的所述发送方式,向对端设备发送保活报文。
9.根据权利要求8所述的设备,其特征在于,所述协商与确定模块包括协商报文发送单元,用于与对端设备相互发送协商报文,其中,所述协商报文携带 有保活报文的发送方式指示信息;确定单元,用于根据收到的所述协商报文中的指示信息确定所述保活报文的发送方式。
10.根据权利要求8所述的设备,其特征在于,所述发送模块包括第一判断单元,用于所述协商与确定模块确定的所述发送方式为所述第一发送方式 时,判断监测出的当前时刻是否满足所述第一发送方式中的设定周期;第一发送单元,用于所述第一判断单元的判断结果为是时,向所述对端设备发送保 活报文。
11.根据权利要求8所述的设备,其特征在于,所述发送模块包括第二判断单元,用于所述协商与确定模块确定的所述发送方式为所述第二发送方式 时,判断监测出的当前时刻是否满足所述第二发送方式中的设定周期,或者判断是否监 测出向所述对端设备发送非保活报文已完成;第二发送单元,用于所述第二判断单元的判断结果为是时,向所述对端设备发送保 活报文。
全文摘要
本发明提供了一种保活报文的发送方法和设备。其中,该方法包括本端设备与对端设备协商并确定保活报文的发送方式,该发送方式包括按周期触发的第一发送方式、按周期与事件结合触发的第二发送方式;该本端设备根据确定的所述发送方式实时监测当前情况;该本端设备监测出所述当前情况满足确定的所述发送方式,向对端设备发送保活报文。根据本发明,解决了因为保活报文发送超时或者超时时间设置过短引起的协商震荡问题,增强了链路的稳定性,从而保证了系统其他功能正常使用。
文档编号H04L12/24GK102014054SQ20101055582
公开日2011年4月13日 申请日期2010年11月22日 优先权日2010年11月22日
发明者奚峰, 孟丽丽, 王涛 申请人:中兴通讯股份有限公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1