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

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

Info

Publication number
WO2016177078A1
WO2016177078A1 PCT/CN2016/075666 CN2016075666W WO2016177078A1 WO 2016177078 A1 WO2016177078 A1 WO 2016177078A1 CN 2016075666 W CN2016075666 W CN 2016075666W WO 2016177078 A1 WO2016177078 A1 WO 2016177078A1
Authority
WO
WIPO (PCT)
Prior art keywords
packet
message
msg
received
receiving end
Prior art date
Application number
PCT/CN2016/075666
Other languages
English (en)
French (fr)
Inventor
姚燕
Original Assignee
中兴通讯股份有限公司
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 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2016177078A1 publication Critical patent/WO2016177078A1/zh

Links

Images

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]

Definitions

  • the present invention relates to the field of data network communication technologies, and in particular, to a method and system for processing an announcement message in a message acknowledgment and retransmission technology of a Resource Reservation Protocol-Traffic Engineer (RSVP-TE).
  • RSVP-TE Resource Reservation Protocol-Traffic Engineer
  • the RSVP protocol is a typical "soft state protocol”.
  • the related LSP (Label Switch Path) status information must be maintained by a timed refresh message. Once a certain RSVP node fails within the specified time. Upon receipt of the refresh message, its associated LSP status will be removed. Based on this feature of RSVP, when the number of tunnels reaches a certain level (such as several thousand), in order to maintain the refresh messages of these tunnels, the load on the entire system will be greatly stressed, and a lot of bandwidth traffic will be spent. Maintain the functionality of the existing tunnel above.
  • RFC2961 proposes various ways to reduce refresh messages, including message acknowledgement and retransmission, bundle transmission, and digest refresh. Although the implementation of these methods is different, the essence can be summarized as follows: Use one RSVP packet to refresh as many LSPs as possible, thus reducing the total number of RSVP packets that need to be refreshed, and finally reducing the number of refresh packets. The pressure of the entire system load.
  • the advantage of message confirmation and retransmission is that the receiving end of the refresh message does not need to create or update a status block, and does not need to compare operations of objects in the message, thereby reducing the traffic load generated by refreshing the message, and more effectively utilizing limited system resources.
  • MSG_ID message identifier
  • the RSVP node When the RSVP node receives the MESSAGE_ID object, if the Epoch is unchanged and the MSG_ID value becomes smaller than the previously received object, the MSG_ID is considered to have received the out-of-order message. However, the MSG_ID is set by the sender, and the receiver does not have a valid method to determine whether the value has been inverted. Therefore, the receiving end cannot process the message correctly.
  • the embodiments of the present invention provide a method and a system for processing an advertisement message, which are designed to implement the problem of the message acknowledgment and retransmission in the RSVP protocol.
  • the receiving end cannot determine whether the value of the MSG_ID is reversed, and the receiving end cannot correctly process the message.
  • the sending end sends the first packet to the receiving end, where the first packet carries the notification message to identify the MSG_ID object;
  • the transmitting end sends a Flip flag to the Flags field of the MSG_ID object in the first first packet sent by the receiving end, and then sends the Flags field of the MSG_ID object in the first packet. Clearing the flip mark;
  • the MSG_ID object in the received first packet is compared with the previous one.
  • the first message is compared, and the received first message is processed according to the comparison result.
  • the receiving end compares the received MSG_ID object in the first packet with the previous first packet from the received first first packet from the sending end, according to the comparison result.
  • the steps of processing the received first message include:
  • the receiving end compares the received MSG_ID object in the first packet with the MSG_ID object of the previous first packet, starting from the received second first packet from the sending end;
  • Epoch field value of the MSG_ID object in the first received packet is changed, it is determined that the sending end is restarted, and the first received message is received and processed;
  • the message is determined to be an out-of-order message. Discard the message;
  • the packet is a trigger packet, and the packet is received and processed.
  • the receiving end is an upstream node of a tunnel established between the receiving end and the transmitting end
  • the sending end is a downstream node of the tunnel
  • the first packet sent by the sending end is a RESV packet.
  • the receiving end is a downstream node of the tunnel
  • the sending end is an upstream node of the tunnel
  • the first packet sent by the sending end is a PATH packet, a PATH-TEAR packet, and a RESV- One of the ERR message or the RESV-CONF message.
  • the receiving end receiving the processing of the first first message comprises:
  • the receiving end When receiving the first first packet sent by the sending end, the receiving end saves the MESSAGE-ID object carried in the first first packet, and processes the packet.
  • An embodiment of the present invention further provides an advertisement message processing system, including: a receiving end and a sending end; wherein:
  • the sending end is configured to send a first packet to the receiving end, where the first packet carries an advertisement message identifier MSG_ID object; and after the MSG_ID is reversed, the first first packet sent to the receiving end
  • the Flags field of the MSG_ID object in the text is marked with a flip flag, and the Flags field of the MSG_ID object in the first message sent thereafter clears the flip flag;
  • the receiving end is configured to receive and process the first first packet, and start from the received second first packet from the sending end, and receive the MSG_ID object in the first packet received Comparing with the previous first message, processing the received first message according to the comparison result.
  • the receiving end is further configured to start, according to the received second first packet from the sending end, the MSG_ID object in the received first packet and the MSG_ID of the previous first packet.
  • the object is compared; if the value of the Epoch field of the MSG_ID object in the first received message is changed, it is determined that the sending end is restarted, and the first received message is received and received; if the first received message is received.
  • the value of the Epoch field of the MSG_ID object in the text has not changed. If the MSG_ID is unchanged, it is determined that the packet is a refresh packet, and the local state block timeout period is updated.
  • the packet is a trigger packet, and the packet is received and processed. If the value of the Epoch field of the MSG_ID object in the first packet received is not changed, and the MSG_ID is smaller, the Flags field is not set to be inverted, and the packet is judged. If the value of the Epoch field of the MSG_ID object in the first received message does not change, and the MSG_ID is smaller, the Flags field is set to a flip flag, and the message is triggered. The message is received and processed.
  • the receiving end is an upstream node of the tunnel
  • the sending end is a downstream node of the tunnel
  • the first packet sent by the sending end is a RESV message, a RESV-TEAR message or a PATH- One of the ERR messages.
  • the receiving end is a downstream node of the tunnel
  • the sending end is an upstream node of the tunnel
  • the first packet sent by the sending end is a PATH packet, a PATH-TEAR packet, and a RESV- One of the ERR message or the RESV-CONF message.
  • the receiving end is further configured to: when receiving the first first packet sent by the sending end, save the MESSAGE-ID object carried in the first first packet, and process the report Text.
  • the sender sends the first message to the receiving end, and the first message carries the notification message to identify the MSG_ID object; after the MSG_ID is reversed, the sending end sends the receiving end to the receiving end.
  • the Flags field of the MSG_ID object in the first first message sent is set with a flip flag, and the Flags field of the MSG_ID object in the first message sent subsequently clears the flip flag; the receiving end receives the first processing
  • the first packet and starting from the received second first packet from the sending end, compares the MSG_ID object in the received first packet with the previous first packet, and receives the processing according to the comparison result.
  • the first packet by means of the signaling advertisement of the transmitting end, enables the receiving end to know whether the message identifier is reversed, so that the receiving end can correctly process the packet, thereby improving the system packet processing performance.
  • FIG. 1 is a schematic diagram of a format of a MESSAGE-ID object defined in RFC 2961;
  • FIG. 2 is a schematic flow chart of a preferred embodiment of a method for processing an announcement message according to the present invention
  • FIG. 3 is a top neighbor network topology diagram in the embodiment of the present invention.
  • FIG. 4 is a topological diagram of a multi-neighbor network in an embodiment of the present invention.
  • FIG. 5 is a schematic structural diagram of a preferred embodiment of an announcement message processing system of the present invention.
  • the main solution of the embodiment of the present invention is: based on the message acknowledgment and retransmission technology of the RSVP-TE, the sending end sends the first packet to the receiving end, and the first message carries the advertised message identifier MSG_ID object; the MSG_ID is flipped After that, the sender sends a Flip flag to the Flags field of the MSG_ID object in the first first packet sent by the receiving end, and then the Flags field of the MSG_ID object in the first packet sent to clear the Flip flag; Receiving and processing the first first packet, and starting from the received second first packet from the sending end, comparing the MSG_ID object in the received first packet with the previous first packet, according to The comparison result processes the received first message, so that the receiving end knows whether the message identifier is reversed by the signaling notification of the transmitting end, so that the receiving end can correctly process the message.
  • the trigger message is an RSVP message including status and information that has not been transmitted before the announcement.
  • the trigger message includes advertising a new state, changing a route change of the reserved path, and the existing RSVP.
  • the receiver of the trigger message needs to completely receive and process this message, create or update a status block, and compare operations of objects in the message.
  • the refresh message indicates the status that has been previously advertised. It contains the same objects and information as the previous RSVP message and is forwarded along the same path.
  • the receiver of the refresh message does not need to completely process this message. It only needs to update the local status block timeout to ensure that the status block does not age.
  • the message sender By carrying the MESSAGE-ID object in the trigger message, when the neighbor receives the message, the message sender is confirmed to receive the message. If the sender of the message does not receive a message for a certain period of time, the message will be retransmitted.
  • the acknowledgment message is acknowledged by piggybacking or acknowledgment messages.
  • the message acknowledgment and retransmission mechanism is only applied to the trigger message. For PATH and RESV refresh messages, no acknowledgment is required. It can be simply assumed that a MESSAGE-ID object corresponds to a message state, the MESSAGE-ID object of the trigger message is changed, and the MESSAGE-ID object of the refresh message is unchanged.
  • the message receiver can pre-determine the message processing strategy according to the change of the MESSAGE-ID object.
  • the advantage of message confirmation and retransmission is that the receiving end of the refresh message does not need to create or update a status block, and does not need to compare operations of objects in the message, thereby reducing the traffic load generated by refreshing the message and more effectively utilizing limited system resources.
  • the format of the MESSAGE-ID object is defined in RFC 2961, as shown in Figure 1.
  • Epoch 24 bits, this field will not change unless a system or RSVP module reboot occurs. Once a restart event has occurred, the value of this field should be randomly generated and different from the value before the restart. Thus, this field can be used to identify if an RSVP node has restarted.
  • MESSAGE_IDentifier 32 bits, a message identifier (hereinafter referred to as MSG_ID), together with the IP address from which the message is generated, uniquely identifies a message. For trigger messages, this data It is constantly increasing, and the data does not change for refreshing messages. It will only decrease in two cases: one is when Epoch is reset, and the other is that the data is flipped.
  • the combination of the two data of Epoch and MSG_ID can also be used to check for out-of-order packets, and out-of-order packets should be discarded.
  • the RSVP node When the RSVP node receives the MESSAGE_ID object, if the Epoch is unchanged and the MSG_ID value becomes smaller than the previously received object, the MSG_ID is considered to have received the out-of-order message. However, the MSG_ID is set by the sender, and the receiver has no valid way to determine whether this value has been inverted.
  • the embodiment of the present invention provides a method for processing an advertisement message, and the sender notifies the receiver whether the message identifier is inverted by signaling, so that the receiver can correctly process the message.
  • a preferred embodiment of the present invention provides a method for processing an announcement message, including:
  • Step S101 The sending end sends the first packet to the receiving end, where the first packet carries the notification message to identify the MSG_ID object.
  • the tunnel is established, and the tunnel is successfully established.
  • the packets sent by the sender to the receiver carry the MSG_ID object.
  • Step S102 after the MSG_ID is reversed, the sending end sends a flip flag to the Flags field of the MSG_ID object in the first first packet sent by the receiving end, and then sends the MSG_ID object in the first packet.
  • the Flags field clears the flip flag;
  • This embodiment extends the meaning of the Flags field of the MESSAGE-ID object, and adds the definition:
  • 0x02 MESSAGE_IDentifier wrapped flag, indicating that the MSG_ID of the sender has been inverted.
  • the Flags field of the first MESSAGE-ID object sent by the sending end to the different receiving end is marked with 0x02, the second MESSAGE-ID object sent to the same receiving end starts, and the Flags field clears the 0x02 flag.
  • Step S103 the receiving end receives the second first report from the sending end.
  • the MSG_ID object in the received first message is compared with the previous first message, and the received first message is processed according to the comparison result.
  • the received MESSAGE-ID object is parsed.
  • the receiving end When receiving the first first packet sent by the sending end, the receiving end saves the MESSAGE-ID object carried in the first first packet, and processes the packet.
  • the receiving end compares the received MSG_ID object in the first packet with the MSG_ID object of the previous first packet, starting from the received second first packet from the sending end;
  • Epoch field value of the MSG_ID object in the first received packet is changed, it is determined that the sending end is restarted, and the first received message is received and processed;
  • the packet is a refresh packet, and only the local state block timeout period is updated to ensure that the status block is not aged.
  • the Flags field is not set to be inverted, and the packet is determined to be an out-of-order packet, and the packet is discarded;
  • the packet is a trigger packet, and the packet is received and processed.
  • the sending end sends the first packet to the receiving end, and the first packet carries the notification message to identify the MSG_ID object; and after the MSG_ID is reversed, the first first report sent by the sending end to the receiving end.
  • the Flags field of the MSG_ID object in the text is marked with a flip flag, and the Flags field of the MSG_ID object in the first message sent thereafter clears the flip flag; the receiving end receives and processes the first first message, and receives the received first message.
  • the receiving end and the transmitting end respectively correspond to the upstream node and the downstream node of the established tunnel, and the two may also be interchanged.
  • the first packet sent by the sending end is one of a RESV packet, a RESV-TEAR packet, or a PATH-ERR packet, and the receiving end sends the packet.
  • the second message is one of a PATH message, a PATH-TEAR message, a RESV-ERR message, or a RESV-CONF message.
  • the first packet sent by the sending end is the PATH packet, the PATH-TEAR packet, the RESV-ERR packet, or the RESV-CONF packet.
  • the second message sent by the receiving end is one of a RESV message, a RESV-TEAR message or a PATH-ERR message.
  • a TE tunnel is established from R1 (upstream node) to R2 (downstream node), and both nodes deploy message confirmation and retransmission functions.
  • R1 sends a PATH message (carrying the MESSAGE-ID object) to R2.
  • R2 replies with a RESV message (carrying the MESSAGE-ID object) and sends it to R1.
  • R1 receives the RESV message, the tunnel is received. set up.
  • the two nodes refresh the status block by refreshing the message, and the status block is not aged (the refresh message also carries the MESSAGE-ID object).
  • R1 and R2 can be used as the transmitting end and the receiving end of the MESSAGE-ID object, the following description will be respectively made by examples.
  • Example 1 The upstream node R1 of the tunnel acts as the sender and the downstream node acts as the receiver
  • the PATH message sent by R1 carries the MESSAGE-ID object, the Flags field is not set to 0x02, and the MSG_ID is globally added.
  • MSG_ID is globally allocated and guaranteed to be unique.
  • the MSG_ID is different for different tunnels.
  • the tunnel state is refreshed by refreshing the packet.
  • the MSG_ID in the PATH packet is kept unchanged.
  • R2 receives the MESSAGE-ID object carried in the first PATH message, directly saves the Epoch and MSG_ID, completely receives and processes the PATH message, and then returns the RESV message to R1.
  • R2 After receiving the second PATH packet, R2 compares the MESSAGE-ID object in the PATH packet with the previously received one, and processes the PATH packet according to the result:
  • the packet is considered to be a refresh packet, and only the local state block timeout period is updated to ensure that the status block is not aged.
  • the packet is considered to be a trigger packet, and the packet is completely received and processed.
  • the Epoch is unchanged, the MSG_ID is smaller, and the Flags is not marked with 0x02.
  • the packet is considered to be an out-of-order packet and the packet is discarded.
  • the MSG_ID is smaller, and the Flags is marked with the 0x02 flag.
  • the packet is considered to be a trigger packet, and the packet is completely received and processed.
  • Example 2 the downstream node of the tunnel acts as the sender and the upstream node acts as the receiver
  • the RESV message sent by R2 carries the MESSAGE-ID object, Flags The field is not set to 0x02, and MSG_ID is globally incremented by 1.
  • MSG_ID is globally allocated and guaranteed to be unique.
  • the MSG_ID is different for different tunnels.
  • the tunnel state is refreshed by refreshing the packet, and the MSG_ID in the refresh RESV remains unchanged.
  • MSG_ID is incremented by 1.
  • R1 receives the MESSAGE-ID object carried in the first RESV message, directly saves Epoch and MSG_ID, and completely receives and processes the RESV message.
  • R1 starts from receiving the second RESV message, compares the MESSAGE-ID object in the received RESV message with the previously received one, and processes the RESV message according to the result:
  • the packet is considered to be a refresh packet, and only the local state block timeout period is updated to ensure that the status block is not aged.
  • the packet is considered to be a trigger packet, and the packet is completely received and processed.
  • the Epoch is unchanged, the MSG_ID is smaller, and the Flags is not marked with 0x02.
  • the packet is considered to be an out-of-order packet and the packet is discarded.
  • the MSG_ID is smaller, and the Flags is marked with the 0x02 flag.
  • the packet is considered to be a trigger packet, and the packet is completely received and processed.
  • Example 3 The sender has multiple neighbors
  • MSG_ID flipping If a tunnel is built on R1, the possibility of MSG_ID flipping is small. Referring to Figure 4, when tunneling from R1 to many different neighbors (R2, R3, R4, etc.), and to each neighbor is very When multiple tunnels (thousands), each tunnel occupies one MSG_ID. When the state of the tunnel changes frequently, the MSG_ID value increases faster, and the MSG_ID may be reversed.
  • the Flags field of the first MESSAGE-ID object respectively sent to R2, R3, and R4 is marked with 0x02, indicating that the MSG_ID is inverted.
  • the second MESSAGE-ID object sent to the same neighbor begins, and the Flags field clears the 0x02 flag.
  • the processing of the different receivers is the same as the behavior of R2 of the first example described above as the receiver, and details are not described herein again.
  • the receiver of the MSG_ID can correctly determine whether the sender's MSG_ID is reversed, so that the received message can be correctly processed.
  • a preferred embodiment of the present invention further provides an advertisement message processing system, including: a receiving end 201 and a transmitting end 202; wherein:
  • the sending end 202 is configured to send a first packet to the receiving end 201, where the first packet carries an advertisement message identifier MSG_ID object; and after the MSG_ID is reversed, the first one sent to the receiving end 201
  • the Flags field of the MSG_ID object in the first message is marked with a flip flag, and the Flags field of the MSG_ID object in the first message sent thereafter clears the flip flag;
  • the receiving end 201 is configured to receive and process the first first packet, and start from the received first first packet from the sending end 202, and receive the received first packet.
  • the MSG_ID object is compared with the previous first message, and the received first message is processed according to the comparison result.
  • the receiving end 201 is further configured to start, according to the received second first packet from the sending end 202, the MSG_ID object in the received first packet and the previous first report.
  • the MSG_ID object of the text is compared; if the Epoch field value of the MSG_ID object in the first received message is changed, it is determined that the sending end 202 is restarted, and the first received message is received and received; if the current received message is received, If the value of the Epoch field of the MSG_ID object in the first packet does not change, and the MSG_ID is unchanged, it is determined that the packet is a refresh packet, and the local state block timeout period is updated; if the MSG_ID in the first packet is currently received Object's Epoch field If the value does not change, and the MSG_ID becomes large, it is determined that the message is a trigger message, and the message is received and processed; if the value of the Epoch field of the MSG_ID object in the first received message does not change, and the MSG_
  • this embodiment extends the meaning of the Flags field of the MESSAGE-ID object, and adds a definition:
  • 0x02 MESSAGE_IDentifier wrapped flag, indicating that the MSG_ID of the sender 202 has been inverted.
  • the Flags field of the first MESSAGE-ID object sent by the sending end 202 to the different receiving end 201 is marked with 0x02, and the second MESSAGE-ID object sent to the same receiving end 201 is started, and the Flags field is cleared. 0x02 tag.
  • the received MESSAGE-ID object is parsed.
  • the receiving end 201 When receiving the first first packet sent by the sending end 202, the receiving end 201 saves the MESSAGE-ID object carried in the first first packet, processes the packet, and returns the second packet to the sending end 202. .
  • the receiving end 201 compares the received MSG_ID object in the first packet with the MSG_ID object of the previous first packet, starting from the received second first packet from the sending end 202;
  • the packet is a refresh packet, and only the local state block timeout period is updated to ensure that the status block is not aged.
  • the packet is determined to be an out-of-order packet, and the packet is discarded.
  • the packet is a trigger packet, and the packet is received and processed.
  • the sending end 202 sends the first packet to the receiving end 201, and the first packet carries the advertised message identifier MSG_ID object; after the MSG_ID is reversed, the sending end 202 sends the first packet to the receiving end 201.
  • the Flags field of the MSG_ID object in the first message is marked with a flip flag, and the Flags field of the MSG_ID object in the first message sent subsequently clears the flip flag; the receiving end 201 receives the received message from the transmitting end 202.
  • the two first packets start to compare the MSG_ID object in the received first packet with the previous first packet, and process the received first packet according to the comparison result, thereby transmitting the message through the sending end 202.
  • the notification is such that the receiving end 201 knows whether the message identifier is reversed, so that the receiving end 201 can correctly process the message, thereby improving the system packet processing performance.
  • the receiving end 201 and the transmitting end 202 may respectively correspond to the upstream node and the downstream node of the established tunnel, and the two may also be interchanged. If the receiving end 201 is the upstream node of the tunnel, and the transmitting end 202 is the downstream node of the tunnel, the first packet sent by the sending end 202 is one of a RESV packet, a RESV-TEAR packet, or a PATH-ERR packet. The second packet sent by the receiving end 201 is one of a PATH packet, a PATH-TEAR packet, a RESV-ERR packet, or a RESV-CONF packet.
  • the first packet sent by the sending end 202 is a PATH packet, a PATH-TEAR packet, a RESV-ERR packet, or a RESV-CONF packet.
  • the second message sent by the receiving end 201 is one of a RESV message, a RESV-TEAR message or a PATH-ERR message.
  • a TE tunnel is built from R1 (upstream node) to R2 (downstream node). Road, both nodes deploy message confirmation and retransmission.
  • R1 sends a PATH message (carrying the MESSAGE-ID object) to R2.
  • R2 replies with a RESV message (carrying the MESSAGE-ID object) and sends it to R1.
  • R1 receives the RESV message, the tunnel is received. set up.
  • the two nodes refresh the status block by refreshing the message, and the status block is not aged (the refresh message also carries the MESSAGE-ID object).
  • R1 and R2 can be used as the transmitting end and the receiving end of the MESSAGE-ID object, the following description will be respectively made by examples.
  • Example 1 The upstream node R1 of the tunnel acts as the sender and the downstream node acts as the receiver
  • the PATH message sent by R1 carries the MESSAGE-ID object, the Flags field is not set to 0x02, and the MSG_ID is globally added.
  • MSG_ID is globally allocated and guaranteed to be unique.
  • the MSG_ID is different for different tunnels.
  • the tunnel state is refreshed by refreshing the packet.
  • the MSG_ID in the PATH packet is kept unchanged.
  • R2 receives the MESSAGE-ID object carried in the first PATH message, directly saves the Epoch and MSG_ID, completely receives and processes the PATH message, and then returns the RESV message to R1.
  • R2 After receiving the second PATH packet, R2 compares the MESSAGE-ID object in the PATH packet with the previously received one, and processes the PATH packet according to the result:
  • the packet is considered to be a refresh packet, and only the local state block timeout period is updated to ensure that the status block is not aged.
  • the packet is considered to be a trigger packet, and the packet is completely received and processed.
  • the Epoch is unchanged, the MSG_ID is smaller, and the Flags is not marked with 0x02.
  • the packet is considered to be an out-of-order packet and the packet is discarded.
  • the MSG_ID is smaller, and the Flags is marked with the 0x02 flag.
  • the packet is considered to be a trigger packet, and the packet is completely received and processed.
  • Example 2 the downstream node of the tunnel acts as the sender and the upstream node acts as the receiver
  • the RESV message sent by R2 carries the MESSAGE-ID object, the Flags field is not set to 0x02, and the MSG_ID is globally added.
  • MSG_ID is globally allocated and guaranteed to be unique.
  • the MSG_ID is different for different tunnels.
  • the tunnel state is refreshed by refreshing the packet, and the MSG_ID in the refresh RESV remains unchanged.
  • MSG_ID is incremented by 1.
  • R1 receives the MESSAGE-ID object carried in the first RESV message, directly saves Epoch and MSG_ID, and completely receives and processes the RESV message.
  • R1 starts from receiving the second RESV message, compares the MESSAGE-ID object in the received RESV message with the previously received one, and processes the RESV message according to the result:
  • the packet is considered to be a refresh packet, and only the local state block timeout period is updated to ensure that the status block is not aged.
  • the packet is considered to be a trigger packet, and the packet is completely received and processed.
  • the Epoch is unchanged, the MSG_ID is smaller, and the Flags is not marked with 0x02.
  • the packet is considered to be an out-of-order packet and the packet is discarded.
  • the MSG_ID is smaller, and the Flags is marked with the 0x02 flag.
  • the packet is considered to be a trigger packet, and the packet is completely received and processed.
  • Example 3 The sender has multiple neighbors
  • the Flags field of the first MESSAGE-ID object respectively sent to R2, R3, and R4 is marked with 0x02, indicating that the MSG_ID is inverted.
  • the second MESSAGE-ID object sent to the same neighbor begins, and the Flags field clears the 0x02 flag.
  • the processing of the different receivers is the same as the behavior of R2 of the first example described above as the receiver, and details are not described herein again.
  • the receiver of the MSG_ID can correctly determine whether the sender's MSG_ID is reversed, so that the received message can be correctly processed.
  • the foregoing embodiment method can be implemented by means of software plus a necessary general hardware platform, and of course, can also be through hardware, but in many cases, the former is better.
  • Implementation Based on such understanding, the technical solution of the present invention, which is essential or contributes to the prior art, may be embodied in the form of a software product stored in a storage medium (such as ROM/RAM, disk,
  • the optical disc includes a number of instructions for causing a terminal device (which may be a cell phone, a computer, a server, or a network device, etc.) to perform the methods described in various embodiments of the present invention.
  • an advertisement message processing method and system provided by an embodiment of the present invention have the following beneficial effects: the signaling end of the transmitting end is used to enable the receiving end to know whether the message identifier is reversed, so that the receiving end can correctly process the message. This improves the processing performance of the system message.

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(Label Switch 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对象，并处理该报文。
PCT/CN2016/075666 2015-07-20 2016-03-04 通告消息处理方法及系统 WO2016177078A1 (zh)

Applications Claiming Priority (2)

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

Publications (1)

Publication Number Publication Date
WO2016177078A1 true WO2016177078A1 (zh) 2016-11-10

Family

ID=57218089

Family Applications (1)

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

Country Status (2)

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

Families Citing this family (1)

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

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101166110A (zh) * 2006-10-20 2008-04-23 中兴通讯股份有限公司 O-uni系统的链路维护过程中的消息处理方法
CN101166112A (zh) * 2006-10-20 2008-04-23 中兴通讯股份有限公司 O-uni系统的简化消息处理方法
CN101166113A (zh) * 2006-10-19 2008-04-23 中兴通讯股份有限公司 O-uni系统链路维护的消息处理方法
CN104270287A (zh) * 2014-09-30 2015-01-07 北京华为数字技术有限公司 一种报文乱序检测方法及装置
CN104700807A (zh) * 2015-03-27 2015-06-10 友达光电股份有限公司 内嵌式时钟点对点传输架构的数据传输装置及其方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1859277A (zh) * 2005-05-08 2006-11-08 华为技术有限公司 基于资源预留协议的路径消息的确认方法
CN101600165B (zh) * 2008-06-05 2011-12-14 电信科学技术研究院 对消息接收状态进行确认的方法及装置
CN101662700A (zh) * 2009-08-28 2010-03-03 中兴通讯股份有限公司 一种信令消息传递方法及系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101166113A (zh) * 2006-10-19 2008-04-23 中兴通讯股份有限公司 O-uni系统链路维护的消息处理方法
CN101166110A (zh) * 2006-10-20 2008-04-23 中兴通讯股份有限公司 O-uni系统的链路维护过程中的消息处理方法
CN101166112A (zh) * 2006-10-20 2008-04-23 中兴通讯股份有限公司 O-uni系统的简化消息处理方法
CN104270287A (zh) * 2014-09-30 2015-01-07 北京华为数字技术有限公司 一种报文乱序检测方法及装置
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, 30 April 2001 (2001-04-30), pages 2961 *

Also Published As

Publication number Publication date
CN106375242B (zh) 2020-09-08
CN106375242A (zh) 2017-02-01

Similar Documents

Publication Publication Date Title
US8472450B2 (en) Method and system for establishing tunnels
US20060159011A1 (en) Detecting unavailable network connections
EP2429135A1 (en) Method, device and system for establishing bidirectional point-to-multipoint label switched path
CN101640637B (zh) 一种基于流量工程的资源预留协议隧道管理方法及系统
WO2009082917A1 (fr) Procédé de redémarrage élégant d'un routeur, routeur et son système de communication
US11991066B2 (en) Method of establishing bidirectional forwarding detection session based on BIER, and BFIR, BFER, system and storage medium
WO2008055436A1 (fr) Procédé de commande d'état de redémarrage progressif et de routeur
US8971174B2 (en) Restart method and node device
CN102355421B (zh) 一种lsp网络拥塞处理的方法、装置及系统
WO2015003299A1 (zh) 一种误码率检测的方法及网络设备
WO2015021799A1 (zh) 数据链路的检测方法、装置、系统、控制器及网关
EP2621133B1 (en) Method and system for implementing pw control bit capability negotiation
EP2254289A1 (en) Method, device, and system for establishing label switching path in fast rerouting switching
WO2006102851A1 (fr) Procede d'information et de negociation de l'aptitude a surveiller propre a la commutation de label
CN102143077B (zh) 路由设备多业务链接实现方法、系统及路由设备
JP2006033124A (ja) トンネル障害通知装置および方法
US20150003451A1 (en) Method and Apparatus for Establishing Multicast Path
WO2016177078A1 (zh) 通告消息处理方法及系统
US20060034203A1 (en) Mobile communication system and service control device
EP2804352A1 (en) Method and apparatus for processing residual information
CN101257448B (zh) 一种提高rsvp-te隧道可靠性的方法
WO2017162172A1 (zh) 重启恢复时间的调整方法和装置
CN102571576B (zh) 一种多协议标签交换网络中优雅重启的方法及路由设备
WO2017152595A1 (zh) 一种响应网络拓扑变化的方法和装置
WO2010115370A1 (zh) 一种更新联合双向标签交换路径绑定关系的方法和装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16789072

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16789072

Country of ref document: EP

Kind code of ref document: A1