CN106375242A - 通告消息处理方法及系统 - Google Patents

通告消息处理方法及系统 Download PDF

Info

Publication number
CN106375242A
CN106375242A CN201510428333.9A CN201510428333A CN106375242A CN 106375242 A CN106375242 A CN 106375242A CN 201510428333 A CN201510428333 A CN 201510428333A CN 106375242 A CN106375242 A CN 106375242A
Authority
CN
China
Prior art keywords
message
msg
transmitting terminal
receiving
receiving terminal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201510428333.9A
Other languages
English (en)
Other versions
CN106375242B (zh
Inventor
姚燕
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ZTE Corp
Original Assignee
ZTE Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ZTE Corp filed Critical ZTE Corp
Priority to CN201510428333.9A priority Critical patent/CN106375242B/zh
Priority to PCT/CN2016/075666 priority patent/WO2016177078A1/zh
Publication of CN106375242A publication Critical patent/CN106375242A/zh
Application granted granted Critical
Publication of CN106375242B publication Critical patent/CN106375242B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
    • H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/50—Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明涉及一种通告消息处理方法及系统，其方法包括：发送端向接收端发送第一报文，在第一报文中携带通告消息标识MSG_ID对象；在MSG_ID发生翻转后，发送端向所述接收端发送的第一个第一报文中的MSG_ID对象的Flags字段置上翻转标记，之后发送的第一报文中的MSG_ID对象的Flags字段清除所述翻转标记；接收端接收处理第一个第一报文，并从接收到的来自发送端的第二个第一报文开始，将收到的第一报文中的MSG_ID对象与前一第一报文进行比较，根据比较结果处理接收到的第一报文。本发明通过发送端的信令通告，使得接收端得知消息标识符是否发生翻转，从而使得接收端能够正确处理报文，提高了系统报文处理性能。

Description

通告消息处理方法及系统
技术领域
本发明涉及数据网络通讯技术领域，尤其涉及一种RSVP-TE(Resource Reservation Protocol-Traffic Engineer，基于流量工程的资源预留协议)的消息确认与重传技术中的通告消息处理方法及系统。
背景技术
RSVP协议是一种典型的“软状态协议”，其相关的LSP(LabelSwitch Path，标签交换通道)状态信息必须依靠定时的刷新消息才能够维持，一旦在规定的时间内某个RSVP节点没能收到刷新消息，则其相关的LSP状态将被拆除。基于RSVP的这种特性，当其隧道数量达到某个量级(比如几千条)之后，为了维持这些隧道的刷新消息将会对整个系统的负荷造成很大压力，将很多带宽流量都花费在维持已有隧道的功能上面。
为了减少刷新消息所产生的流量负荷，以更有效地利用有限的系统资源，RFC2961提出了多种减少刷新消息的方式，包括消息确认与重传、捆绑发送、摘要刷新等。虽然，这些方式的具体实现方式各异，但是本质都可以归结为：使用一个RSVP报文，刷新尽可能多的LSP，从而减少需要用来刷新的RSVP报文总量，最终减少刷新报文对整个系统负荷的压力。
其中，消息确认与重传的优势在于刷新消息的接收端不用创建或更新状态块，不用比较消息中各对象等操作，从而减少刷新消息所产生的流量负荷，更加有效的利用有限的系统资源。
此外，利用消息确认与重传机制中Epoch和消息标识符(以下文中简称MSG_ID)两个数据的组合，还可以用来检查乱序报文，乱序的报文应该被丢弃。
RSVP节点收到MESSAGE_ID对象时，和前面收到的对象相比，若Epoch不变，而MSG_ID数值变小，当MSG_ID没有发生翻转时，则认为收到了乱序报文。但是MSG_ID是发送方设置的，接收端没有有效的方法判断此数值是否发生翻转。因此，使得接收端无法正确处理报文。
发明内容
本发明实施例提供一种通告消息处理方法及系统，旨在实现RSVP协议中消息确认与重传机制下，接收端无法判断MSG_ID数值是否发生翻转，导致接收端无法正确处理报文的技术问题。
本发明实施例提出的一种通告消息处理方法，包括：
发送端向接收端发送第一报文，在所述第一报文中携带通告消息标识MSG_ID对象；
在MSG_ID发生翻转后，所述发送端向所述接收端发送的第一个第一报文中的MSG_ID对象的Flags字段置上翻转标记，之后发送的第一报文中的MSG_ID对象的Flags字段清除所述翻转标记；
所述接收端接收处理所述第一个第一报文，并从接收到的来自所述发送端的第二个第一报文开始，将收到的第一报文中的MSG_ID对象与前一第一报文进行比较，根据比较结果处理接收到的第一报文。
优选地，所述接收端从接收到的来自所述发送端的第二个第一报文开始，将收到的第一报文中的MSG_ID对象与前一第一报文进行比较，根据比较结果处理接收到的第一报文的步骤包括：
所述接收端从接收到的来自所述发送端的第二个第一报文开始，将收到的第一报文中的MSG_ID对象与前一第一报文的MSG_ID对象进行比较；
若当前接收到的第一报文中的MSG_ID对象的Epoch字段值变化，则判断所述发送端重启，接收处理当前接收到的第一报文；
若当前接收到的第一报文中的MSG_ID对象的Epoch字段值未变化，且MSG_ID不变，则判断此报文是刷新报文，更新本地状态块超时时间；
若当前接收到的第一报文中的MSG_ID对象的Epoch字段值未变化，且MSG_ID变大，则判断此报文是触发报文，接收处理此报文；
若当前接收到的第一报文中的MSG_ID对象的Epoch字段值未变化，且MSG_ID变小，Flags字段未置翻转标记，则判断此报文是乱序报文，丢弃该报文；
若当前接收到的第一报文中的MSG_ID对象的Epoch字段值未变化，且MSG_ID变小，Flags字段置上翻转标记，则判断此报文是触发报文，接收处理此报文。
优选地，所述接收端为所述接收端与发送端之间建立的隧道的上游节点，所述发送端为所述隧道的下游节点，所述发送端发送的第一报文为RESV报文、RESV-TEAR报文或PATH-ERR报文中的一种。
优选地，所述接收端为所述隧道的下游节点，所述发送端为所述隧道的上游节点，所述发送端发送的第一报文为PATH报文、PATH-TEAR报文、RESV-ERR报文或RESV-CONF报文中的一种。
优选地，所述接收端接收处理所述第一个第一报文的步骤包括：
所述接收端在接收到所述发送端发送的第一个第一报文时，保存所述第一个第一报文携带的MESSAGE-ID对象，并处理该报文。
本发明实施例还提出一种通告消息处理系统，包括：接收端和发送端；其中：
所述发送端，用于向接收端发送第一报文，在所述第一报文中携带通告消息标识MSG_ID对象；在MSG_ID发生翻转后，向所述接收端发送的第一个第一报文中的MSG_ID对象的Flags字段置上翻转标记，之后发送的第一报文中的MSG_ID对象的Flags字段清除所述翻转标记；
所述接收端，用于接收处理所述第一个第一报文，并从接收到的来自所述发送端的第二个第一报文开始，将收到的第一报文中的MSG_ID对象与前一第一报文进行比较，根据比较结果处理接收到的第一报文。
优选地，所述接收端，还用于从接收到的来自所述发送端的第二个第一报文开始，将收到的第一报文中的MSG_ID对象与前一第一报文的MSG_ID对象进行比较；若当前接收到的第一报文中的MSG_ID对象的Epoch字段值变化，则判断所述发送端重启，接收处理当前接收到的第一报文；若当前接收到的第一报文中的MSG_ID对象的Epoch字段值未变化，且MSG_ID不变，则判断此报文是刷新报文，更新本地状态块超时时间；若当前接收到的第一报文中的MSG_ID对象的Epoch字段值未变化，且MSG_ID变大，则判断此报文是触发报文，接收处理此报文；若当前接收到的第一报文中的MSG_ID对象的Epoch字段值未变化，且MSG_ID变小，Flags字段未置翻转标记，则判断此报文是乱序报文，丢弃该报文；若当前接收到的第一报文中的MSG_ID对象的Epoch字段值未变化，且MSG_ID变小，Flags字段置上翻转标记，则判断此报文是触发报文，接收处理此报文。
优选地，所述接收端为所述隧道的上游节点，所述发送端为所述隧道的下游节点，所述发送端发送的第一报文为RESV报文、RESV-TEAR报文或PATH-ERR报文中的一种。
优选地，所述接收端为所述隧道的下游节点，所述发送端为所述隧道的上游节点，所述发送端发送的第一报文为PATH报文、PATH-TEAR报文、RESV-ERR报文或RESV-CONF报文中的一种。
优选地，所述接收端，还用于在接收到所述发送端发送的第一个第一报文时，保存所述第一个第一报文携带的MESSAGE-ID对象，并处理该报文。
本发明实施例提出的一种通告消息处理方法及系统，发送端向接收端发送第一报文，在第一报文中携带通告消息标识MSG_ID对象；在MSG_ID发生翻转后，发送端向接收端发送的第一个第一报文中的MSG_ID对象的Flags字段置上翻转标记，之后发送的第一报文中的MSG_ID对象的Flags字段清除所述翻转标记；接收端接收处理所述第一个第一报文，并从接收到的来自发送端的第二个第一报文开始，将收到的第一报文中的MSG_ID对象与前一第一报文进行比较，根据比较结果处理接收到的第一报文，由此通过发送端的信令通告，使得接收端得知消息标识符是否发生翻转，从而使得接收端能够正确处理报文，提高了系统报文处理性能。
附图说明
图1是RFC2961中定义的MESSAGE-ID对象的格式示意图；
图2是本发明通告消息处理方法较佳实施例的流程示意图；
图3是本发明实施例中单邻居网络拓扑图；
图4是本发明实施例中多邻居网络拓扑图；
图5是本发明通告消息处理系统较佳实施例的结构示意图。
为了使本发明的技术方案更加清楚、明了，下面将结合附图作进一步详述。
具体实施方式
应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
本发明实施例的主要解决方案是：基于RSVP-TE的消息确认与重传技术，发送端向接收端发送第一报文，在第一报文中携带通告消息标识MSG_ID对象；在MSG_ID发生翻转后，发送端向接收端发送的第一个第一报文中的MSG_ID对象的Flags字段置上翻转标记，之后发送的第一报文中的MSG_ID对象的Flags字段清除所述翻转标记；接收端接收处理第一个第一报文，并从接收到的来自发送端的第二个第一报文开始，将收到的第一报文中的MSG_ID对象与前一第一报文进行比较，根据比较结果处理接收到的第一报文，由此通过发送端的信令通告，使得接收端得知消息标识符是否发生翻转，从而接收端能够正确处理报文。
这里简单介绍一下本发明实施例中涉及的消息确认与重传技术。
首先介绍两个概念，触发消息和刷新消息。
触发消息，是包括了通告之前没有传输过的状态和信息的RSVP消息。该触发消息包括通告新状态，改变预约路径的路由变化，对已存在的RSVP会话或者预约做出改变的消息。触发消息的接收者需要完全接收处理此消息，创建或更新状态块，比较消息中各对象等操作。
刷新消息，表示之前已经通告过的状态，它包含与之前的RSVP消息相同的对象和信息，并沿着相同的路径进行转发。刷新消息的接收者不需要完全处理此消息，只需要更新本地状态块超时时间，保证状态块不会老化。
消息确认与重传机制的原理如下：
通过在触发消息中携带MESSAGE-ID对象，当邻居接收到该消息时，向消息发送者确认接收到该消息。若消息发送者一定时间内没有收到消息确认，则会重传该消息。确认消息通过捎带方式或者确认消息进行确认，消息确认与重传机制只应用于触发消息，对于PATH和RESV的刷新消息，则不需要进行确认操作。可以简单地认为，一个MESSAGE-ID对象对应一个消息状态，触发消息的MESSAGE-ID对象是变化的，刷新消息的MESSAGE-ID对象不变。消息接收者根据MESSAGE-ID对象的变化，就能预先判断消息的处理策略。
消息确认与重传的优势在于刷新消息的接收端不用创建或更新状态块，不用比较消息中各对象等操作，从而减少刷新消息所产生的流量负荷，更加有效的利用有限的系统资源。
此外，在RFC2961中定义了MESSAGE-ID对象的格式，如图1所示。
MESSAGE-ID对象各字段含义为：
Flags：8位，0x01＝ACK_Desired flag，表示发送方发送的消息需要接收方的确认回复。
Epoch：24位，这个字段除非发生了系统或者RSVP模块的重启，否则不会改变。一旦发生了重启事件，则此字段的值应该随机产生，并不同于重启前的值。这样，此字段可以用来标识某个RSVP节点是否发生了重启。
MESSAGE_IDentifier:32位，消息标识符(以下文中简称MSG_ID)，与产生消息的IP地址一起，唯一确定一个消息。对于触发消息，该数据是不断增加的，对于刷新消息，该数据不变。只有在两种情况下会减少：一是当Epoch发生重置，一是该数据发生翻转。
由于MSG_ID在正常情况下是不会变小的，所以Epoch和MSG_ID两个数据的组合，还可以用来检查乱序报文，乱序的报文应该被丢弃。
RSVP节点收到MESSAGE_ID对象时，和前面收到的对象相比，若Epoch不变，而MSG_ID数值变小，当MSG_ID没有发生翻转时，则认为收到了乱序报文。但是MSG_ID是发送方设置的，接收方没有有效的方法判断此数值是否发生翻转。
为了解决这个问题，本发明实施例提出了一种通告消息处理方法，发送方通过信令通告给接收方消息标识符是否发生翻转，从而使得接收方能正确处理报文。
具体地，如图2所示，本发明较佳实施例提出一种通告消息处理方法，包括：
步骤S101，发送端向接收端发送第一报文，在所述第一报文中携带通告消息标识MSG_ID对象；
只要节点部署了重传与确认功能，隧道建立过程，和隧道建立成功后，发送端向接收端发送的报文都携带MSG_ID对象。
步骤S102，在MSG_ID发生翻转后，所述发送端向所述接收端发送的第一个第一报文中的MSG_ID对象的Flags字段置上翻转标记，之后发送的第一报文中的MSG_ID对象的Flags字段清除所述翻转标记；
本实施例扩展MESSAGE-ID对象的Flags字段含义，增加定义：
0x02＝MESSAGE_IDentifier wrapped flag，表示发送端的MSG_ID发生了翻转。
MSG_ID发生翻转后，发送端向不同接收端发送的第一个MESSAGE-ID对象的Flags字段置上0x02标记，向同一个接收端发送的第二个MESSAGE-ID对象开始，Flags字段清除0x02标记。
步骤S103，所述接收端从接收到的来自所述发送端的第二个第一报文开始，将收到的第一报文中的MSG_ID对象与前一第一报文进行比较，根据比较结果处理接收到的第一报文。
具体地，对于接收端，对收到的MESSAGE-ID对象进行解析。
接收端在接收到发送端发送的第一个第一报文时，保存第一个第一报文携带的MESSAGE-ID对象，并处理该报文。
后续，接收端从接收到的来自发送端的第二个第一报文开始，将收到的第一报文中的MSG_ID对象与前一第一报文的MSG_ID对象进行比较；
若当前接收到的第一报文中的MSG_ID对象的Epoch字段值变化，则判断所述发送端重启，接收处理当前接收到的第一报文；
若当前接收到的第一报文中的MSG_ID对象的Epoch字段值未变化，且MSG_ID不变，则判断此报文是刷新报文，只更新本地状态块超时时间，保证状态块不老化；
若当前接收到的第一报文中的MSG_ID对象的Epoch字段值未变化，且MSG_ID变大，则判断此报文是触发报文，接收处理此报文；
若当前接收到的第一报文中的MSG_ID对象的Epoch字段值未变化，且MSG_ID变小，Flags字段未置翻转标记，则判断此报文是乱序报文，丢弃该报文；
若当前接收到的第一报文中的MSG_ID对象的Epoch字段值未变化，且MSG_ID变小，Flags字段置上翻转标记，则判断此报文是触发报文，接收处理此报文。
本实施例通过上述方案，发送端向接收端发送第一报文，在第一报文中携带通告消息标识MSG_ID对象；在MSG_ID发生翻转后，发送端向接收端发送的第一个第一报文中的MSG_ID对象的Flags字段置上翻转标记，之后发送的第一报文中的MSG_ID对象的Flags字段清除所述翻转标记；接收端接收处理第一个第一报文，并从接收到的来自发送端的第二个第一报文开始，将收到的第一报文中的MSG_ID对象与前一第一报文进行比较，根据比较结果处理接收到的第一报文，由此通过发送端的信令通告，使得接收端得知消息标识符是否发生翻转，从而使得接收端能够正确处理报文，提高了系统报文处理性能。
需要说明的是，本实施例中接收端与发送端可以分别对应所建立隧道的上游节点和下游节点，两者也可以互换。若接收端为隧道的上游节点，发送端为隧道的下游节点，则发送端发送的第一报文为RESV报文、RESV-TEAR报文或PATH-ERR报文中的一种，接收端发送的第二报文为PATH报文、PATH-TEAR报文、RESV-ERR报文或RESV-CONF报文中的一种。
若接收端为隧道的下游节点，发送端为隧道的上游节点，则发送端发送的第一报文为PATH报文、PATH-TEAR报文、RESV-ERR报文或RESV-CONF报文中的一种，接收端发送的第二报文为RESV报文、RESV-TEAR报文或PATH-ERR报文中的一种。
以下结合具体实例对本发明实施例方案进行详细阐述：
参考图3所示，从R1(上游节点)到R2(下游节点)建一条TE隧道，两节点均部署消息确认与重传功能。
建路过程，R1发送PATH报文(携带MESSAGE-ID对象)到R2，R2收到PATH报文后回复RESV报文(携带MESSAGE-ID对象)发给R1，R1收到RESV报文后，隧道建立。
之后两节点间通过刷新报文刷新状态块，保持状态块不老化(刷新报文也携带MESSAGE-ID对象)。
由于R1和R2都可以作为MESSAGE-ID对象的发送端和接收端，下面以实例分别进行描述。
实例1——隧道的上游节点R1作为发送方，下游节点作为接收方
R1作为MESSAGE-ID对象的发送方的处理过程如下：
1、建路过程，R1发送的PATH报文中携带MESSAGE-ID对象，Flags字段未置0x02标记，MSG_ID全局加1。
说明：MSG_ID全局分配，保证唯一。不同隧道不同状态，MSG_ID都不同。
2、TE隧道建立之后，隧道状态通过刷新报文进行刷新，刷新PATH报文中的MSG_ID保持不变。
3、当R1上状态发生变化，需要发送触发报文时，MSG_ID全局加1。
4、当MSG_ID发生翻转后，向R2发送的第一个PATH报文中的MESSAGE-ID对象的Flags置上0x02标记，之后的PATH报文中的MESSAGE-ID对象的Flags清除0x02标记。
R2作为MESSAGE-ID对象的接收方的处理过程如下：
1、建路过程，R2收到第一个PATH报文中携带的MESSAGE-ID对象，直接保存Epoch和MSG_ID，完全接收处理PATH报文，然后向R1回复RESV报文。
2、R2从收到第二个PATH报文开始，将收到PATH报文中的MESSAGE-ID对象和之前收到的进行比较，根据结果处理PATH报文：
①若Epoch变化，则认为发送方重启，完全接收处理此报文；
②若Epoch未变化，MSG_ID不变，则认为此报文是刷新报文，只更新本地状态块超时时间，保证状态块不老化；
③若Epoch未变化，MSG_ID变大，则认为此报文是触发报文，完全接收处理此报文；
④若Epoch未变化，MSG_ID变小，Flags未置0x02标记，则认为此报文是乱序报文，丢弃该报文；
⑤若Epoch未变化，MSG_ID变小，Flags置上0x02标记，则认为此报文是触发报文，完全接收处理此报文。
实例2——隧道的下游节点作为发送方，上游节点作为接收方
R2作为MESSAGE-ID对象的发送方的处理过程如下：
1、建路过程，R2发送的RESV报文中携带MESSAGE-ID对象，Flags
字段未置0x02标记，MSG_ID全局加1。
说明：MSG_ID全局分配，保证唯一。不同隧道不同状态，MSG_ID都不同。
2、TE隧道建立之后，隧道状态通过刷新报文进行刷新，刷新RESV中的MSG_ID保持不变。
3、当R2上状态发生变化，需要发送触发报文时，MSG_ID全局加1。
4、当MSG_ID发生翻转后，向R1发送的第一个RESV报文中的MESSAGE-ID对象的Flags置上0x02标记，之后的RESV报文中的MESSAGE-ID对象的Flags清除0x02标记。
R1作为MESSAGE-ID对象的接收方的处理过程如下：
1、建路过程，R1收到第一个RESV报文中携带的MESSAGE-ID对象，直接保存Epoch和MSG_ID，完全接收处理RESV报文。
2、R1从收到第二个RESV报文开始，将收到RESV报文中的MESSAGE-ID对象和之前收到的进行比较，根据结果处理RESV报文：
①若Epoch变化，则认为发送方重启，完全接收处理此报文；
②若Epoch未变化，MSG_ID不变，则认为此报文是刷新报文，只更新本地状态块超时时间，保证状态块不老化；
③若Epoch未变化，MSG_ID变大，则认为此报文是触发报文，完全接收处理此报文；
④若Epoch未变化，MSG_ID变小，Flags未置0x02标记，则认为此报文是乱序报文，丢弃该报文；
⑤若Epoch未变化，MSG_ID变小，Flags置上0x02标记，则认为此报文是触发报文，完全接收处理此报文。
实例3——发送方有多个邻居
如果R1上就建一条隧道，MSG_ID翻转的可能性不大。参考附图4，当从R1建隧道到很多不同邻居(R2，R3，R4等)，且到每个邻居都建很多条隧道(上千条)时，每条隧道就占一个MSG_ID，当隧道的状态频繁变化时，MSG_ID数值增长的就比较快，这时MSG_ID就可能发生翻转。
如图4所示，R1节点当MSG_ID发生翻转后，分别发送给R2、R3、R4的第一个MESSAGE-ID对象的Flags字段置上0x02标记，表示MSG_ID发生翻转。发送给同一个邻居的第二个MESSAGE-ID对象开始，Flags字段清除0x02标记。不同接收方的处理和前面描述的实例1的R2作为接收方的行为相同，这里不再赘述。
通过上述方法，MSG_ID的接收方可以正确判断发送方的MSG_ID是否发生翻转，从而可以正确处理接收报文。
如图5所示，本发明较佳实施例还提出一种通告消息处理系统，包括：接收端201和发送端202；其中：
所述发送端202，用于，向接收端201发送第一报文，在所述第一报文中携带通告消息标识MSG_ID对象；在MSG_ID发生翻转后，向所述接收端201发送的第一个第一报文中的MSG_ID对象的Flags字段置上翻转标记，之后发送的第一报文中的MSG_ID对象的Flags字段清除所述翻转标记；
所述接收端201，用于接收处理所述第一个第一报文，并从接收到的来自所述发送端202的第二个第一报文开始，将收到的第一报文中的MSG_ID对象与前一第一报文进行比较，根据比较结果处理接收到的第一报文。
进一步地，所述接收端201，还用于从接收到的来自所述发送端202的第二个第一报文开始，将收到的第一报文中的MSG_ID对象与前一第一报文的MSG_ID对象进行比较；若当前接收到的第一报文中的MSG_ID对象的Epoch字段值变化，则判断所述发送端202重启，接收处理当前接收到的第一报文；若当前接收到的第一报文中的MSG_ID对象的Epoch字段值未变化，且MSG_ID不变，则判断此报文是刷新报文，更新本地状态块超时时间；若当前接收到的第一报文中的MSG_ID对象的Epoch字段值未变化，且MSG_ID变大，则判断此报文是触发报文，接收处理此报文；若当前接收到的第一报文中的MSG_ID对象的Epoch字段值未变化，且MSG_ID变小，Flags字段未置翻转标记，则判断此报文是乱序报文，丢弃该报文；若当前接收到的第一报文中的MSG_ID对象的Epoch字段值未变化，且MSG_ID变小，Flags字段置上翻转标记，则判断此报文是触发报文，接收处理此报文。
具体地，本实施例扩展MESSAGE-ID对象的Flags字段含义，增加定义：
0x02＝MESSAGE_IDentifier wrapped flag，表示发送端202的MSG_ID发生了翻转。
MSG_ID发生翻转后，发送端202向不同接收端201发送的第一个MESSAGE-ID对象的Flags字段置上0x02标记，向同一个接收端201发送的第二个MESSAGE-ID对象开始，Flags字段清除0x02标记。
对于接收端201，对收到的MESSAGE-ID对象进行解析。
接收端201在接收到发送端202发送的第一个第一报文时，保存第一个第一报文携带的MESSAGE-ID对象，并处理该报文，向发送端202回复第二报文。
后续，接收端201从接收到的来自发送端202的第二个第一报文开始，将收到的第一报文中的MSG_ID对象与前一第一报文的MSG_ID对象进行比较；
若当前接收到的第一报文中的MSG_ID对象的Epoch字段值变化，则判断所述发送端202重启，接收处理当前接收到的第一报文；
若当前接收到的第一报文中的MSG_ID对象的Epoch字段值未变化，且MSG_ID不变，则判断此报文是刷新报文，只更新本地状态块超时时间，保证状态块不老化；
若当前接收到的第一报文中的MSG_ID对象的Epoch字段值未变化，且MSG_ID变大，则判断此报文是触发报文，接收处理此报文；
若当前接收到的第一报文中的MSG_ID对象的Epoch字段值未变化，且MSG_ID变小，Flags字段未置翻转标记，则判断此报文是乱序报文，丢弃该报文；
若当前接收到的第一报文中的MSG_ID对象的Epoch字段值未变化，且MSG_ID变小，Flags字段置上翻转标记，则判断此报文是触发报文，接收处理此报文。
本实施例通过上述方案，发送端202向接收端201发送第一报文，在第一报文中携带通告消息标识MSG_ID对象；在MSG_ID发生翻转后，发送端202向接收端201发送的第一个第一报文中的MSG_ID对象的Flags字段置上翻转标记，之后发送的第一报文中的MSG_ID对象的Flags字段清除所述翻转标记；接收端201从接收到的来自发送端202的第二个第一报文开始，将收到的第一报文中的MSG_ID对象与前一第一报文进行比较，根据比较结果处理接收到的第一报文，由此通过发送端202的信令通告，使得接收端201得知消息标识符是否发生翻转，从而使得接收端201能够正确处理报文，提高了系统报文处理性能。
需要说明的是，本实施例中接收端201与发送端202可以分别对应所建立隧道的上游节点和下游节点，两者也可以互换。若接收端201为隧道的上游节点，发送端202为隧道的下游节点，则发送端202发送的第一报文为RESV报文、RESV-TEAR报文或PATH-ERR报文中的一种，接收端201发送的第二报文为PATH报文、PATH-TEAR报文、RESV-ERR报文或RESV-CONF报文中的一种。
若接收端201为隧道的下游节点，发送端202为隧道的上游节点，则发送端202发送的第一报文为PATH报文、PATH-TEAR报文、RESV-ERR报文或RESV-CONF报文中的一种，接收端201发送的第二报文为RESV报文、RESV-TEAR报文或PATH-ERR报文中的一种。
以下结合具体实例对本发明实施例方案进行详细阐述：
参考图3所示，从R1(上游节点)到R2(下游节点)建一条TE隧道，两节点均部署消息确认与重传功能。
建路过程，R1发送PATH报文(携带MESSAGE-ID对象)到R2，R2收到PATH报文后回复RESV报文(携带MESSAGE-ID对象)发给R1，R1收到RESV报文后，隧道建立。
之后两节点间通过刷新报文刷新状态块，保持状态块不老化(刷新报文也携带MESSAGE-ID对象)。
由于R1和R2都可以作为MESSAGE-ID对象的发送端和接收端，下面以实例分别进行描述。
实例1——隧道的上游节点R1作为发送方，下游节点作为接收方
R1作为MESSAGE-ID对象的发送方的处理过程如下：
1、建路过程，R1发送的PATH报文中携带MESSAGE-ID对象，Flags字段未置0x02标记，MSG_ID全局加1。
说明：MSG_ID全局分配，保证唯一。不同隧道不同状态，MSG_ID都不同。
2、TE隧道建立之后，隧道状态通过刷新报文进行刷新，刷新PATH报文中的MSG_ID保持不变。
3、当R1上状态发生变化，需要发送触发报文时，MSG_ID全局加1。
4、当MSG_ID发生翻转后，向R2发送的第一个PATH报文中的MESSAGE-ID对象的Flags置上0x02标记，之后的PATH报文中的MESSAGE-ID对象的Flags清除0x02标记。
R2作为MESSAGE-ID对象的接收方的处理过程如下：
1、建路过程，R2收到第一个PATH报文中携带的MESSAGE-ID对象，直接保存Epoch和MSG_ID，完全接收处理PATH报文，然后向R1回复RESV报文。
2、R2从收到第二个PATH报文开始，将收到PATH报文中的MESSAGE-ID对象和之前收到的进行比较，根据结果处理PATH报文：
①若Epoch变化，则认为发送方重启，完全接收处理此报文；
②若Epoch未变化，MSG_ID不变，则认为此报文是刷新报文，只更新本地状态块超时时间，保证状态块不老化；
③若Epoch未变化，MSG_ID变大，则认为此报文是触发报文，完全接收处理此报文；
④若Epoch未变化，MSG_ID变小，Flags未置0x02标记，则认为此报文是乱序报文，丢弃该报文；
⑤若Epoch未变化，MSG_ID变小，Flags置上0x02标记，则认为此报文是触发报文，完全接收处理此报文。
实例2——隧道的下游节点作为发送方，上游节点作为接收方
R2作为MESSAGE-ID对象的发送方的处理过程如下：
1、建路过程，R2发送的RESV报文中携带MESSAGE-ID对象，Flags
字段未置0x02标记，MSG_ID全局加1。
说明：MSG_ID全局分配，保证唯一。不同隧道不同状态，MSG_ID都不同。
2、TE隧道建立之后，隧道状态通过刷新报文进行刷新，刷新RESV中的MSG_ID保持不变。
3、当R2上状态发生变化，需要发送触发报文时，MSG_ID全局加1。
4、当MSG_ID发生翻转后，向R1发送的第一个RESV报文中的MESSAGE-ID对象的Flags置上0x02标记，之后的RESV报文中的MESSAGE-ID对象的Flags清除0x02标记。
R1作为MESSAGE-ID对象的接收方的处理过程如下：
1、建路过程，R1收到第一个RESV报文中携带的MESSAGE-ID对象，直接保存Epoch和MSG_ID，完全接收处理RESV报文。
2、R1从收到第二个RESV报文开始，将收到RESV报文中的MESSAGE-ID对象和之前收到的进行比较，根据结果处理RESV报文：
①若Epoch变化，则认为发送方重启，完全接收处理此报文；
②若Epoch未变化，MSG_ID不变，则认为此报文是刷新报文，只更新本地状态块超时时间，保证状态块不老化；
③若Epoch未变化，MSG_ID变大，则认为此报文是触发报文，完全接收处理此报文；
④若Epoch未变化，MSG_ID变小，Flags未置0x02标记，则认为此报文是乱序报文，丢弃该报文；
⑤若Epoch未变化，MSG_ID变小，Flags置上0x02标记，则认为此报文是触发报文，完全接收处理此报文。
实例3——发送方有多个邻居
如果R1上就建一条隧道，MSG_ID翻转的可能性不大。参考附图4，当从R1建隧道到很多不同邻居(R2，R3，R4等)，且到每个邻居都建很多条隧道(上千条)时，每条隧道就占一个MSG_ID，当隧道的状态频繁变化时，MSG_ID数值增长的就比较快，这时MSG_ID就可能发生翻转。
如图4所示，R1节点当MSG_ID发生翻转后，分别发送给R2、R3、R4的第一个MESSAGE-ID对象的Flags字段置上0x02标记，表示MSG_ID发生翻转。发送给同一个邻居的第二个MESSAGE-ID对象开始，Flags字段清除0x02标记。不同接收方的处理和前面描述的实例1的R2作为接收方的行为相同，这里不再赘述。
通过上述方法，MSG_ID的接收方可以正确判断发送方的MSG_ID是否发生翻转，从而可以正确处理接收报文。
还需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。
以上所述仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或流程变换，或直接或间接运用在其它相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种通告消息处理方法，其特征在于，包括：
发送端向接收端发送第一报文，在所述第一报文中携带通告消息标识MSG_ID对象；
在MSG_ID发生翻转后，所述发送端向所述接收端发送的第一个第一报文中的MSG_ID对象的Flags字段置上翻转标记，之后发送的第一报文中的MSG_ID对象的Flags字段清除所述翻转标记；
所述接收端接收处理所述第一个第一报文，并从接收到的来自所述发送端的第二个第一报文开始，将收到的第一报文中的MSG_ID对象与前一第一报文进行比较，根据比较结果处理接收到的第一报文。
2.根据权利要求1所述的方法，其特征在于，所述接收端从接收到的来自所述发送端的第二个第一报文开始，将收到的第一报文中的MSG_ID对象与前一第一报文进行比较，根据比较结果处理接收到的第一报文的步骤包括：
所述接收端从接收到的来自所述发送端的第二个第一报文开始，将收到的第一报文中的MSG_ID对象与前一第一报文的MSG_ID对象进行比较；
若当前接收到的第一报文中的MSG_ID对象的Epoch字段值变化，则判断所述发送端重启，接收处理当前接收到的第一报文；
若当前接收到的第一报文中的MSG_ID对象的Epoch字段值未变化，且MSG_ID不变，则判断此报文是刷新报文，更新本地状态块超时时间；
若当前接收到的第一报文中的MSG_ID对象的Epoch字段值未变化，且MSG_ID变大，则判断此报文是触发报文，接收处理此报文；
若当前接收到的第一报文中的MSG_ID对象的Epoch字段值未变化，且MSG_ID变小，Flags字段未置翻转标记，则判断此报文是乱序报文，丢弃该报文；
若当前接收到的第一报文中的MSG_ID对象的Epoch字段值未变化，且MSG_ID变小，Flags字段置上翻转标记，则判断此报文是触发报文，接收处理此报文。
3.根据权利要求1所述的方法，其特征在于，所述接收端为所述接收端与发送端之间建立的隧道的上游节点，所述发送端为所述隧道的下游节点，所述发送端发送的第一报文为RESV报文、RESV-TEAR报文或PATH-ERR报文中的一种。
4.根据权利要求1所述的方法，其特征在于，所述接收端为所述隧道的下游节点，所述发送端为所述隧道的上游节点，所述发送端发送的第一报文为PATH报文、PATH-TEAR报文、RESV-ERR报文或RESV-CONF报文中的一种。
5.根据权利要求1-4中任一项所述的方法，其特征在于，所述接收端接收处理所述第一个第一报文的步骤包括：
所述接收端在接收到所述发送端发送的第一个第一报文时，保存所述第一个第一报文携带的MESSAGE-ID对象，并处理该报文。
6.一种通告消息处理系统，其特征在于，包括：接收端和发送端；其中：
所述发送端，用于向接收端发送第一报文，在所述第一报文中携带通告消息标识MSG_ID对象；在MSG_ID发生翻转后，向所述接收端发送的第一个第一报文中的MSG_ID对象的Flags字段置上翻转标记，之后发送的第一报文中的MSG_ID对象的Flags字段清除所述翻转标记；
所述接收端，用于接收处理所述第一个第一报文，并从接收到的来自所述发送端的第二个第一报文开始，将收到的第一报文中的MSG_ID对象与前一第一报文进行比较，根据比较结果处理接收到的第一报文。
7.根据权利要求6所述的系统，其特征在于，
所述接收端，还用于从接收到的来自所述发送端的第二个第一报文开始，将收到的第一报文中的MSG_ID对象与前一第一报文的MSG_ID对象进行比较；若当前接收到的第一报文中的MSG_ID对象的Epoch字段值变化，则判断所述发送端重启，接收处理当前接收到的第一报文；若当前接收到的第一报文中的MSG_ID对象的Epoch字段值未变化，且MSG_ID不变，则判断此报文是刷新报文，更新本地状态块超时时间；若当前接收到的第一报文中的MSG_ID对象的Epoch字段值未变化，且MSG_ID变大，则判断此报文是触发报文，接收处理此报文；若当前接收到的第一报文中的MSG_ID对象的Epoch字段值未变化，且MSG_ID变小，Flags字段未置翻转标记，则判断此报文是乱序报文，丢弃该报文；若当前接收到的第一报文中的MSG_ID对象的Epoch字段值未变化，且MSG_ID变小，Flags字段置上翻转标记，则判断此报文是触发报文，接收处理此报文。
8.根据权利要求6所述的系统，其特征在于，所述接收端为所述隧道的上游节点，所述发送端为所述隧道的下游节点，所述发送端发送的第一报文为RESV报文、RESV-TEAR报文或PATH-ERR报文中的一种。
9.根据权利要求6所述的系统，其特征在于，所述接收端为所述隧道的下游节点，所述发送端为所述隧道的上游节点，所述发送端发送的第一报文为PATH报文、PATH-TEAR报文、RESV-ERR报文或RESV-CONF报文中的一种。
10.根据权利要求6-9中任一项所述的系统，其特征在于，
所述接收端，还用于在接收到所述发送端发送的第一个第一报文时，保存所述第一个第一报文携带的MESSAGE-ID对象，并处理该报文。
CN201510428333.9A 2015-07-20 2015-07-20 通告消息处理方法及系统 Active CN106375242B (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201510428333.9A CN106375242B (zh) 2015-07-20 2015-07-20 通告消息处理方法及系统
PCT/CN2016/075666 WO2016177078A1 (zh) 2015-07-20 2016-03-04 通告消息处理方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201510428333.9A CN106375242B (zh) 2015-07-20 2015-07-20 通告消息处理方法及系统

Publications (2)

Publication Number Publication Date
CN106375242A true CN106375242A (zh) 2017-02-01
CN106375242B CN106375242B (zh) 2020-09-08

Family

ID=57218089

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201510428333.9A Active CN106375242B (zh) 2015-07-20 2015-07-20 通告消息处理方法及系统

Country Status (2)

Country Link
CN (1) CN106375242B (zh)
WO (1) WO2016177078A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114422609A (zh) * 2021-12-30 2022-04-29 北京机电工程总体设计部 一种设备数字标识与名称共存的数据通信方法

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113676844B (zh) * 2021-09-27 2024-06-25 北京星网船电科技有限公司 一种基于北斗短报文的多点数据通信方法及系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1859277A (zh) * 2005-05-08 2006-11-08 华为技术有限公司 基于资源预留协议的路径消息的确认方法
CN101600165A (zh) * 2008-06-05 2009-12-09 大唐移动通信设备有限公司 对消息接收状态进行确认的方法及装置
CN101662700A (zh) * 2009-08-28 2010-03-03 中兴通讯股份有限公司 一种信令消息传递方法及系统
CN104700807A (zh) * 2015-03-27 2015-06-10 友达光电股份有限公司 内嵌式时钟点对点传输架构的数据传输装置及其方法

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101166113B (zh) * 2006-10-19 2010-06-16 中兴通讯股份有限公司 O-uni系统链路维护的消息处理方法
CN101166112A (zh) * 2006-10-20 2008-04-23 中兴通讯股份有限公司 O-uni系统的简化消息处理方法
CN101166110A (zh) * 2006-10-20 2008-04-23 中兴通讯股份有限公司 O-uni系统的链路维护过程中的消息处理方法
CN104270287B (zh) * 2014-09-30 2018-04-27 北京华为数字技术有限公司 一种报文乱序检测方法及装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1859277A (zh) * 2005-05-08 2006-11-08 华为技术有限公司 基于资源预留协议的路径消息的确认方法
CN101600165A (zh) * 2008-06-05 2009-12-09 大唐移动通信设备有限公司 对消息接收状态进行确认的方法及装置
CN101662700A (zh) * 2009-08-28 2010-03-03 中兴通讯股份有限公司 一种信令消息传递方法及系统
CN104700807A (zh) * 2015-03-27 2015-06-10 友达光电股份有限公司 内嵌式时钟点对点传输架构的数据传输装置及其方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
NETWORK WORKING GROUP: ""RSVP Refresh Overhead Reduction Extensions"", 《REQUEST FOR COMMENTS:2961》 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114422609A (zh) * 2021-12-30 2022-04-29 北京机电工程总体设计部 一种设备数字标识与名称共存的数据通信方法
CN114422609B (zh) * 2021-12-30 2024-08-02 北京机电工程总体设计部 一种设备数字标识与名称共存的数据通信方法

Also Published As

Publication number Publication date
CN106375242B (zh) 2020-09-08
WO2016177078A1 (zh) 2016-11-10

Similar Documents

Publication Publication Date Title
CN101483570B (zh) 一种防止中继链路的环网临时环路的方法、系统及设备
KR20090030320A (ko) 고장 방지 능력을 위해 다중 경로를 실행하기 위한 방법 및모바일 에드-호크 네트워크
JP2004274321A (ja) 通信方法および通信端末装置
CN100420242C (zh) 一种路由器链路状态数据同步的方法
CN112312483A (zh) 带宽增加、带宽减少方法及装置、存储介质、电子装置
CN106375242A (zh) 通告消息处理方法及系统
CN102143077A (zh) 路由设备多业务链接实现方法、系统及路由设备
CN112075102A (zh) 低功耗蓝牙组网方法、电子设备、网络和存储介质
CN114172798B (zh) Bier网络故障检测方法、装置、设备及可读存储介质
CN113727415B (zh) 动态感知的无人机自组网改进aodv路由协议的方法
CN105978796A (zh) 基于不稳定移动网络的消息通信方法及系统
CN103560947A (zh) 一种避免中间系统邻居关系震荡的方法及装置
CN100496023C (zh) 一种传输链路状态信息的方法
CN101902382A (zh) 一种以太单环网地址刷新方法及系统
CN104901865A (zh) 一种基于全局单调序列号的移动端即时通讯信号同步方法
CN101207555B (zh) 一种路由黑洞避免过程中过载位自动清除的方法
KR101499755B1 (ko) 중간 노드 장치, 중간 노드 장치의 제어 방법, 및 네트워크시스템
CN101841453B (zh) 一种网络错误源的处理方法、系统及网络节点
CN111355764B (zh) 保活报文发送方法、装置、电子设备及可读存储介质
CN116389514A (zh) 一种数据分布式存储的通信处理方法及装置
CN103414591A (zh) 一种端口故障恢复时的快速收敛方法和系统
CN110661550A (zh) 一种hplc通信链路中转发报文的方法、装置、存储介质和电子设备
WO2017143733A1 (zh) 路由器及其系统、数据库的同步方法及其装置
JP2008011041A (ja) システム情報設定方法及び装置
JP4805072B2 (ja) 通信システム

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant