Patent Description:
This application relates to the field of communication technologies, and in particular, to a method for session protection and a corresponding device.

As networking becomes diversified, a transmission path of a service packet is controlled by deploying control protocols. Control information is transmitted according to these protocols through sessions established between network element devices. Session termination and session flapping often occur on a network. It is difficult to diagnose failures. This severely affects a network service. <CIT> relates to techniques for initiating a targeted LDP session. Loibl et al. describe "BGP Flow Specification Multi Vendor and Inter AS Interoperability" and proposes changes to the flow specification standard. <CIT> discloses a method and a device for diagnosing network faults. <CIT> discloses a fault detection method and a fault detection device. <CIT> relates to a method for providing context-based routing table updates in Border Gateway Protocol hosts.

It is clear that the described embodiments are merely some rather than all of embodiments of this application.

<FIG> is a schematic diagram of a scenario according to an embodiment of this application. The scenario described in a schematic diagram <NUM> is that a border router <NUM> of an autonomous system (Autonomous System, AS) AS <NUM> and a border router <NUM> of an autonomous system AS <NUM> establish a border gateway protocol (Border Gateway Protocol, BGP) session <NUM>. The BGP is a dynamic routing protocol used between autonomous systems ASs, and is used to exchange reachable routing information between ASs and construct an inter-AS data transmission path. When the AS <NUM> and the AS <NUM> belong to a same AS, the BGP session <NUM> is an internal border gateway protocol (Internal Border Gateway Protocol, IBGP) session; or when the AS <NUM> and the AS <NUM> are two different ASs, the BGP session <NUM> is an external border gateway protocol (External Border Gateway Protocol, EBGP) session. There are four types of BGP packets: (<NUM>) a BGP open (Open) packet, used to establish a session between BGP peers; (<NUM>) a BGP keepalive (Keepalive) packet, used to periodically send a keepalive message to a BGP peer to maintain validity of a session; (<NUM>) a BGP update (Update) packet, used to exchange routing information between BGP peers; (<NUM>) a BGP notification (Notification) packet, used to notify a BGP exception; and (<NUM>) a BGP route-refresh (Route-refresh) packet, used to request a BGP peer to resend routing information of a specified address family. The BGP protocol has a periodic mechanism to ensure connection reliability, and has a plurality of capabilities and attributes, for example, a multiprotocol extension for BGP-<NUM> (Multiprotocol Extension for BGP-<NUM>), a route refresh capability for BGP-<NUM> (Route Refresh Capability for BGP-<NUM>), and an outbound route filtering capability (Outbound Route Filtering Capability). The multiprotocol extension capability for BGP-<NUM> may alternatively be based on an address family identifier (Address Family Identifier, AFI) and a subsequent address family (Subsequent Address Family Identifier, SAFI), for example, the multiprotocol extension capabilities such as IPv4 unicast (IPv4 Unicast), IPv4 multicast (IPv4 Multicast), IPv4 flowspec (IPv4 Flowspec), IPv6 unicast (IPv6 Unicast), and IPv6 flowspec (IPv6 Flowspec). For a network device that supports the BGP, some BGP capabilities are enabled based on a network requirement. According to features of the BGP, one BGP session may support the following at the same time: (<NUM>) a plurality of BGP capabilities, (<NUM>) the BGP multiprotocol extension capability may further support a plurality of address families, and (<NUM>) when a BGP update message is received, the message may carry a plurality of different types of BGP path attributes. When the BPG capability and/or the BGP attribute is incorrectly configured and/or incorrectly processed by a device, an established BGP session is interrupted. When the BGP session is re-established, if the BGP capability and/or the BGP attribute carried on the BGP session is not adjusted or a device failure is not recovered, the established BGP session is interrupted again, causing the failure to occur repeatedly, and finally a service is terminated due to network flapping. As shown in <FIG>, before the router <NUM> and the router <NUM> establish the BGP session <NUM>, the router <NUM> sends a BGP open packet to the router <NUM>, where the BGP open packet carries a BGP capability <NUM> of the router <NUM>. The BGP capabilities <NUM> include: an IPv4 unicast (IPv4 Unicast), an IPv4 multicast (IPv4 Multicast), an IPv4-labeled route exchange (IPv4 labeled Unicast), an IPv4 flowspec (IPv4 Flowspec), a route refresh capability (Route Refresh Capability), and a support for <NUM>-octet AS number capability (Support for <NUM>-octet AS number capability). The router <NUM> sends a BGP open packet to the router <NUM>, where the BGP open packet carries a BGP capability <NUM> of the router <NUM>. The BGP capabilities <NUM> include: an IPv4 unicast (IPv4 Unicast), an IPv4 multicast (IPv4 Multicast), an IPv4 flowspec (IPv4 Flowspec), an IPv4 VPN unicast (VPNv4 unicast), a route refresh capability (Route Refresh Capability), and a support for <NUM>-octet AS number capability (Support for <NUM>-octet AS number capability). According to a current processing rule of the BGP, after an R1 and an R2 successfully establish the BGP session <NUM>, the BGP capability supported by the BGP session <NUM> is an intersection of "the BGP capability <NUM> sent by the R1 to the R2" and "the BGP capability <NUM> sent by the R2 to the R1", and BGP capabilities <NUM> supported by the BGP session <NUM> include: an IPv4 unicast (IPv4 Unicast), an IPv4 multicast (IPv4 Multicast), an IPv4 flowspec (IPv4 Flowspec), a route refresh capability (Route Refresh Capability), and a support for <NUM>-octet AS number capability (Support for <NUM>-octet AS number capability). According to the foregoing BGP session capability generation rule, when a router does not want to support one or more capabilities on an established BGP session, the one or more capabilities may be excluded from a BGP open packet in a BGP session establishment stage. For example, if the router <NUM> does not want to support the IPv4 flowspec capability on the BGP session established between the router <NUM> and the router <NUM>, the IPv4 flowspec capability may be deleted or disabled from a BGP session startup configuration of the router <NUM>, without depending on a configuration of the router <NUM>.

<FIG> is a schematic diagram of a scenario according to an embodiment. A schematic diagram <NUM> describes a label distribution network, where a router <NUM> and a router <NUM> support a label distribution protocol (Label Distribution Protocol, LDP). The LDP is an application protocol used to obtain a label switched path (Label Switched Path, LSP) based on one or more label switch routing devices (Label Switch Router, LSR). A working mechanism of the LDP needs to establish an LDP session between two LSRs, for example, the router <NUM> and the router <NUM> shown in <FIG>. There are four types of LDP protocol messages: (<NUM>) a discovery message, such as an LDP hello (Hello) packet, used to advertise and maintain an LSR in a network; (<NUM>) a session message, used to establish, maintain, and terminate a session between the LSRs, for example, an initialization (Initialization) packet for negotiating a session parameter and a keepalive (Keepalive) packet for maintaining the session; (<NUM>) an advertisement message, used to create, change, and delete a label relationship; and (<NUM>) a notification message, used to provide notification suggestion information, for example, a notification (Notification) packet. Before an LDP session is established, two LSRs carry capabilities and parameters by using an LDP initialization packet by using a type length value (Type-length-value, TLV), the two LSRs negotiate the capabilities and parameters by using the LDP initialization packet. If the negotiation is successful, the two LSRs enter a session establishment process. As shown in <FIG>, the router <NUM> sends the LDP initialization packet to the router <NUM>, where the LDP initialization packet includes the LDP capabilities and parameters <NUM> of the router <NUM>. The LDP capabilities and parameters of the router <NUM> include: an LDP protocol version, a label distribution mode, a value of a hold timer, a maximum protocol data unit (Protocol Data Unit, PDU) length, a label space, and outbound label filtering (Outbound Label Filtering, OLF). The router <NUM> receives the LDP initialization packet, checks correctness, and sends the LDP initialization packet to the router <NUM>. The LDP initialization packet includes an LDP capability <NUM> of the router <NUM>. The LDP capabilities and parameters of the router <NUM> include: an LDP protocol version, a label distribution mode, a value of a hold timer, a maximum PDU length, a label space, outbound label filtering (Outbound Label Filtering, OLF), and inbound label filtering (Inbound Label Filtering, ILF). The router <NUM> and the router <NUM> establish an LDP session <NUM>. A capability <NUM> of the LDP session <NUM> is an intersection of the LDP capability <NUM> of the router <NUM> and the LDP capability <NUM> of the router <NUM>, and includes: an LDP protocol version, a label distribution mode, a value of a hold timer, a maximum PDU length, a label space, and outbound label filtering (Outbound Label Filtering, OLF). When an LSR does not want to support one or more capabilities on an established LDP session, the one or more capabilities may be excluded from the LDP initialization packet in an LDP session establishment stage. For example, if the router <NUM> does not want to support the ILF capability on the LDP session established between the router <NUM> and the router <NUM>, the ILF capability may be deleted or disabled from an LDP session startup configuration of the router <NUM>, without depending on a configuration of the router <NUM>.

<FIG> is a flowchart according to an embodiment of this application. This embodiment provides a method for session protection, in which after a session failure is found, a session supporting a basic capability is established, so as to ensure normal running of a basic service. A specific method is as follows:
S301: Determine that a failure occurs in a session between a first device and a second device.

In some embodiments, both the first device and the second device are routing devices. A BGP session has been established between the first device and the second device. Because a BPG capability in the BGP session is incorrectly configured, the established BGP session is terminated in this case. When the first device and the second device re-establish a BGP session, because the BGP capability carried on the BGP session is not adjusted or modified, the re-established BGP session is abnormally terminated again due to the foregoing reason. If a network administrator does not perform manual intervention, the foregoing failure occurs repeatedly. Consequently, network link flapping is caused, BGP route control information cannot be transmitted based on the BGP session, and a network service cannot be normally transmitted. For example, the first device, for example, the router <NUM> shown in <FIG>, and the second device, for example, the router <NUM> shown in <FIG>, establish a BGP session, for example, the BGP session <NUM> shown in <FIG>. The first device and the second device negotiate a BGP capability, including an IPv4 flowspec capability, supported by both parties. A network in which the first device and the second device are located needs to forward some data packets via a BGP flowspec route. In this case, the first device defines a data packet forwarding policy and implements the policy by enabling the BGP flowspec route. A BGP flowspec route capability of the first device is incorrectly configured, for example, a quintuple of a data packet defined in the BGP flowspec policy is incorrectly configured. In this case, a BGP keepalive protocol packet between the first device and the second device matches the BGP flowspec policy, and is forwarded by the first device to another routing device, but is not sent to the second device. In this case, according to a BGP mechanism, the second device does not receive the BGP keepalive protocol packet within a specified time period, so that the BGP session is terminated. The first device discovers that the previously established BGP session is terminated and starts establishment of a BGP session with the second device. When the first device and the second device re-establish the BGP session, a BGP flowspec capability carried on the re-established BGP session is not adjusted or modified. As a result, the re-established BGP session is terminated abnormally again due to the foregoing reason. If the network administrator does not perform manual intervention, the foregoing failure occurs repeatedly. Consequently, the network link flapping is caused, the BGP route control information cannot be transmitted based on the BGP session, and the network service cannot be normally transmitted. In some embodiments, the BGP session failure includes: (<NUM>) Abnormal session termination occurs once; and (<NUM>) A quantity of times of session termination exceeds a threshold within a specified time period. A manner of determining that a session failure occurs is classified based on a subject that determines the failure, and includes automatic determining and manual determining. The automatic determining means that a routing device that supports the BGP automatically determines that a session failure occurs upon a quantity of BGP session failures satisfies a rule for failure reporting according to a session failure reporting rule. The manual determining means that the network administrator manually determines whether a failure occurs in a BGP session. For example, according to the session failure reporting rule, the routing device automatically determines that the failure occurs in the session if the session is terminated for more than three times within <NUM> minutes. The network administrator finds, by viewing a device log, that the session is terminated twice within <NUM> minutes, and the network administrator manually determines that the failure occurs in the session.

In some embodiments, in a session of a BGP route protocol and a session of an IGP route protocol, capabilities and parameters of two devices that establish a session are negotiated in a session establishment process, and session re-establishment is further supported after the session is terminated. In this case, the foregoing failure may occur in the session of the BGP route protocol and the session of the IGP route protocol. Consequently, the network link flapping is caused, the BGP route control information cannot be transmitted based on the BGP session, and the network service cannot be normally transmitted.

In some embodiments, both the first device, for example, the router <NUM> shown in <FIG>, and the second device, for example, the router <NUM> shown in <FIG>, support an LDP, and an LDP session is established between the first device and the second device. The established LDP session is terminated because an LDP capability is incorrectly configured. When the first device and the second device re-establish an LDP session, the LDP capability carried on the LDP session is not adjusted or modified. As a result, the re-established LDP session is terminated abnormally again due to the foregoing reason. If the network administrator does not perform manual intervention, the foregoing failure occurs repeatedly, and the service is interrupted due to the network flapping. For example, the LDP session is established between the first device and the second device, and capabilities, including an outbound label filtering OLF capability, supported by both the first device and the second device are negotiated. In this case, the first device defines an OLF policy. Because an LDP OLF capability of the first device is incorrectly configured, an LDP keepalive protocol packet between the first device and the second device is filtered out, and is not sent to the second device. In this case, the second device does not receive the LDP keepalive protocol packet within a specified time period, so that the LDP session is terminated. In this case, when the first device and the second device re-establish the LDP session, the LDP OLF capability carried on the LDP session is not adjusted or modified. As a result, the re-established LDP session is terminated abnormally again due to the foregoing reason. If the network administrator does not perform manual intervention, the foregoing failure occurs repeatedly, and the service is interrupted due to the network flapping.

In some embodiments, the LDP session failure includes: (<NUM>) Abnormal session termination occurs once; and (<NUM>) A quantity of times of session termination exceeds a threshold within a specified time period. A manner of determining that a session failure occurs is classified based on a subject that determines the failure, and includes automatic determining and manual determining. The automatic determining means that a label switching routing device that supports the LDP automatically determines that a session failure occurs upon a quantity of LDP session failures satisfies a rule for failure reporting according to a session failure reporting rule. The manual determining means that the network administrator manually determines whether a failure occurs in an LDP session. For example, according to the session failure reporting rule, the routing device automatically determines that the failure occurs in the session if the session is terminated for more than three times within <NUM> minutes. The network administrator finds, by viewing a device log, that the session is terminated twice within <NUM> minutes, and the network administrator manually determines that the failure occurs in the session.

In some embodiments, for a label distribution protocol session, capabilities and parameters of two devices that establish the session are negotiated in a process of establishing the session, and session re-establishment is further supported after the session is terminated. A label distribution protocol includes the LDP protocol, a resource reservation protocol (Resource Reservation Protocol, RSVP), and a path computation element communication protocol (Path Computation Element Communication Protocol, PCEP). In this case, the foregoing failure may occur in the label distribution protocol session. Consequently, the network link flapping is caused, LDP label distribution information cannot be transmitted based on the LDP session, and the network service cannot be normally transmitted.

S303: After the failure occurs, the first device sends, to the second device, a first session establishment packet used to establish a new session, where the first session establishment packet carries capability information of the first device, and the capability information of the first device indicates that the first device does not have a capability of filtering a protocol packet for the new session.

In some embodiments, it is determined, by performing operation <NUM>, that the failure occurs in the BGP session between the first device and the second device. The first device sends the first session establishment packet to the second device. The first session establishment packet, for example, a BGP open packet, is used to establish a new BGP session. The first session establishment packet carries the capability information of the first device. The capability information of the first device indicates that the first device does not have the capability of filtering the protocol packet for the new session. For example, the capabilities of the first device carried in the first session establishment packet include: an IPv4 unicast (IPv4 Unicast), an IPv4 multicast (IPv4 Multicast), an IPv4 flowspec (IPv4 Flowspec), an IPv6 unicast (IPv6 Unicast), an IPv6 flowspec (IPv6 Flowspec), and a route refresh capability (Route Refresh Capability). For example, when the failure occurs in the BGP session between the router <NUM> and the router <NUM>, the router <NUM> sends the first session establishment packet to the router <NUM>, where the BGP capabilities of the first session establishment packet include: the IPv4 unicast (IPv4 Unicast) and the route refresh capability (Route Refresh Capability). In this case, the router <NUM> has the IPv4 unicast (IPv4 Unicast) and the route refresh capability (Route Refresh Capability) for the newly established BGP session, and does not have the capability of filtering the protocol packet, for example, the BGP flowspec capability.

In some embodiments, it is determined, by performing operation <NUM>, that the failure occurs in the LDP session between the first device and the second device. The first device sends the first session establishment packet to the second device. The first session establishment packet, for example, an LDP initialization packet, is used to establish an LDP session. The first session establishment packet carries the capability information of the first device. The capability information of the first device indicates that the first device does not have the capability of filtering the protocol packet for the new session. For example, capabilities for supporting an LDP label switching routing device include: an LDP protocol version, a label distribution mode, a value of a keepalive hold timer, a maximum PDU length, a label space, an outbound label filtering OLF capability, and an inbound label filtering ILF capability. For example, when the failure occurs in the LDP session between the router <NUM> and the router <NUM>, the router <NUM> sends the first session establishment packet to the router <NUM>, where LDP capabilities of the first session establishment packet include: the LDP version, the label distribution mode, the value of the keepalive hold timer, the maximum PDU length, and the label space. In this case, the router <NUM> has the capabilities of the LDP version, the label distribution mode, the value of the keepalive hold timer, the maximum PDU length, and the label space for the newly established LDP session, and does not have the capability of filtering the protocol packet, for example, the outbound label filtering OLF capability and the inbound label filtering ILF capability.

<FIG> is a flowchart according to an embodiment of this application. This embodiment provides a method for session protection. A specific method is as follows:.

S401: Determine that a failure occurs in a session between a first device and a second device.

In some embodiments, both the first device and the second device are routing devices. A BGP session has been established between the first device and the second device. Because a BPG capability in the BGP session is incorrectly configured, the established BGP session is terminated in this case. When the first device and the second device re-establish a BGP session, because the BGP capability carried on the BGP session is not adjusted or modified, the re-established BGP session is abnormally terminated again due to the foregoing reason. If a network administrator does not perform manual intervention, the foregoing failure occurs repeatedly. Consequently, network link flapping is caused, BGP route control information cannot be transmitted based on the BGP session, and a network service cannot be normally transmitted. For example, the first device, for example, the router <NUM> shown in <FIG>, and the second device, for example, the router <NUM> shown in <FIG>, establish a BGP session, for example, the BGP session <NUM> shown in <FIG>. The first device and the second device negotiate a BGP capability, including an IPv4 flowspec capability, supported by both parties. A network in which the first device and the second device are located needs to forward some data packets via a BGP flowspec route. In this case, the first device defines a data packet forwarding policy and implements the policy by enabling the BGP flowspec route. A BGP flowspec route capability of the first device is incorrectly configured, for example, a quintuple of a data packet defined in the BGP flowspec policy is incorrectly configured. In this case, a BGP keepalive protocol packet between the first device and the second device matches the BGP flowspec policy, and is forwarded by the first device to another routing device, but is not sent to the second device. In this case, according to a BGP mechanism, the second device does not receive the BGP keepalive protocol packet within a specified time period, so that the BGP session is terminated. The first device discovers that the previously established BGP session is terminated and starts establishment of the BGP session with the second device. When the first device and the second device re-establish the BGP session, a BGP flowspec capability carried on the re-established BGP session is not adjusted or modified. As a result, the re-established BGP session is terminated abnormally again due to the foregoing reason. If the network administrator does not perform manual intervention, the foregoing failure occurs repeatedly. Consequently, the network link flapping is caused, the BGP route control information cannot be transmitted based on the BGP session, and the network service cannot be normally transmitted. In some embodiments, the BGP session failure includes: (<NUM>) Abnormal session termination occurs once; and (<NUM>) A quantity of times of session termination exceeds a threshold within a specified time period. A manner of determining that a session failure occurs is classified based on a subject that determines the failure, and includes automatic determining and manual determining. The automatic determining means that a routing device that supports the BGP automatically determines that a session failure occurs upon a quantity of BGP session failures satisfies a rule for failure reporting according to a session failure reporting rule. The manual determining means that the network administrator manually determines whether the failure occurs in the BGP session. For example, according to the session failure reporting rule, the routing device automatically determines that the failure occurs in the session if the session is terminated for more than three times within <NUM> minutes. The network administrator finds, by viewing a device log, that the session is terminated twice within <NUM> minutes, and the network administrator manually determines that the failure occurs in the session.

In some embodiments, both the first device, for example, the router <NUM> shown in <FIG>, and the second device, for example, the router <NUM> shown in <FIG>, support an LDP, and an LDP session is established between the first device and the second device. The established LDP session is terminated because an LDP capability is incorrectly configured. When the first device and the second device re-establish an LDP session, the LDP capability carried on the LDP session is not adjusted or modified. As a result, the re-established LDP session is terminated abnormally again due to the foregoing reason. If the network administrator does not perform manual intervention, the foregoing failure occurs repeatedly, and the service is interrupted due to network flapping. For example, the LDP session is established between the first device and the second device, and capabilities, including an outbound label filtering OLF capability, supported by both the first device and the second device are negotiated. In this case, the first device defines an OLF policy. Because an LDP OLF capability of the first device is incorrectly configured, an LDP keepalive protocol packet between the first device and the second device is filtered out, and is not sent to the second device. In this case, the second device does not receive the LDP keepalive protocol packet within a specified time period, so that the LDP session is terminated. In this case, when the first device and the second device re-establish the LDP session, the LDP OLF capability carried on the LDP session is not adjusted or modified. As a result, the re-established LDP session is terminated abnormally again due to the foregoing reason. If the network administrator does not perform manual intervention, the foregoing failure occurs repeatedly, and the service is interrupted due to the network flapping.

In some embodiments, the LDP session failure includes: (<NUM>) Abnormal session termination occurs once; and (<NUM>) A quantity of times of session termination exceeds a threshold within a specified time period. A manner of determining that a session failure occurs is classified based on a subject that determines the failure, and includes automatic determining and manual determining. The automatic determining means that a label switching routing device that supports the LDP automatically determines that a session failure occurs upon a quantity of LDP session failures satisfies a rule for failure reporting according to a session failure reporting rule. The manual determining means that the network administrator manually determines whether the failure occurs in the LDP session. For example, according to the session failure reporting rule, the routing device automatically determines that the failure occurs in the session if the session is terminated for more than three times within <NUM> minutes. The network administrator finds, by viewing a device log, that the session is terminated twice within <NUM> minutes, and the network administrator manually determines that the failure occurs in the session.

S403: After the failure occurs, the first device sends, to the second device, a first session establishment packet used to establish a new session, where the first session establishment packet carries capability information of the first device, and the capability information of the first device indicates that the first device does not have a capability of filtering a protocol packet for the new session.

In some embodiments, it is determined, by performing operation <NUM>, that the failure occurs in the BGP session between the first device and the second device. The first device sends the first session establishment packet to the second device. The first session establishment packet, for example, a BGP open packet, is used to establish a new BGP session. The first session establishment packet carries the capability information of the first device. The capability information of the first device indicates that the first device does not have the capability of filtering the protocol packet for the new session. For example, the capabilities of the first device carried in the first session establishment packet include: an IPv4 unicast (IPv4 Unicast), an IPv4 multicast (IPv4 Multicast), an IPv4 flowspec (IPv4 Flowspec), an IPv6 unicast (IPv6 Unicast), an IPv6 flowspec (IPv6 Flowspec), and a route refresh capability (Route Refresh Capability). For example, when the failure occurs in the BGP session between the router <NUM> and the router <NUM>, the router <NUM> sends the first session establishment packet to the router <NUM>, where the BGP capabilities of the first session establishment packet include: the IPv4 unicast (IPv4 Unicast) and the route refresh capability (Route Refresh Capability). In this case, the router <NUM> has the IPv4 unicast (IPv4 Unicast) and the route refresh capability (Route Refresh Capability) for the newly established BGP session, and does not have the capability of filtering the protocol packet, for example, a BGP flowspec capability.

In some embodiments, it is determined, by performing operation <NUM>, that the failure occurs in the LDP session between the first device and the second device. The first device sends the first session establishment packet to the second device. The first session establishment packet, for example, an LDP initialization packet, is used to establish the LDP session. The first session establishment packet carries the capability information of the first device. The capability information of the first device indicates that the first device does not have the capability of filtering the protocol packet for the new session. For example, capabilities for supporting an LDP label switching routing device include: an LDP protocol version, a label distribution mode, a value of a keepalive hold timer, a maximum PDU length, a label space, an outbound label filtering OLF capability, and an inbound label filtering ILF capability. For example, when the failure occurs in the LDP session between the router <NUM> and the router <NUM>, the router <NUM> sends the first session establishment packet to the router <NUM>, where LDP capabilities of the first session establishment packet include: the LDP version, the label distribution mode, the value of the keepalive hold timer, the maximum PDU length, and the label space. In this case, the router <NUM> has the capabilities of the LDP version, the label distribution mode, the value of the keepalive hold timer, the maximum PDU length, and the label space for the newly established LDP session, and does not have the capability of filtering the protocol packet, for example, the outbound label filtering OLF capability and the inbound label filtering ILF capability.

S405: The first device receives a second session establishment packet that is sent by the second device and that is used to establish the new session, where the second session establishment packet carries capability information of the second device, and the capability information of the second device indicates that the second device does not have the capability of filtering the protocol packet for the new session.

In some embodiments, after receiving the first session establishment packet sent by the first device in operation S403, the second device sends, to the first device, the second session establishment packet used to establish the new session. In this case, the first device receives the second session establishment packet that is sent by the second device and that is used to establish the new session. The second session establishment packet, for example, a BGP open packet, is a packet used to establish the new session. The second session establishment packet carries the capability information of the second device. The first device receives the second session establishment packet sent by the second device, where the second session establishment packet carries the capability information of the second device, and the capability information of the second device indicates that the second device does not have the capability of filtering the protocol packet for the new session. For example, capabilities of the second device for the BGP session include: an IPv4 unicast (IPv4 Unicast), an IPv4 multicast (IPv4 Multicast), an IPv4 flowspec (IPv4 Flowspec), an IPv6 unicast (IPv6 Unicast), an IPv6 flowspec (IPv6 Flowspec), and a route refresh capability (Route Refresh Capability). For example, when the failure occurs in the BGP session between the router <NUM> and the router <NUM>, the router <NUM> sends the first session establishment packet to the router <NUM>; after receiving the first session establishment packet, the router <NUM> sends the second session establishment packet to the router <NUM>, where BGP capabilities of the router <NUM> carried in the second session establishment packet include: the IPv4 unicast (IPv4 Unicast) and the route refresh capability (Route Refresh Capability). In this case, the router <NUM> has the IPv4 unicast (IPv4 Unicast) and the route refresh capability (Route Refresh Capability) for the newly established BGP session, and does not have the capability of filtering the protocol packet, for example, the BGP flowspec capability.

In some embodiments, after receiving the first session establishment packet sent by the first device in operation S403, the second device sends, to the first device, the second session establishment packet used to establish the new session. The second session establishment packet, for example, an LDP initialization packet, is used to establish the new session. The second session establishment packet carries the capability information of the second device. The first device receives the second session establishment packet sent by the second device, where the second session establishment packet carries the capability information of the second device, and the capability information of the second device indicates that the second device does not have the capability of filtering the protocol packet for the new session. For example, capabilities of the second device for the LDP session include: an LDP version, a label distribution mode, a value of a keepalive hold timer, a maximum PDU length, a label space, an outbound label filtering OLF capability, and an inbound label filtering ILF capability. For example, when the failure occurs in the LDP session between the router <NUM> and the router <NUM>, the router <NUM> sends the first session establishment packet to the router <NUM>; and the router <NUM> sends the second session establishment packet to the router <NUM>, where LDP capabilities of the router <NUM> carried in the second session establishment packet include: the LDP version, the label distribution mode, the value of the keepalive hold timer, the maximum PDU length, and the label space. In this case, the router <NUM> has capabilities of the LDP version, the label distribution mode, the value of the keepalive hold timer, the maximum PDU length, and the label space for the newly established LDP session, and does not have the capability of filtering the protocol packet, for example, the LDP OLF or the LDP ILF capability.

S407: Establish the new session between the first device and the second device.

In some embodiments, the first device and the second device perform operation S405, and the first device and the second device establish the new session. For example, after receiving the second session establishment packet sent by the router <NUM>, the router <NUM> checks correctness of the packet and negotiates a BGP capability. Through the foregoing operations, the router <NUM> and the router <NUM> have the same BGP capabilities for the new session, both have the IPv4 unicast (IPv4 Unicast) and the route refresh capability (Route Refresh Capability), and do not have the capability of filtering the protocol packet.

In some embodiments, the first device and the second device perform operation S405, and the first device and the second device establish the new session. For example, after receiving the second session establishment packet sent by the router <NUM>, the router <NUM> checks correctness of the packet and negotiates an LDP capability. Through the foregoing operations, the router <NUM> and the router <NUM> have the same LDP capabilities for the new LDP session, and both have the LDP version, the label distribution mode, the value of the keepalive hold timer, the maximum PDU length, and the label space capability, and do not have the capability of filtering the protocol packet.

<FIG> is a flowchart according to an embodiment of this application. This embodiment provides a method for session protection. According to the method, after a session failure occurs, the session failure is to be analyzed and located. If a failure cause is successfully located, the failure is recovered based on the failure cause; or if the failure cause is not successfully located, a first device and a second device establish a new session, so as to ensure normal running of a network service. A specific method is as follows:.

S501: Determine that a failure occurs in a session between a first device and a second device.

In some embodiments, both the first device and the second device are routing devices. A BGP session has been established between the first device and the second device. Because a BPG capability in the BGP session is incorrectly configured, the established BGP session is terminated in this case. When the first device and the second device re-establish the BGP session, because the BGP capability carried on the BGP session is not adjusted or modified, the re-established BGP session is abnormally terminated again due to the foregoing reason. If a network administrator does not perform manual intervention, the foregoing failure occurs repeatedly. Consequently, network link flapping is caused, BGP route control information cannot be transmitted based on the BGP session, and a network service cannot be normally transmitted. For example, the first device, for example, the router <NUM> shown in <FIG>, and the second device, for example, the router <NUM> shown in <FIG>, establish a BGP session, for example, the BGP session <NUM> shown in <FIG>. The first device and the second device negotiate a BGP capability, including an IPv4 flowspec capability, supported by both parties. A network in which the first device and the second device are located needs to forward some data packets via a BGP flowspec route. In this case, the first device defines a data packet forwarding policy and implements the policy by enabling the BGP flowspec route. A BGP flowspec route capability of the first device is incorrectly configured, for example, a quintuple of a data packet defined in the BGP flowspec policy is incorrectly configured. In this case, a BGP keepalive protocol packet between the first device and the second device matches the BGP flowspec policy, and is forwarded by the first device to another routing device, but is not sent to the second device. In this case, according to a BGP mechanism, the second device does not receive the BGP keepalive protocol packet within a specified time period, so that the BGP session is terminated. The first device discovers that the previously established BGP session is terminated and starts establishment of the BGP session with the second device. When the first device and the second device re-establish the BGP session, a BGP flowspec capability carried on the re-established BGP session is not adjusted or modified. As a result, the re-established BGP session is terminated abnormally again due to the foregoing reason. If the network administrator does not perform manual intervention, the foregoing failure occurs repeatedly. Consequently, the network link flapping is caused, the BGP route control information cannot be transmitted based on the BGP session, and the network service cannot be normally transmitted. In some embodiments, the BGP session failure includes: (<NUM>) Abnormal session termination occurs once; and (<NUM>) A quantity of times of session termination exceeds a threshold within a specified time period. A manner of determining that a session failure occurs is classified based on a subject that determines the failure, and includes automatic determining and manual determining. The automatic determining means that a routing device that supports the BGP automatically determines that a session failure occurs upon a quantity of BGP session failures satisfies a rule for failure reporting according to a session failure reporting rule. The manual determining means that the network administrator manually determines whether the failure occurs in the BGP session. For example, according to the session failure reporting rule, the routing device automatically determines that the failure occurs in the session if the session is terminated for more than three times within <NUM> minutes. The network administrator finds, by viewing a device log, that the session is terminated twice within <NUM> minutes, and the network administrator manually determines that the failure occurs in the session.

In some embodiments, both the first device, for example, the router <NUM> shown in <FIG>, and the second device, for example, the router <NUM> shown in <FIG>, support an LDP, and an LDP session is established between the first device and the second device. The established LDP session is terminated because an LDP capability is incorrectly configured. When the first device and the second device re-establish the LDP session, the LDP capability carried on the LDP session is not adjusted or modified. As a result, the re-established LDP session is terminated abnormally again due to the foregoing reason. If the network administrator does not perform manual intervention, the foregoing failure occurs repeatedly, and the service is interrupted due to the network flapping. For example, the LDP session is established between the first device and the second device, and capabilities, including an outbound label filtering OLF capability, supported by both the first device and the second device are negotiated. In this case, the first device defines an OLF policy. Because an LDP OLF capability of the first device is incorrectly configured, an LDP keepalive protocol packet between the first device and the second device is filtered out, and is not sent to the second device. In this case, the second device does not receive the LDP keepalive protocol packet within a specified time period, so that the LDP session is terminated. In this case, when the first device and the second device re-establish the LDP session, the LDP OLF capability carried on the LDP session is not adjusted or modified. As a result, the re-established LDP session is terminated abnormally again due to the foregoing reason. If the network administrator does not perform manual intervention, the foregoing failure occurs repeatedly, and the service is interrupted due to the network flapping.

In some embodiments, the LDP session failure includes: (<NUM>) Abnormal session termination occurs once; and (<NUM>) A quantity of times of session termination exceeds a threshold within a specified time period. A manner of determining that a session failure occurs is classified based on a determining subject of the failure, including automatic determining and manual determining. The automatic determining means that a label switching routing device that supports the LDP automatically determines that a session failure occurs upon a quantity of LDP session failures satisfies a rule for failure reporting according to a session failure reporting rule. The manual determining means that the network administrator manually determines whether the failure occurs in the LDP session. For example, according to the session failure reporting rule, the routing device automatically determines that the failure occurs in the session if the session is terminated for more than three times within <NUM> minutes. The network administrator finds, by viewing a device log, that the session is terminated twice within <NUM> minutes, and the network administrator manually determines that the failure occurs in the session.

In some embodiments, for a label distribution protocol session, capabilities and parameters of two devices that establish the session are negotiated in a process of establishing the session, and session re-establishment is further supported after the session is terminated. A label distribution protocol includes the LDP, a resource reservation protocol (Resource Reservation Protocol, RSVP), and a path computation element communication protocol (Path Computation Element Communication Protocol, PCEP). In this case, the foregoing failure may occur in the label distribution protocol session. Consequently, the network link flapping is caused, LDP label distribution information cannot be transmitted based on the LDP session, and the network service cannot be normally transmitted.

S503: The first device performs failure analysis on the failure.

In some embodiments, the first device supports a local failure analysis function. In this case, the first device monitors and collects session information, and performs, by using the failure analysis function, session failure analysis on the session failure determined by the first device. The first device obtains a failure analysis result. The failure analysis result includes: a failure locating result, a failure cause analysis, and/or a failure recovery suggestion. In some embodiments, the failure analysis result includes that a failure cause of a session failure <NUM> is not located. In some embodiments, the failure analysis result includes that a failure cause of a session failure <NUM> is located, and the failure cause is that a BGP keepalive packet is filtered out according to a routing policy.

In some embodiments, a session failure analyzer is deployed in the network, and the session failure analyzer performs failure locating and failure analysis on the session failure based on reported session information, and generates a failure analysis result. The failure analysis result includes: a failure locating result, a failure cause analysis, and/or a failure recovery suggestion. In some embodiments, failure analysis result information includes that a failure cause of a session failure <NUM> is not located. In some embodiments, the failure analysis result includes that a session failure cause of a session failure <NUM> is located, and the failure cause is that a BGP keepalive packet is filtered out according to a routing policy. The first device supports session information monitoring and collection, and reports session monitoring data to the session failure analyzer. When the first device determines the session failure, the first device establishes a monitoring information transmission channel with the session failure analyzer. For example, when the first device determines that the BGP session failure occurs, the first device enables a BGP monitoring protocol (BGP Monitoring Protocol, BMP) to establish a BMP session with the session failure analyzer. The first device sends monitoring data to the session failure analyzer based on the monitoring information transmission channel. For example, the first device sends collected BGP monitoring data to the session failure analyzer based on the established BMP session. The first device receives, based on a monitoring information transmission notification, the analysis result sent by the session failure analyzer. For example, the first device receives, based on the established BMP session, the failure analysis result sent by the session failure analyzer. After receiving the analysis result sent by the session failure analyzer, the first device terminates the monitoring information transmission notification. For example, after receiving the failure analysis result, the first device terminates the BMP session.

In some embodiments, the session failure analyzer is deployed in the network, and the session failure analyzer performs failure locating and failure analysis on the session failure based on the monitoring data, and generates the failure analysis result. The first device supports session monitoring data collection and reporting of monitoring data collection data. When the first device determines that the session failure occurs, the first device establishes the monitoring information transmission channel with the session failure analyzer. For example, when the first device determines that the LDP session failure occurs, the first device establishes a transmission control protocol (Transmission Control Protocol, TCP) connection to the session failure analyzer, where the TCP connection is used to establish an LDP monitoring channel between the first device and the session failure analyzer. The first device sends monitoring data to the session failure analyzer based on the monitoring information transmission channel. For example, the first device sends collected LDP monitoring data to the session failure analyzer based on the established LDP monitoring channel. The first device receives, based on a monitoring information transmission notification, the analysis result sent by the session failure analyzer. For example, the first device receives, based on established LDP monitoring communication, the failure analysis result sent by the session failure analyzer. After receiving the analysis result sent by the session failure analyzer, the first device terminates the monitoring information transmission notification. For example, after receiving the failure analysis result, the first device terminates the LDP monitoring channel.

S505: If the failure cause is located, the failure is recovered; or if the failure cause is not located, the first device sends, to the second device, a first session establishment packet used to establish a new session, where the first session establishment packet carries capability information of the first device, and the capability information of the first device indicates that the first device does not have a capability of filtering a protocol packet for the new session.

In some embodiments, the first device obtains the failure analysis result, and determines whether the failure cause is located. If the failure cause is successfully located, the first device recovers the failure based on failure locating information, so that the session failure is recovered and the network service is restored. If the failure cause is not located, the failure cause locating fails, and the session failure continues to exist.

In some embodiments, the first device sends the first session establishment packet to the second device. The first session establishment packet, for example, a BGP open packet, is used to establish a new BGP session. The first session establishment packet carries the capability information of the first device. The capability information of the first device indicates that the first device does not have the capability of filtering the protocol packet for the new session. For example, the capabilities of the first device carried in the first session establishment packet include: an IPv4 unicast (IPv4 Unicast), an IPv4 multicast (IPv4 Multicast), an IPv4 flowspec (IPv4 Flowspec), an IPv6 unicast (IPv6 Unicast), an IPv6 flowspec (IPv6 Flowspec), and a route refresh capability (Route Refresh Capability). For example, when the failure occurs in the BGP session between the router <NUM> and the router <NUM>, the router <NUM> sends the first session establishment packet to the router <NUM>, where the BGP capabilities of the first session establishment packet include: the IPv4 unicast (IPv4 Unicast) and the route refresh capability (Route Refresh Capability). In this case, the router <NUM> has the IPv4 unicast (IPv4 Unicast) and the route refresh capability (Route Refresh Capability) for the newly established BGP session, and does not have the capability of filtering the protocol packet, for example, a BGP flowspec capability.

In some embodiments, the first device sends the first session establishment packet to the second device. The first session establishment packet, for example, an LDP initialization packet, is used to establish an LDP session. The first session establishment packet carries the capability information of the first device. The capability information of the first device indicates that the first device does not have the capability of filtering the protocol packet for the new session. For example, capabilities for supporting an LDP label switching routing device include: an LDP protocol version, a label distribution mode, a value of a keepalive hold timer, a maximum PDU length, a label space, an outbound label filtering OLF capability, and an inbound label filtering ILF capability. For example, when the failure occurs in the LDP session between the router <NUM> and the router <NUM>, the router <NUM> sends the first session establishment packet to the router <NUM>, where LDP capabilities of the first session establishment packet include: the LDP version, the label distribution mode, the value of the keepalive hold timer, the maximum PDU length, and the label space. In this case, the router <NUM> has the capabilities of the LDP version, the label distribution mode, the value of the keepalive hold timer, the maximum PDU length, and the label space for the newly established LDP session, and does not have the capability of filtering the protocol packet, for example, the outbound label filtering OLF capability and the inbound label filtering ILF capability.

S507: The first device receives a second session establishment packet that is sent by the second device and that is used to establish the new session, where the second session establishment packet carries capability information of the second device, and the capability information of the second device indicates that the second device does not have the capability of filtering the protocol packet for the new session.

In some embodiments, after receiving the first session establishment packet sent by the first device in operation S505, the second device sends, to the first device, the second session establishment packet used to establish the new session. In this case, the first device receives the second session establishment packet that is sent by the second device and that is used to establish the new session. The second session establishment packet, for example, a BGP open packet, is a packet used to establish the new session. The second session establishment packet carries the capability information of the second device. The first device receives the second session establishment packet sent by the second device, where the second session establishment packet carries the capability information of the second device, and the capability information of the second device indicates that the second device does not have the capability of filtering the protocol packet for the new session. For example, capabilities of the second device for the BGP session include: the IPv4 unicast (IPv4 Unicast), the IPv4 multicast (IPv4 Multicast), the IPv4 flowspec (IPv4 Flowspec), the IPv6 unicast (IPv6 Unicast), the IPv6 flowspec (IPv6 Flowspec), and the route refresh capability (Route Refresh Capability). For example, when the failure occurs in the BGP session between the router <NUM> and the router <NUM>, the router <NUM> sends the first session establishment packet to the router <NUM>; after receiving the first session establishment packet, the router <NUM> sends the second session establishment packet to the router <NUM>, where BGP capabilities of the router <NUM> carried in the second session establishment packet include: the IPv4 unicast (IPv4 Unicast) and the route refresh capability (Route Refresh Capability). In this case, the router <NUM> has the IPv4 unicast (IPv4 Unicast) and the route refresh capability (Route Refresh Capability) for the newly established BGP session, and does not have the capability of filtering the protocol packet, for example, the BGP flowspec capability.

In some embodiments, after receiving the first session establishment packet sent by the first device in operation S505, the second device sends, to the first device, the second session establishment packet used to establish the new session. The second session establishment packet, for example, an LDP initialization packet, is used to establish the new session. The second session establishment packet carries the capability information of the second device. The first device receives the second session establishment packet sent by the second device, where the second session establishment packet carries the capability information of the second device, and the capability information of the second device indicates that the second device does not have the capability of filtering the protocol packet for the new session. For example, capabilities of the second device for the LDP session include: the LDP version, the label distribution mode, the value of the keepalive hold timer, the maximum PDU length, the label space, the outbound label filtering OLF capability, and the inbound label filtering ILF capability. For example, when the failure occurs in the LDP session between the router <NUM> and the router <NUM>, the router <NUM> sends the first session establishment packet to the router <NUM>; and the router <NUM> sends the second session establishment packet to the router <NUM>, where LDP capabilities of the router <NUM> carried in the second session establishment packet include: the LDP version, the label distribution mode, the value of the keepalive hold timer, the maximum PDU length, and the label space. In this case, the router <NUM> has capabilities of the LDP version, the label distribution mode, the value of the keepalive hold timer, the maximum PDU length, and the label space for the newly established LDP session, and does not have the capability of filtering the protocol packet, for example, the LDP OLF or the LDP ILF capability.

S509: Establish the new session between the first device and the second device.

In some embodiments, the first device and the second device perform operation S505, and the first device and the second device establish the new session. For example, after receiving the second session establishment packet sent by the router <NUM>, the router <NUM> checks correctness of the packet and negotiates a BGP capability. Through the foregoing operations, the router <NUM> and the router <NUM> have the same BGP capabilities for the new session, both have the IPv4 unicast (IPv4 Unicast) and the route refresh capability (Route Refresh Capability), and do not have the capability of filtering the protocol packet.

In some embodiments, the first device and the second device perform operation S505, and the first device and the second device establish the new session. For example, after receiving the second session establishment packet sent by the router <NUM>, the router <NUM> checks correctness of the packet and negotiates an LDP capability. Through the foregoing operations, the router <NUM> and the router <NUM> have the same LDP capabilities for the new LDP session, and both have the LDP version, the label distribution mode, the value of the keepalive hold timer, the maximum PDU length, and the label space capability, and do not have the capability of filtering the protocol packet.

An embodiment of this application further provides a first system. The first system is configured to perform, by using modules shown in <FIG>, some or all operations performed by the router <NUM> in <FIG>. Refer to <FIG>, the first system <NUM> includes:.

In some embodiments, the first system <NUM> may further include:.

In some embodiments, the modules in the first system <NUM> may be deployed in a same physical device. In some other embodiments, the modules in the first system <NUM> may be deployed in a plurality of different physical devices. Each module in the first system <NUM> may be a hardware module or a module combining software and hardware.

It should be understood that, when the system provided in <FIG> implements functions of the system, division of the foregoing functional modules is merely used as an example for description. During actual application, the foregoing functions may be allocated to different functional modules for implementation as required. In other words, an internal structure of the system is divided into different functional modules to implement all or some of the functions described above. In addition, the system and method embodiments provided in the foregoing embodiments belong to a same concept. For a specific implementation process, refer to the method embodiments, and details are not described herein again.

<FIG> is a schematic structural diagram of a first system <NUM> according to an embodiment of this application. The first system <NUM> shown in <FIG> is configured to perform operations related to the method for session protection shown in <FIG>. As shown in <FIG>, the first system <NUM> includes at least one processor <NUM>, a connection wire <NUM>, a memory <NUM>, and at least one network interface <NUM>.

The processor <NUM> is, for example, a general-purpose central processing unit (central processing unit, CPU), a digital signal processor (digital signal processor, DSP), a network processor (network processor, NP), a graphics processing unit (Graphics Processing Unit, GPU), a neural-network processing unit (neural-network processing unit, NPU), a data processing unit (Data Processing Unit, DPU), a microprocessor, or one or more integrated circuits configured to implement solutions of this application. For example, the processor <NUM> includes an application-specific integrated circuit (application-specific integrated circuit, ASIC), a programmable logic device (programmable logic device, PLD) or another programmable logic device, a transistor logic device, a hardware component, or any combination thereof. The PLD is, for example, a complex programmable logic device (complex programmable logic device, CPLD), a field programmable gate array (field programmable gate array, FPGA), generic array logic (generic array logic, GAL), or any combination thereof. The processor <NUM> may implement or execute various logical blocks, modules, and circuits described with reference to content disclosed in embodiments of the present invention. Alternatively, the processor may be a combination of processors implementing a computing function, for example, a combination of one or more microprocessors, or a combination of the DSP and the microprocessor.

The first system <NUM> may further include a connection wire <NUM>. The connection wire <NUM> is configured to transfer information between components of the first system <NUM>. A bus may be a peripheral component interconnect (peripheral component interconnect, PCI) bus or an extended industry standard architecture (extended industry standard architecture, EISA) bus, or the like. Buses may be classified into an address bus, a data bus, a control bus, and the like. For ease of representation, only one bold line is used for representation in <FIG>, but this does not mean that there is only one bus or only one type of bus.

The memory <NUM> is, for example, a read-only memory (read-only memory, ROM) or another type of static storage device that can store static information and instructions, or a random access memory (random access memory, RAM) or another type of dynamic storage device that can store information and instructions, or an electrically erasable programmable read-only memory (electrically erasable programmable read-only Memory, EEPROM), a compact disc read-only memory (compact disc read-only memory, CD-ROM) or another compact disc storage, an optical disc storage (including a compact disc, a laser disc, an optical disc, a digital versatile disc, a Blu-ray disc, and the like), a magnetic disk storage medium or another magnetic storage device, or any other medium that can be used to carry or store expected program code in a form of instructions or a data structure and that can be accessed by a computer, but is not limited thereto. For example, the memory <NUM> exists independently, and is connected to the processor <NUM> by the bus. Alternatively, the memory <NUM> may be integrated with the processor <NUM>.

The network interface <NUM> uses any apparatus such as a transceiver to communicate with another device or a communication network. The communication network may be the Ethernet, a radio access network (RAN), a wireless local area network (wireless local area network, WLAN), or the like. The network interface <NUM> may include a wired communication interface, and may further include a wireless communication interface. Specifically, the network interface <NUM> may be an Ethernet (Ethernet) interface, a fast Ethernet (Fast Ethernet, FE) interface, a gigabit Ethernet (Gigabit Ethernet, GE) interface, an asynchronous transfer mode (Asynchronous Transfer Mode, ATM) interface, a wireless local area network (wireless local area network, WLAN) interface, a cellular network communication interface, or a combination thereof. The Ethernet interface may be an optical interface, an electrical interface, or a combination thereof. In this embodiment of this application, the network interface <NUM> may be used by the first system <NUM> to communicate with another device.

In specific implementation, in an embodiment, the processor <NUM> may include one or more CPUs. Each of the processors may be a single-core processor, or may be a multi-core processor. The processor herein may be one or more devices, circuits, and/or processing cores configured to process data (for example, computer program instructions).

In specific implementation, in an embodiment, the first system <NUM> may include a plurality of processors. Each of the processors may be a single-core processor, or may be a multi-core processor. The processor herein may be one or more devices, circuits, and/or processing cores configured to process data (for example, computer program instructions).

In specific implementation, in an embodiment, the first system <NUM> may further include an output device and an input device. The output device communicates with the processor <NUM>, and may display information in a plurality of manners. For example, the output device may be a liquid crystal display (liquid crystal display, LCD), a light emitting diode (light emitting diode, LED) display device, a cathode ray tube (cathode ray tube, CRT) display device, or a projector (projector). The input device communicates with the processor <NUM>, and may receive an input from a user in a plurality of manners. For example, the input device may be a mouse, a keyboard, a touchscreen device, or a sensing device.

In some embodiments, the memory <NUM> is configured to store a program module and data. The program module includes a session failure determining module <NUM>, a session establishment packet sending module <NUM>, a session establishment packet receiving module <NUM>, a failure analysis module <NUM>, a monitoring channel establishment module <NUM>, a monitoring information sending module <NUM>, an analysis information receiving module <NUM>, and a monitoring channel termination module <NUM>. In some embodiments, the modules in the memory <NUM> in <FIG> correspond to the modules shown in <FIG>. The processor <NUM> can perform, by executing the computer readable instructions in the modules in the memory <NUM>, operations that can be performed by the modules shown in <FIG>.

In a specific embodiment, the first system <NUM> in this embodiment of this application may be corresponding to the foregoing plurality of embodiments, for example, the first system in the plurality of embodiments corresponding to <FIG>. The processor <NUM> in the first system <NUM> reads the instruction in the memory <NUM>, so that the first system <NUM> shown in <FIG> can perform all or some operations performed by the first system in the foregoing plurality of embodiments.

Although a plurality of operations and modules are disclosed in embodiments of this application, for some technical problems, these operations and modules are not all mandatory.

An operation sequence in the specification, claims, and accompanying drawings of this application is not limited to a specific sequence or sequence in the description. It should be understood that the data used in such a way are simultaneous or may be altered in appropriate circumstances so that the described embodiments can be implemented in order other than the order illustrated or described in the accompanying drawings.

The foregoing one or more technical solutions in embodiments of this application have at least the following technical effects:.

Claim 1:
A method for session protection, said method comprising the steps of :
determining (S301, S401), by a first device (<NUM>), that a failure occurs in a session between the first device (<NUM>) and a second device (<NUM>); and
sending (S303, S403), by the first device (<NUM>), to the second device (<NUM>) after the failure occurs, a first session establishment packet used to establish a new session, wherein the first session establishment packet carries capability information of the first device (<NUM>), and the capability information of the first device (<NUM>) indicates that the first device does not have a capability of filtering a protocol packet for the new session;
wherein the method further comprises the steps of :
receiving (S405), by the first device (<NUM>), after the failure occurs, a second session establishment packet that is sent by the second device (<NUM>) and that is used to establish the new session, wherein the second session establishment packet carries capability information of the second device (<NUM>), and the capability information of the second device (<NUM>) indicates that the second device (<NUM>) does not have the capability of filtering the protocol packet for the new session; and
establishing (S407), by the first device (<NUM>), the new session based on the first session establishment packet and the second session establishment packet, wherein the new session does not have the capability of filtering the protocol packet.