Path detection method and device and related equipment

Abstract

The invention relates to the technical field of network communication, in particular to a path detection method and device and related equipment. The method comprises the following steps: judging whether a to-be-detected client supports a path detection configuration issuing function or not; when it is judged that the to-be-detected client supports the path detection configuration issuing function, path detection configuration corresponding to the to-be-detected client is carried in a path computation element communication protocol PCEP extension message and issued to the to-be-detected client, so that the to-be-detected client carries out path detection based on the path detection configuration.

Description

Technical Field

[0001] The present application relates to the field of network communication technology, and in particular to a path detection method, device and related equipment. Background Art

[0002] TWAMP (Two-Way Active Measurement Protocol) is a measurement technology used to monitor performance such as packet loss, latency, and jitter. It is an extension of OWAMP (One-Way Active Measurement Protocol) and supports bidirectional measurement. TWAMP is commonly used to monitor network quality and help network administrators diagnose and optimize network performance. TWAMP negotiates over TCP connections and uses UDP packets for measurement. Currently, controllers use the Network Configuration (Netconf) protocol to distribute client and server configurations to source and destination devices. The Netconf protocol is a network management protocol based on Extensible Markup Language (XML) that provides a programmable method for configuring and managing network devices. When the controller distributes configuration information to a node via the Netconf protocol, the node must wait for the configuration command to be triggered, making it impossible for the node to quickly deploy TWAMP services. This results in poor performance when configuring TWAMP on network devices via the Netconf protocol. Summary of the Invention

[0003] The present application provides a path detection method, apparatus and related equipment.

[0004] In a first aspect, the present application provides a path detection method, the method comprising:

[0005] Determine whether the client to be detected supports the path detection configuration delivery function;

[0006] When it is determined that the client to be detected supports the path detection configuration sending function, the path detection configuration corresponding to the client to be detected is carried in the path calculation unit communication protocol PCEP extended message and sent to the client to be detected, so that the client to be detected performs path detection based on the path detection configuration.

[0007] Optionally, the method is applied to a path computation element (PCE), the client to be detected is a path computation client (PCC) to be detected, the PCEP protocol predefines a first TLV field whose Type is a first value, the first TLV field represents the PCC to be detected, and the PCE supports path detection configuration delivery; the step of determining whether the client to be detected supports the path detection configuration delivery function includes:

[0008] When negotiating a session with the PCC to be detected, the PCE sends a PCEP session start message to the PCC.

[0009] Receive a PCEP session start message sent by the PCC to be detected, and determine whether the PCEP session start message carries the first TLV field.

[0010] Optionally, the path detection configuration is a Bidirectional Active Measurement Protocol (TWAMP) configuration.

[0011] Optionally, the PCEP protocol predefines a second TLV field in which the Type field is a second value and the Value field carries a path detection configuration; and the step of carrying the path detection configuration corresponding to the client to be detected in a Path Computation Unit Communication Protocol (PCEP) extended message and sending the message to the client to be detected includes:

[0012] The path detection configuration corresponding to the client to be detected is filled into the Value field of the second TLV field, and the second TLV field is carried in a PCEP message and sent to the client to be detected.

[0013] Optionally, the PCEP message is used to instruct the client to be detected to create an SR / SRv6 tunnel; the path detection configuration carried in the second TLV field of the PCEP message is used to instruct the client to be detected to use the source and destination of the created SR / SRv6 tunnel as the source and destination of the control session and test session of the TWAMP detection.

[0014] Optionally, the PCEP protocol predefines a third TLV field whose Type field is a third value and whose Value field carries updated path detection parameters. The method further includes:

[0015] If it is determined that the TWAMP detection parameters of the client to be detected need to be updated, the TWAMP detection parameters to be updated are carried in the third TLV field and sent to the client to be detected through a PCUpd message.

[0016] Optionally, the PCEP protocol predefines a fourth TLV field whose Type field is a fourth value and whose Value field carries a path detection result. The method further includes:

[0017] Receive a PCRpt message carrying the fourth TLV field sent by the client to be detected;

[0018] Parse the fourth TLV field carried in the PCRpt message to obtain a path detection result.

[0019] In a second aspect, the present application provides a path detection device, the device comprising:

[0020] A judgment unit, used to judge whether the client to be detected supports the path detection configuration delivery function;

[0021] The sending unit is used to carry the path detection configuration corresponding to the client to be detected in the path calculation unit communication protocol PCEP extended message and send it to the client to be detected when it is determined that the client to be detected supports the path detection configuration sending function, so that the client to be detected performs path detection based on the path detection configuration.

[0022] Optionally, the device is applied to a path computation element (PCE), the client to be detected is a path computation client (PCC) to be detected, the PCEP protocol pre-defines a first TLV field whose Type is a first value, the first TLV field represents the PCC to be detected, and the PCE supports path detection configuration delivery; when determining whether the client to be detected supports the path detection configuration delivery function, the determining unit is specifically configured to:

[0023] When negotiating a session with the PCC to be detected, the two parties exchange a PCEP session start message.

[0024] Receive a PCEP session start message sent by the PCC to be detected, and determine whether the PCEP session start message carries the first TLV field.

[0025] Optionally, the path detection configuration is a Bidirectional Active Measurement Protocol (TWAMP) configuration.

[0026] Optionally, the PCEP protocol predefines a second TLV field in which the Type field is a second value and the Value field carries a path detection configuration; when the path detection configuration corresponding to the client to be detected is carried in a Path Computation Unit Communication Protocol (PCEP) extended message and delivered to the client to be detected, the delivering unit is specifically configured to:

[0027] The path detection configuration corresponding to the client to be detected is filled into the Value field of the second TLV field, and the second TLV field is carried in a PCEP message and sent to the client to be detected.

[0028] Optionally, the PCEP message is used to instruct the client to be detected to create an SR / SRv6 tunnel; the path detection configuration carried in the second TLV field of the PCEP message is used to instruct the client to be detected to use the source and destination of the created SR / SRv6 tunnel as the source and destination of the control session and test session of the TWAMP detection.

[0029] Optionally, the PCEP protocol predefines a third TLV field whose Type is a third value and whose Value field carries updated path detection parameters. The apparatus further includes:

[0030] The updating unit is configured to, if it is determined that the TWAMP detection parameters of the client to be detected need to be updated, carry the TWAMP detection parameters to be updated in a third TLV field and send the updated TWAMP detection parameters to the client to be detected via a PCUpd message.

[0031] Optionally, the PCEP protocol predefines a fourth TLV field whose Type is a fourth value and whose Value field carries a path detection result. The apparatus further includes:

[0032] A receiving unit, configured to receive a PCRpt message carrying a fourth TLV field, sent by a client to be detected;

[0033] The parsing unit is configured to parse the fourth TLV field carried by the PCRpt message to obtain a path detection result.

[0034] In a third aspect, an embodiment of the present application provides a path detection device, the path detection device comprising:

[0035] a memory for storing program instructions;

[0036] The processor is configured to call the program instructions stored in the memory and execute the steps of the method as described in any one of the first aspects above according to the obtained program instructions.

[0037] In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to enable the computer to execute the steps of the method described in any one of the above-mentioned first aspects.

[0038] In summary, the path detection method provided in the embodiment of the present application determines whether the client to be detected supports the path detection configuration sending function; when it is determined that the client to be detected supports the path detection configuration sending function, the path detection configuration corresponding to the client to be detected is carried in the path calculation unit communication protocol PCEP extended message and sent to the client to be detected, so that the client to be detected performs path detection based on the path detection configuration.

[0039] By adopting the path detection method provided in the embodiment of the present application, the path detection configuration is sent to the detection device through the PECP extended message by extending the PCEP protocol message, which simplifies the process of the detection task and improves the efficiency of creating the detection configuration.

[0040] Furthermore, after determining the path information of the SR / SRv6 tunnel and the set TWAMP parameters, the PCE sends the path information and TWAMP parameters to the PCC. The PCC then completes the path establishment and path detection session creation based on the information. As can be seen, in this embodiment of the present application, the initiator of path establishment and the initiator of path detection are the same device. This allows users to complete path establishment and path detection using the same device, reducing the difficulty of network maintenance. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments of the present application or the description of the prior art. Obviously, the drawings described below are only some embodiments recorded in this application. For ordinary technicians in this field, other drawings can also be obtained based on these drawings of the embodiments of the present application.

[0042] Figure 1 A detailed flow chart of a path detection method provided in an embodiment of the present application;

[0043] Figure 2 A schematic diagram of the message format of a TWAMP-CAPABILITY TLV provided in an embodiment of the present application;

[0044] Figure 3 A schematic diagram of the TWAMP-SESSION-TLV message format provided in an embodiment of the present application;

[0045] Figure 4 A schematic diagram of the TWAMP-RESULT-TLV message format provided in an embodiment of the present application;

[0046] Figure 5 A schematic diagram of a path detection process provided in an embodiment of the present application;

[0047] Figure 6 A schematic structural diagram of a path detection device provided in an embodiment of the present application;

[0048] Figure 7 A schematic diagram of the hardware architecture of a path detection device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0049] The terms used in the embodiments of this application are only for the purpose of describing specific embodiments and are not intended to limit this application. The singular forms "a," "the," and "the" used in this application and claims are also intended to include plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used herein refers to any or all possible combinations of one or more associated listed items.

[0050] It should be understood that although the terms first, second, third, etc. may be used to describe various information in the embodiments of the present application, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, without departing from the scope of the present application, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" used may also be interpreted as "at the time of" or "when" or "in response to determining".

[0051] In an MPLS / SRv6 network that supports the Path Computation Element Protocol (PCEP), the PCE server on the controller can trigger SR / SRv6 tunnel creation, active SR / SRv6 tunnel updates, and tunnel deletion based on the PCEP protocol's Active Stateful PCE (Path Computation Element) mode.

[0052] As a centralized path calculation entity, PCE can perform optimal path calculation based on the global network view, avoiding the local optimal problem in distributed computing; it supports cross-domain path calculation and can coordinate path information between multiple domains. At the same time, PCEP is an IETF standard protocol with good interoperability; the PCEP protocol is flexible in design and easy to expand. In view of these advantages, in the embodiment of the present application, by extending the PCEP protocol and adding TWAMP protocol related parameter information, the active measurement function during tunnel creation is realized, and the PCRpt message content can also be added to inform the PCE of the performance indicators of the current tunnel, simplifying the SLA solution of the control component.

[0053] For example, see Figure 1 FIG. 1 is a detailed flow chart of a path detection method provided in an embodiment of the present application, and the method includes the following steps:

[0054] Step 100: Determine whether the client to be detected supports the path detection configuration delivery function.

[0055] In an embodiment of the present application, the path detection method can be applied to a path computation element (PCE), which can be integrated into a controller. The client to be detected is a path computation client (PCC) to be detected. The PCEP protocol predefines a first TLV field with a Type value of a first value, the first TLV field represents the PCC to be detected, and the PCE supports the delivery of path detection configurations.

[0056] In the embodiment of the present application, the path detection configuration is a Bidirectional Active Measurement Protocol (TWAMP) configuration. Specifically, the TWAMP detection function is extended on the basis of the PCEP protocol, so that the PCEP extended protocol message can carry the TWAMP detection configuration.

[0057] Specifically, when determining whether the client to be detected supports the path detection configuration delivery function, a preferred implementation method is:

[0058] When performing session negotiation with the PCC to be detected, the PCE sends a start PCEP session message to each other; receives the start PCEP session message sent by the PCC to be detected, and determines whether the start PCEP session message carries the first TLV field.

[0059] For example, during the session negotiation phase between the Path Computation Client (PCC) and the Path Computation Element (PCE), the PCEP session start message is sent to each other to negotiate whether the TWAMP configuration delivery capability is supported. A new CAPABILITY TLV, namely TWAMP-CAPABILITY TLV, needs to be defined. For example, see Figure 2 , which is a schematic diagram of a TWAMP-CAPABILITY TLV message format provided in an embodiment of the present application.

[0060] The fields are described as follows:

[0061] Type: TBD1 (first value, assigned by IANA);

[0062] Length: The remaining byte length except Type;

[0063] Reserved: reserved position;

[0064] Flags: reserved flags.

[0065] Step 110: When it is determined that the client to be detected supports the path detection configuration sending function, the path detection configuration corresponding to the client to be detected is carried in the path calculation unit communication protocol PCEP extended message and sent to the client to be detected, so that the client to be detected performs path detection based on the path detection configuration.

[0066] In the embodiment of the present application, the PCEP protocol predefines a second TLV field in which Type is the second value and the Value field carries the path detection configuration.

[0067] Then, when the path detection configuration corresponding to the client to be detected is carried in a Path Computation Element Communication Protocol (PCEP) extension message and sent to the client to be detected, a preferred implementation method is as follows:

[0068] The path detection configuration corresponding to the client to be detected is filled into the Value field of the second TLV field, and the second TLV field is carried in a PCEP message and sent to the client to be detected.

[0069] In practice, the PCInitiate extension can carry TWAMP configuration parameters. The PCInitiate message is a PCEP message type used by the PCE to proactively deliver path policies to the PCC without the PCC explicitly requesting it. When the extension supports carrying TWAMP detection parameters, a new TWAMP parameter TLV message is added to the Label Switched Path Initialization Request message.

[0070] Furthermore, a TWAMP-SESSION-TLV is added to the Association Object object to specify the TWAMP parameters (source port, destination port, aging time, etc.) applied to the SR / SRv6 tunnel. Figure 3 , which is a schematic diagram of a TWAMP-SESSION-TLV message format provided in an embodiment of the present application.

[0071] Field Description:

[0072] Type: TBD2 (second value, assigned by IANA);

[0073] Length: The remaining byte length except Type;

[0074] Reserved: reserved position;

[0075] Flags: Reserved flags. Currently, only the P and R bits are defined. Set P to 1 when session parameters change and set R to 1 when a detection session needs to be deleted. Set P and R to 0 in the PCInitiate message. The PCC should ignore any non-zero values ​​received.

[0076] Control Session Name: 16 bits in length, control session name;

[0077] Sender Port: 16 bits in length, used to detect the source port of the session;

[0078] Reflector Port: 16 bits in length, used to detect the destination port of the session.

[0079] Server timeout: 16 bits in length, controls the session aging time;

[0080] Reflector timeout: 16 bits in length, used to test the session aging time.

[0081] In an embodiment of the present application, the PCEP message filled with the Value field of the second TLV field is used to instruct the client to be detected to create an SR / SRv6 tunnel; the path detection configuration carried by the second TLV field of the PCEP message is used to instruct the client to be detected to use the source and destination of the created SR / SRv6 tunnel as the source and destination of the control session and test session of the TWAMP detection.

[0082] Specifically, after receiving the PCInitiate message containing the TWAMP-SESSION-TLV, the PCC first creates an SR / SRv6 tunnel based on the triplet (headend, color, endpoint) defined by the Association Object, the preference, and the label information defined by the ERO Object. It determines whether the global TWAMP parameter configuration function of the PCC device is enabled. If not, the TWAMP-SESSION-TLV is ignored and no TWAMP detection task is created. If enabled, a TWAMP detection task is created with the tunnel source and destination as the control session and the test session source and destination for TWAMP detection to detect performance indicators along the label-defined path. If the PCInitiate contains the PATH-ATTRIB Object, that is, multiple load-balanced paths are defined under the tunnel, the TWAMP detection also needs to create multiple test sessions at the same time, corresponding to multiple label paths.

[0083] Furthermore, in the embodiment of the present application, the PCEP protocol predefines a third TLV field whose Type field is a third value and whose Value field carries updated path detection parameters. The path detection method further includes the following steps:

[0084] If it is determined that the TWAMP detection parameters of the client to be detected need to be updated, the TWAMP detection parameters to be updated are carried in the third TLV field and sent to the client to be detected through a PCUpd message.

[0085] In the embodiment of the present application, TWAMP related parameters can also be carried through the PCUpd extension.

[0086] PCUpd is a mechanism or message related to path calculation that dynamically updates path calculation information within the network, helping the network select more optimal paths, thereby reducing latency and packet loss or improving bandwidth utilization. PCUpd is triggered when the network topology changes or path performance does not meet requirements.

[0087] If the TWAMP detection parameters need to be modified or the TWAMP detection capability needs to be canceled, the TWAMP-SESSION-TLV can be carried. The TLV definition is as follows Figure 3 As shown. If the detection parameters need to be modified, set the P bit to 1, and the parameters are changed. After the PCC receives the message, it updates the parameters of the corresponding TWAMP control session and test session. If the TWAMP detection capability is to be canceled, the R bit can be set to 1. After the PCC receives the PCUpd message with R=1, it deletes the TWAMP detection control session and test session related to the tunnel. Among them, the third value can be the same as the second value, or a third value different from the second value can be defined for the TLV used to update the detection parameters or cancel the TWAMP detection capability. In the embodiment of the present application, no specific limitation is made here.

[0088] Furthermore, in the embodiment of the present application, the PCEP protocol predefines a fourth TLV field whose Type field is a fourth value and whose Value field carries a path detection result. The method further includes:

[0089] Receive a PCRpt message carrying the fourth TLV field sent by the client to be detected;

[0090] Parse the fourth TLV field carried in the PCRpt message to obtain a path detection result.

[0091] In the embodiment of the present application, the TWAMP detection result can also be carried through the PCRpt extension.

[0092] For example, PCRpt is a message type in the Path Computation Element (PCE) architecture, which is used to report the results or status of the path calculation. When the status of the path changes (such as path failure or recovery), PCRpt is used to report the latest path status. By extending the PCRpt message and increasing the reporting of TWAMP detection results, the control unit PCE underlay network topology performance can be promptly notified. A new TWAMP-RESULT-TLV is added to describe the control session and the status of the control session, and sub-TLVs are defined, which reference RFC 8571's TLV descriptions of delay, jitter, and packet loss to announce performance indicators. For example, see Figure 4 As shown, it is a schematic diagram of the message format of TWAMP-RESULT-TLV provided in an embodiment of the present application.

[0093] Field Description:

[0094] Type:TBD3 (IANA assigned)

[0095] Length: The remaining byte length except Type.

[0096] Reserved: Reserved

[0097] Flags: Reserved flags. Currently, only the C and T bits are defined. A C bit set to 1 indicates that the control session is in the Active state. A T bit set to 1 indicates that the test session is in the Active state.

[0098] Control Session Name: 16 bits in length, control session name

[0099] Optional TLV: can carry sub-TLVs. For details, see the descriptions of Unidirectional Link Delay TLV, Min / Max Unidirectional Link Delay TLV, Unidirectional Delay Variation TLV, and Unidirectional Link Loss TLV in RFC 8571.

[0100] That is, the control unit PCE receives the PCRpt message, checks whether the reported performance indicators meet the SLA service quality requirements, and further determines whether to trigger path recalculation.

[0101] The path detection process provided by the embodiment of the present application is described in detail below in conjunction with specific application scenarios. Figure 5 , which is a schematic diagram of a path detection process provided in an embodiment of the present application.

[0102] The PCE and PCC exchange open messages carrying the TWAMP-CAPABILITY TLV to inform each other that they support TWAMP configuration delivery capabilities and maintain activity through keepalives.

[0103] The PCE sends an extended PCInitiateMESSAGE message carrying the Association Object extended TWAMP-SESSION-TLV to the PCC. The PCC creates a path detection task based on the path detection configuration in the TWAMP-SESSION-TLV.

[0104] PCC sends PCRpt MESSAGE to PCE;

[0105] Whether the global TWAMP parameter configuration function is enabled on the PCC. If so, the PCC sends an extended PCRpt message carrying the TWAMP-RESULT-TLV to the PCE to feedback the detection result.

[0106] Furthermore, if it is determined that the configuration parameters of the detection task need to be updated, the PCC sends a PCUpd MESSAGE carrying the Association Object extension TWAMP–SESSION-TLV with the P bit set to 1;

[0107] The PCC sends a PCRpt MESSAGE to the PCE.

[0108] For example, see Figure 6 FIG. 1 is a schematic diagram of a path detection device provided in an embodiment of the present application, the device comprising:

[0109] A judgment unit, used to judge whether the client to be detected supports the path detection configuration delivery function;

[0110] The sending unit is used to carry the path detection configuration corresponding to the client to be detected in the path calculation unit communication protocol PCEP extended message and send it to the client to be detected when it is determined that the client to be detected supports the path detection configuration sending function, so that the client to be detected performs path detection based on the path detection configuration.

[0111] Optionally, the device is applied to a path computation element (PCE), the client to be detected is a path computation client (PCC) to be detected, the PCEP protocol pre-defines a first TLV field whose Type is a first value, the first TLV field represents the PCC to be detected, and the PCE supports path detection configuration delivery; when determining whether the client to be detected supports the path detection configuration delivery function, the determining unit is specifically configured to:

[0112] When negotiating a session with the PCC to be detected, the two parties exchange a PCEP session start message.

[0113] Receive a PCEP session start message sent by the PCC to be detected, and determine whether the PCEP session start message carries the first TLV field.

[0114] Optionally, the path detection configuration is a Bidirectional Active Measurement Protocol (TWAMP) configuration.

[0115] Optionally, the PCEP protocol predefines a second TLV field in which the Type field is a second value and the Value field carries a path detection configuration; when the path detection configuration corresponding to the client to be detected is carried in a Path Computation Unit Communication Protocol (PCEP) extended message and delivered to the client to be detected, the delivering unit is specifically configured to:

[0116] The path detection configuration corresponding to the client to be detected is filled into the Value field of the second TLV field, and the second TLV field is carried in a PCEP message and sent to the client to be detected.

[0117] Optionally, the PCEP message is used to instruct the client to be detected to create an SR / SRv6 tunnel; the path detection configuration carried in the second TLV field of the PCEP message is used to instruct the client to be detected to use the source and destination of the created SR / SRv6 tunnel as the source and destination of the control session and test session of the TWAMP detection.

[0118] Optionally, the PCEP protocol predefines a third TLV field whose Type is a third value and whose Value field carries updated path detection parameters. The apparatus further includes:

[0119] The updating unit is configured to, if it is determined that the TWAMP detection parameters of the client to be detected need to be updated, carry the TWAMP detection parameters to be updated in a third TLV field and send the updated TWAMP detection parameters to the client to be detected via a PCUpd message.

[0120] Optionally, the PCEP protocol predefines a fourth TLV field whose Type is a fourth value and whose Value field carries a path detection result. The apparatus further includes:

[0121] A receiving unit, configured to receive a PCRpt message carrying a fourth TLV field, sent by a client to be detected;

[0122] The parsing unit is configured to parse the fourth TLV field carried by the PCRpt message to obtain a path detection result.

[0123] The above units may be one or more integrated circuits configured to implement the above methods, such as one or more application-specific integrated circuits (ASICs), one or more digital signal processors (DSPs), or one or more field programmable gate arrays (FPGAs). For another example, when a unit is implemented by scheduling program code through a processing element, the processing element may be a general-purpose processor, such as a central processing unit (CPU) or other processor that can call program code. For another example, these units may be integrated together and implemented in the form of a system-on-a-chip (SOC).

[0124] Furthermore, the path detection device provided in the embodiment of the present application, from the hardware level, the hardware architecture diagram of the path detection device can be found in Figure 7 As shown, the path detection device may include: a memory 70 and a processor 71,

[0125] The memory 70 is used to store program instructions. The processor 71 calls the program instructions stored in the memory 70 and executes the above method embodiment according to the obtained program instructions. The specific implementation method and technical effect are similar and will not be repeated here.

[0126] Optionally, the present application also provides a path detection device, comprising at least one processing element (or chip) for executing the above method embodiment.

[0127] Optionally, the present application also provides a program product, such as a computer-readable storage medium, which stores computer-executable instructions, and the computer-executable instructions are used to enable the computer to execute the above method embodiments.

[0128] Here, the machine-readable storage medium can be any electronic, magnetic, optical or other physical storage device that can contain or store information, such as executable instructions, data, etc. For example, the machine-readable storage medium can be: RAM (Random Access Memory), volatile memory, non-volatile memory, flash memory, storage drive (such as hard disk drive), solid state drive, any type of storage disk (such as CD, DVD, etc.), or similar storage media, or a combination thereof.

[0129] The systems, devices, modules, or units described in the above embodiments may be implemented by computer chips or entities, or by products having certain functions. A typical implementation device is a computer, which may be in the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email transceiver, game console, tablet computer, wearable device, or any combination of these devices.

[0130] For the convenience of description, the above devices are described as being divided into various units according to their functions. Of course, when implementing this application, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0131] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the embodiments of the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0132] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the steps in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0133] Furthermore, these computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0134] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable device to implement the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0135] The above description is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

Claims

1. A path detection method, characterized in that: The method comprises: Determine whether the client to be detected supports the path detection configuration delivery function; When it is determined that the client to be detected supports the path detection configuration sending function, the path detection configuration corresponding to the client to be detected is carried in the path calculation unit communication protocol PCEP extended message and sent to the client to be detected, so that the client to be detected performs path detection based on the path detection configuration.

2. The method according to claim 1, wherein The method is applied to a path computation element (PCE), the client to be detected is a path computation client (PCC) to be detected, the PCEP protocol predefines a first TLV field whose Type is a first value, the first TLV field represents the PCC to be detected, and the PCE supports the delivery of path detection configuration; The steps of determining whether the client to be detected supports the path detection configuration delivery function include: When negotiating a session with the PCC to be detected, the PCE sends a PCEP session start message to the PCC. Receive a PCEP session start message sent by the PCC to be detected, and determine whether the PCEP session start message carries the first TLV field.

3. The method according to claim 1 or 2, wherein: The path detection configuration is a Bidirectional Active Measurement Protocol TWAMP configuration.

4. The method according to claim 3, wherein The PCEP protocol predefines a second TLV field with a Type value of the second value and a Value field that carries the path detection configuration. The step of carrying the path detection configuration corresponding to the client to be detected in a Path Computation Element Communication Protocol (PCEP) extended message and sending it to the client to be detected includes: The path detection configuration corresponding to the client to be detected is filled into the Value field of the second TLV field, and the second TLV field is carried in a PCEP message and sent to the client to be detected.

5. The method according to claim 4, wherein This PCEP message is used to instruct the client to be detected to create an SR / SRv6 tunnel. The path detection configuration carried in the second TLV field of the PCEP message is used to instruct the client to be detected to use the source and destination of the created SR / SRv6 tunnel as the source and destination of the control session and test session of the TWAMP detection.

6. The method according to claim 4, wherein The PCEP protocol predefines a third TLV field whose Type field is a third value and whose Value field carries updated path detection parameters. The method further includes: If it is determined that the TWAMP detection parameters of the client to be detected need to be updated, the TWAMP detection parameters to be updated are carried in the third TLV field and sent to the client to be detected through a PCUpd message.

7. The method according to claim 1, wherein The PCEP protocol predefines a fourth TLV field whose Type field is a fourth value and whose Value field carries a path detection result. The method further includes: Receive a PCRpt message carrying the fourth TLV field sent by the client to be detected; Parse the fourth TLV field carried in the PCRpt message to obtain a path detection result.

8. A path detection device, characterized in that: The device comprises: A judgment unit, used to judge whether the client to be detected supports the path detection configuration delivery function; The sending unit is used to carry the path detection configuration corresponding to the client to be detected in the path calculation unit communication protocol PCEP extended message and send it to the client to be detected when it is determined that the client to be detected supports the path detection configuration sending function, so that the client to be detected performs path detection based on the path detection configuration.

9. A path detection device, characterized in that: The path detection device comprises: a memory for storing program instructions; The processor is configured to call the program instructions stored in the memory, and execute the steps of the method according to any one of claims 1 to 7 according to the obtained program instructions.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to enable the computer to execute the steps of the method according to any one of claims 1 to 7.

Images