WO2023024706A1 - 链路测试方法、电子设备及存储介质 - Google Patents

链路测试方法、电子设备及存储介质 Download PDF

Info

Publication number
WO2023024706A1
WO2023024706A1 PCT/CN2022/103491 CN2022103491W WO2023024706A1 WO 2023024706 A1 WO2023024706 A1 WO 2023024706A1 CN 2022103491 W CN2022103491 W CN 2022103491W WO 2023024706 A1 WO2023024706 A1 WO 2023024706A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
link
message
server
reflector
Prior art date
Application number
PCT/CN2022/103491
Other languages
English (en)
French (fr)
Inventor
窦战伟
郭俊
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2023024706A1 publication Critical patent/WO2023024706A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/50—Testing arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/50—Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/141—Setup of application sessions

Definitions

  • the present application relates to the technical field of communications, and in particular to a link test method, electronic equipment and storage media.
  • TWAMP Two-Way Active Measurement Protocol
  • TWAMP is an IP performance measurement protocol, which is mainly used for performance measurement such as IP network link delay and packet loss rate.
  • TWAMP usually consists of 4 logical entities, namely Control-Client (client), Server (server), Session-Reflector (reflector), Session-Sender (transmitter); it is divided into three stages in the working process: Control protocol negotiation phase, control session negotiation phase, and testing phase.
  • the Control-Client sends a Request-TW-Session message to the Server to request to create a test session through the pre-created transmitter Session-Sender, and the Server creates a reflector Session-Reflector according to the Request-TW-Session message, which is implemented in During the test phase, the Session-Reflector reflects test packets back to the Session-Sender.
  • the Session-Reflector can only obtain the IP address in the Request-TW-Session message, and the obtained link information is limited, only through the IP address
  • the method of checking the route to determine the link to be tested does not guarantee that the test packet sent by the Session-Sender and the reflected packet sent by the reflector go through the same link, and may not be sent according to the link expected by the user. The link to be tested determined by the reflected packet is inaccurate.
  • the embodiment of the present application provides a link testing method, which is applied to the client, and the method includes: sending a session request to the server and establishing a test session, the session request carrying the path information of the return link; sending a test report send the test message to the server, and receive the reflection message corresponding to the test message sent by the server through the return link.
  • the embodiment of the present application also provides a link testing method, which is applied to the server, and the method includes: receiving a session request sent by the client and establishing a test session, the session request carrying the path information of the return link; receiving generating a reflection message corresponding to the test message from the test message sent by the transmitter of the client; and sending the reflection message to the client through the return link.
  • the embodiment of the present application also provides an electronic device, including: at least one processor; and a memory connected in communication with the at least one processor; wherein, the memory stores information that can be executed by the at least one processor. Instructions, the instructions are executed by the at least one processor, so that the at least one processor can execute the above-mentioned link testing method.
  • An embodiment of the present application further provides a computer-readable storage medium storing a computer program, wherein the above-mentioned link test method is implemented when the computer program is executed by a processor.
  • Fig. 1 is a schematic flow chart of a link testing method according to an embodiment of the present application
  • FIG. 2 is a schematic diagram of the structure of TLV
  • Figure 3 is a schematic structural diagram of the client and server in the SR-MPLS-POLICY scenario
  • Figure 4 is a schematic diagram of the structure of TLV in the SR-MPLS-POLICY scenario
  • Figure 5 is a schematic diagram of another structure of TLV in the SR-MPLS-POLICY scenario
  • Figure 6 is a schematic structural diagram of the client and server in the SRV6-POLICY scenario
  • Figure 7 is a schematic diagram of the structure of TLV in the SRV6-POLICY scenario
  • Figure 8 is a schematic diagram of another structure of TLV in the SRV6-POLICY scenario.
  • FIG. 9 is a schematic structural diagram of a client and a server in this embodiment in an SR-TE scenario
  • Figure 10 is a schematic diagram of the structure of a TLV in an SR-TE scenario
  • FIG. 11 is a schematic structural diagram of a client and a server in a VPN scenario
  • Figure 12 is a schematic structural diagram of TLV in a VPN scenario
  • Figure 13 is a schematic structural diagram of the client and server in a pure IP scenario
  • Figure 14 is a schematic structural diagram of the client and server in the SR BE scenario
  • FIG. 15 is a schematic structural diagram of a TLV in the case of specifying backhaul IP address information
  • FIG. 16 is another schematic structural diagram of a TLV in the case of specifying backhaul IP address information
  • Fig. 17 is a schematic structural diagram of a TLV in the case of specifying return label information
  • FIG. 18 is a schematic flowchart of a link testing method according to another embodiment of the present application.
  • Fig. 19 is a schematic structural diagram of an electronic device according to an embodiment of the present application.
  • the main purpose of the embodiments of the present application is to provide a link testing method, electronic equipment, and a storage medium, so as to improve the accuracy of finding a return link, thereby improving the accuracy of detection.
  • Step 101 send a session request to the server and establish a test session.
  • this step takes place during the control session negotiation phase.
  • the execution subject of this embodiment is the client, where the session request sent by the client carries the path information of the return link, and the server can find the corresponding link based on the path information.
  • the return link to return the corresponding message.
  • Step 102 sending a test message to the server, and receiving a reflection message corresponding to the test message sent by the server through a return link.
  • this process occurs in the testing phase.
  • the client sends a test message to the server.
  • the server After receiving the test message, the server generates a reflection message, and the server finds the corresponding return link according to the path information. Thus, the reflected packet is returned to the client through the return link.
  • the session request in this embodiment carries the path information of the return link, so that when the client sends a test message to the server, the server can accurately find the return link according to the path information, and send the reflected message according to the return link.
  • the link returns, thereby completing the test process, improving the accuracy of finding the return link, thereby improving the accuracy of detection.
  • the session request includes information for creating a reflector, and the information for creating a reflector includes path information of a return link.
  • the server receives a session request, it also obtains information for creating a reflector, and uses the information to create a reflector.
  • sending the test message to the server, and receiving the reflection message corresponding to the test message sent by the server through the return link includes: sending the test message through a locally created transmitter to the server; receive the reflected message corresponding to the test message through the return link corresponding to the path information, and send the reflected message through the reflector in the server.
  • the client includes a locally created transmitter, and the server creates a reflector based on the information used to create the reflector; in the testing phase, the client sends a test message to the server's reflector through the transmitter, and the reflector A reflection message corresponding to the test message is generated, the reflector finds the return link based on the path information of the return link, and sends the reflection message to the transmitter through the return link.
  • the information used to create the reflector is TLV information.
  • the TLV information includes not only the path information of the return link, but also the type of the return link, the length of the TLV information, and the subtype of the return link.
  • the structure of the TLV information is used to indicate that when the server creates the reflector, it obtains the path information of the reflector to send the reflection message, as shown in Figure 2, which is a schematic structural diagram of the TLV, where type represents the type of the return link (for example : sr-te, sr-mpls-policy, srv6-policy, mpls-te, vpn, etc.),
  • Lenght indicates the length of the path information
  • sub-type indicates the subtype of the path information carried
  • value indicates the path information.
  • the path type carries different value values, that is to say, the type of path information is determined according to the type of the return link. In this way, when the reflector returns the reflected message, the accuracy of the return link
  • Type indicates the type of path: Type 1 indicates that the type is sr-mpls-policy; Type 2 indicates that the type is srv6-policy; Type 3 indicates that the type is te-tunne1; Type 4 indicates that the type is The type is VPN; Type is 5, indicating that the type is a return IP address; Type is 6, indicating that the type is a return label.
  • TWAMP-Server parses information such as the IP address, port number, and carried path TLV from the Request-TW-Session, and creates a reflector based on these information, and the reflector
  • the path information in the TLV is stored in the value value (for example: label stack, segment-list, BSID, VPN-ID, VC-ID, tunnel ID, return IP address, return label, etc.), and this information is used for the reflector in the test phase Searching for the return link when sending a reflected message can ensure that the path where the reflector sends the test message and the path that the reflector sends the reflected message is the same link, or ensure that the reflected message is sent according to the path expected by the user.
  • the session-sender sends a test message to the session-reflector, and the session-reflector generates a reflection message after receiving the test message, and at the same time searches for the return link according to the cached path information, that is, the value value, and sends the reflection message Send it to the Sesion-sender through the found return link. After that, the Sesion-sender performs IP performance statistics after receiving the reflected packet.
  • control session negotiation stage before sending a session request to the server and establishing a test session, it also includes: initiating a connection request to the server, receiving a response message returned by the server, and the response message carries the communication mode that the server expects to support ; Send a connection message to the server, the connection message carries the information that the client supports the communication mode, and the server and the client establish a connection based on the communication mode.
  • the communication mode expected to be supported by the server is a two-way co-path mode.
  • TWAMP-Client first initiates a TCP connection request to TWAMP-Server, and then TWAMP-Server responds to TWAMP-Client with a Greeting response message, in the mode field of the Greeting message of the response Setting the "two-way co-path mode" flag set in this embodiment indicates that the TWAMP-Server supports this new communication mode.
  • one bit of the mode field in the response message is used to identify the two-way co-path mode.
  • the mode field of the response message occupies 32 bits, each bit represents a communication mode, and this embodiment uses one of the unallocated bits to identify this communication mode, that is, the two-way co-path mode.
  • the TWAMP-Client of this embodiment After the TWAMP-Client of this embodiment receives the Greeting message, because the TWAMP-Client can support the two-way co-path mode, the TWAMP-Client sends a connection message to the TWAMP-Server, that is, the Set-Up-Response message.
  • the client that is, the TWAMP-Client end
  • the server end that is, the TWAMP-Server end
  • this communication mode-bidirectional co-path mode (Bidirectional co-path mode)
  • the sending link and the return link are the same link.
  • configure the information of the transmitter namely session-sender, on the TWAMP-Client, including source IP address, destination IP address, source UDP port number, destination UDP port number, and DSCP value; in addition, configure the transmitter to send the message according to the test scenario.
  • the TLV information of the return link of the document for example: sr-policy scenarios need to configure sr-policy path information (such as color, end-point, protocol-origin, discrimination, Segment-list ID); SR-TE scenarios need to configure TE- Tunnel information (such as tunnel ID); L2VPN/l3VPN scenarios need to configure VPN information (such as: AC interface information, VPN instance name); finally configure the reflector to return the path information of the reflected packet according to different test scenarios, for example, sr-mpls
  • sr-policy scenario you need to specify the label stack information (LABLE-STACK) or BSID (binding-segment-list-id); in the srv6-policy scenario, you need to specify the segment list (segment-list) or BSID; in the L2VPN/l3VPN scenario, you need to configure the VPN-ID ;
  • the return IP address or return label information needs to be specified.
  • the first scenario In the SR-MPLS-POLICY scenario, the TWAMP transmitter sends the test packet and the reflector returns the reflection packet, and sends a packet test according to a specified candidate path.
  • Figure 3 it is a schematic structural diagram of the client and server in the SR-MPLS-POLICY scenario, where the client PE1 and the server PE2 are configured with SR-POLICY respectively, and there are multiple Candidate Path Candidate Path, this embodiment only selects one of the paths.
  • the specific implementation is as follows:
  • the sesson-sender on the client PE1, and specify the source IP address, destination IP address, source UDP port number, Destination UDP port number, etc., and at the same time specify the information of the candidate path for the session-sender to send the message (including color, end-point, protocol-origin, segment-list ID, etc.); and the path information of the return link sent by the session-reflector , the path information is the corresponding sr-policy Candidate Path information on PE2.
  • TLV information There are two forms of TLV information, one is the Lable-stack label stack information, and the other is the BSID (Binding segment ID) information bound to the Candidate Path .
  • PE1 initiates the establishment of a TWAMP-Control connection.
  • the flag bit of "two-way common path mode" is set.
  • PE1 After the TWAMP-Control connection is established, PE1 initiates a session request on the established control connection, and carries specific path information of the return link in the session request message (Request-TW-Session) according to the configuration, that is, Information about a candidate path from PE2 to PE1. If the return path information is a label stack, the label stack TLV is encapsulated.
  • FIG. 4 it is a schematic diagram of the structure of TLV in the SR-MPLS-POLICY scenario.
  • Type is set to 1, which means the SR-MPLS-POLICY scenario, lenght is the label stack depth n times 4 plus 1 byte, sub -type is 1, which means the label stack; Value is the specific label stack information; if it is BSID, encapsulate the BSID TLV.
  • FIG. 5 it is another structural diagram of TLV in the SR-MPLS-POLICY scenario.
  • Type is set to 1, indicating the SR-MPLS-POLICY scenario, lenght is 5 bytes, and sub-type is 2, indicating BSID , Value is the specific BSID value.
  • the TWAMP-Server of PE2 analyzes the IP address, port number and path TLV information in the request message. And create a sess-reflector reflector based on these information, wherein the return path cached and parsed in the reflector is one of the label stack lable-stack and BSID, and the specific information type is determined according to the specific tlv-type.
  • the Session-Sender searches for the specific packet sending path according to the configured Candidate Path information, and sends the test message on the path.
  • Session-Reflector After the Session-Reflector receives the test message, it generates a reflection message, and at the same time, according to the cached return path information (signature stack lable-stack or BSID), finds the return path, and places the reflection message on the found return path Send to session-sender.
  • the cached return path information signature stack lable-stack or BSID
  • the second scenario In the SRV6-POLICY scenario, the test packet sent by the TWAMP transmitter and the reflection packet returned by the reflector are sent according to the specified Candidate Path (candidate path) for testing.
  • Candidate Path candidate path
  • Figure 6 it is a schematic structural diagram of the client and server in the SRV6-POLICY scenario, where PE1 and PE2 are configured with SRV6-POLICY respectively, and there are multiple Candidate Paths from PE1 to PE2 and from PE2 to PE1, and one of them is selected. Path is used as the return link.
  • the specific implementation is as follows:
  • PE1 initiates the establishment of a TWAMP-Control connection.
  • the flag bit of "two-way common path mode" is set.
  • PE1 initiates a session request on the established control connection, and carries the specific reflector return packet path TLV information in the session request message (Request-TW-Session) according to the configuration , that is, information about a candidate path from PE2 to PE1. If the return path information is Segment-List, encapsulate the Segment-List TLV.
  • FIG 7 it is a schematic diagram of a TLV structure in the SRV6-POLICY scenario.
  • Type is set to 2; lenght is the label stack depth n times 16 plus 1 byte; sub-type is 1, indicating the label stack; Value is Specific segment information; if it is BSID, encapsulate BSID TLV, as shown in Figure 8, which is another structural diagram of TLV in the SRV6-POLICY scenario, Type is set to 2; lenght is 5 bytes; sub-type is 2, Value is a BSID value.
  • the TWAMP-Server of PE2 analyzes the IP address, port number and path TLV information in the request message. And create a sess-reflector reflector based on these information, wherein the return path TLV information parsed is cached in the reflector (that is, one of the label stack Segment-List and BSID, and the specific information type is determined according to the specific tlv-type).
  • the Session-Sender searches for the specific packet sending path according to the configured Candidate Path information, and sends the test message on the path.
  • Session-Reflector After the Session-Reflector receives the test message, it generates a reflection message, and at the same time searches for the return path according to the cached return path information (signature stack Segment-List or BSID), and puts the reflection message on the found return path Send to session-sender.
  • the cached return path information signature stack Segment-List or BSID
  • the third scenario In the SR-TE or MPLS-TE scenario, the test packet sent by the TWAMP transmitter and the reflector reflection section test packet are sent according to the specified SR-TE for testing.
  • Figure 9 it is a schematic structural diagram of the client and server in this embodiment under the SR-TE scenario or the MPLS-TE scenario, and the specific implementation methods are as follows:
  • PE1 initiates the establishment of a TWAMP-Control connection.
  • the flag bit of "two-way common path mode" is set.
  • PE1 After the TWAMP-Control connection is established, PE1 initiates a session request on the established control connection, and carries the reflector return path TLV information specified in the configuration in the session request message (Request-TW-Session), that is, PE2 Information about a tunnel to PE1, including the tunnel ID.
  • Request-TW-Session the reflector return path TLV information specified in the configuration in the session request message
  • FIG. 10 it is a schematic diagram of the structure of the TLV in the SR-TE or MPLS-TE scenario.
  • Type is set to 3; lenght is 5 bytes; sub-type is 0; Value is a specific tunnel ID value.
  • the TWAMP-Server of PE2 After receiving the request message, the TWAMP-Server of PE2 analyzes the IP address, port number and path TLV information in the request message. And create a sess-reflector reflector based on these information, wherein the reflector caches the resolved return path TLV information, that is, the return tunnel ID.
  • the Session-Sender searches for the specific packet sending path according to the configured tunnel ID information, and sends the test message on the path.
  • Session-Reflector After the Session-Reflector receives the test message, it generates a reflection message, and at the same time, according to the cached tunnel ID information, finds the return path, and sends the reflection message to the session-sender on the found return path.
  • the fourth scenario includes L2VPN, L3VPN, test packets sent by the TWAMP transmitter and reflector reflection segment test packets, and the specified l2VPN sends packets for testing.
  • Figure 11 it is a schematic diagram of the structure of the client and server in the VPN scenario, and the specific implementation is as follows:
  • the path information is the corresponding VPN instance number (VPN-ID) or identifier on PE2, such as VC-ID, return label, etc.
  • PE1 initiates the establishment of a TWAMP-Control connection.
  • the flag bit of "two-way common path mode" is set.
  • PE1 initiates a session request on the established control connection, and carries the TLV information of the reflector return path specified in the configuration in the session request message (Request-TW-Session), That is, the VPN-ID TLV corresponding to PE2 and PE1, and the information includes the return VPN-ID.
  • FIG. 12 it is a schematic diagram of the TLV structure in the VPN scenario.
  • Type is set to 4; lenght is 5 bytes; sub-type is 1 for L2VPN, sub-type is 2 for L3VPN; Value is the specific VPN-ID value. It should be noted that, in the VPN scenario, Value may also be an identifier of the return link, such as VC-ID, return label, and the like.
  • the TWAMP-Server of PE2 After receiving the request message, the TWAMP-Server of PE2 analyzes the IP address, port number and path TLV information in the request message. And create a sess-reflector reflector according to the information, wherein the reflector caches the resolved return path TLV information, that is, the return VPN-ID.
  • the Session-Sender searches for the specific packet sending path according to the configured VPN information, and sends the test packet on the path.
  • Session-Reflector After the Session-Reflector receives the test message, it generates a reflection message, and at the same time searches for the return path according to the VPN-ID of the buffered return path, and sends the reflection message to the session-sender on the found return path.
  • the fifth scenario In the traditional pure IP scenario or SR BE scenario, the TWAMP reflector sends the test message according to the specified IP or label (lable), as shown in Figure 13, which is the connection between the client and the server in the pure IP scenario
  • the schematic diagram of the structure as shown in Figure 14, is a schematic diagram of the structure of the client and server in the SR BE scenario.
  • the specific implementation is as follows:
  • PE1 initiates the establishment of a TWAMP-Control connection.
  • the flag bit of "two-way common path mode" is set.
  • PE1 initiates a session request on the established control connection, and carries the TLV information of the reflector return path specified in the configuration in the session request message (Request-TW-Session), That is, the backhaul IP address TLV, the information includes the backhaul IP address information, and the IP address is the destination IP address of the reflection packet sent by the reflector.
  • Request-TW-Session the TLV information of the reflector return path specified in the configuration in the session request message
  • Type is set to 5; lenght is 5 bytes; sub-type is 1 to indicate an IPV4 address; Value is a specific return IPv4 address value;
  • Type is set to 5; lenght is 17 bytes; sub-type is 2 to indicate the IPV6 address; Value is the specific return IPv6 address value .
  • FIG. 17 it is a structural diagram of a TLV in the case of specifying return label information, Type is set to 6; lenght is 5 bytes; sub-type is 0; Value is the specific return label value Label.
  • the TWAMP-Server of PE2 After receiving the request message, the TWAMP-Server of PE2 analyzes the IP address, port number and path TLV information in the request message. And create a session-reflector reflector based on these information, where the resolved return path TLV information is cached in the reflector, that is, return IP address information or return label information.
  • the Session-Sender searches for the specific packet sending path according to the configured destination IP information, and sends the test packet on the path.
  • Session-Reflector After the Session-Reflector receives the test message, it generates a reflection message, and at the same time searches for the return path according to the cached return path IP address or return label information, and sends the reflection message to the session-reflector on the found return path. sender.
  • FIG. 18 Another embodiment of the present application relates to a link testing method, which is applied to the server.
  • the specific flowchart is shown in FIG. 18 , including the following steps:
  • Step 201 receiving a session request sent by a client and establishing a test session.
  • the session request carries path information of the return link.
  • Step 202 receiving a test message sent by the client, and generating a reflection message corresponding to the test message.
  • Step 203 sending the reflection message to the client through the return link.
  • the session request includes information for creating a reflector
  • the information for creating a reflector includes path information of a return link.
  • the method further includes: creating a reflector according to the information used to create the reflector.
  • receiving the test message sent by the client and generating a reflection message corresponding to the test message includes: using the reflector to receive the test message sent by the transmitter of the client, and using the reflector to generate a reflection message corresponding to the test message
  • the reflective message corresponding to the document; sending the reflective message to the client through the return link includes: using the reflector to send the reflective message to the client through the return link corresponding to the path information.
  • the method further includes: storing path information in the reflector.
  • this embodiment is an embodiment corresponding to the previous embodiment, and the same or corresponding content of the previous embodiment and this embodiment is still valid in this embodiment. In order to avoid repetition, it will not be repeated here.
  • the relevant technical details of this embodiment can also be applied to the previous embodiment. .
  • step division of the above various methods is only for the sake of clarity of description. During implementation, it can be combined into one step or some steps can be split and decomposed into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this patent. ; Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but not changing the core design of the algorithm and process are all within the scope of protection of this patent.
  • An embodiment of the present application relates to an electronic device, as shown in FIG. 19 , including at least one processor 301; and a memory 302 communicatively connected to at least one processor 301; Instructions executed by 301, the instructions are executed by at least one processor 301, so that at least one processor 301 can execute the communication control method as described above.
  • the memory 302 and the processor 301 are connected by a bus, and the bus may include any number of interconnected buses and bridges, and the bus connects one or more processors 301 and various circuits of the memory 302 together.
  • the bus may also connect together various other circuits such as peripherals, voltage regulators, and power management circuits, all of which are well known in the art and therefore will not be further described herein.
  • the bus interface provides an interface between the bus and the transceivers.
  • a transceiver may be a single element or multiple elements, such as multiple receivers and transmitters, providing means for communicating with various other devices over a transmission medium.
  • the data processed by the processor 301 is transmitted on the wireless medium through the antenna, and further, the antenna also receives the data and transmits the data to the processor 301 .
  • the processor 301 is responsible for managing the bus and general processing, and may also provide various functions including timing, peripheral interface, voltage regulation, power management and other control functions. And the memory 302 may be used to store data used by the processor 301 when performing operations.
  • An embodiment of the present application relates to a computer-readable storage medium storing a computer program.
  • the above method embodiments are implemented when the computer program is executed by the processor.
  • the program is stored in a storage medium, and includes several instructions to make a device ( It may be a single-chip microcomputer, a chip, etc.) or a processor (processor) to execute all or part of the steps of the methods in the various embodiments of the present application.
  • the aforementioned storage media include: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), magnetic disk or optical disc, etc., which can store program codes. .

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请涉及通信领域，特别涉及一种链路测试方法、电子设备、存储介质。本申请的链路测试方法包括：向服务端发送会话请求并建立测试会话，所述会话请求携带有返程链路的路径信息；发送测试报文至所述服务端，并通过所述返程链路接收所述服务端发送的与所述测试报文对应的反射报文。

Description

链路测试方法、电子设备及存储介质
交叉引用
本申请基于申请号为“202110996602.7”、申请日为2021年8月27日的中国专利申请提出，并要求该中国专利申请的优先权，该中国专利申请的全部内容在此以引入方式并入本申请。
技术领域
本申请涉及通信技术领域，特别涉及一种链路测试方法、电子设备及存储介质。
背景技术
双向主动测量协议(TWAMP，Two-Way Active Measurement Protocol)是一种IP性能度量的协议，主要用于IP网络链路时延和丢包率等性能度量。TWAMP通常有4个逻辑实体组成，即Control-Client(客户端)、Server(服务端)、Session-Reflector(反射器)、Session-Sender(发射器)；在工作过程中分为三个阶段：控制协议协商阶段、控制会话协商阶段、测试阶段。
在控制会话协商阶段，Control-Client通过预先创建的发射器Session-Sender发送Request-TW-Session消息向Server请求创建测试会话，Server根据Request-TW-Session消息来创建反射器Session-Reflector，实现在测试阶段Session-Reflector向Session-Sender反射回测试报文。
然而，Request-TW-Session消息中，只有源UDP端口号、目的UDP端口号、源IP地址、目的IP地址等信息，而用于标识待测链路的信息只有源IP地址和目的IP地址。由于Session-Reflector是根据Request-TW-Session消息来创建的，因此Session-Reflector只能获取到Request-TW-Session消息中的IP地址，获取的待测链路的信息比较有限，仅通过IP地址查路由确定出的待测链路的方式，并不能保证Session-Sender发送的测试报文和反射器发送的反射报文走 的是同一条链路，也不一定能够按用户期望的链路发送反射报文，确定出的待测链路并不准确。
发明内容
本申请实施例提供了一种链路测试方法，应用于客户端，所述方法包括：向服务端发送会话请求并建立测试会话，所述会话请求携带有返程链路的路径信息；发送测试报文至所述服务端，并通过所述返程链路接收所述服务端发送的与所述测试报文对应的反射报文。
本申请实施例还提供了一种链路测试方法，应用于服务端，所述方法包括：接收客户端发送的会话请求并建立测试会话，所述会话请求携带有返程链路的路径信息；接收所述客户端的发射器发送的测试报文，生成与所述测试报文对应的反射报文；并通过所述返程链路向所述客户端发送所述反射报文。
本申请实施例还提供了一种电子设备，包括：至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述的链路测试方法。
本申请实施例还提供了一种计算机可读存储介质，存储有计算机程序，其中，所述计算机程序被处理器执行时实现上述的链路测试方法。
附图说明
一个或多个实施例通过与之对应的附图中的图片进行示例性说明，这些示例性说明并不构成对实施例的限定，附图中具有相同参考数字标号的元件表示为类似的元件，除非有特别申明，附图中的图不构成比例限制。
图1是根据本申请一实施例的链路测试方法的流程示意图；
图2是TLV的结构示意图；
图3是SR-MPLS-POLICY场景下客户端与服务端的结构示意图；
图4是SR-MPLS-POLICY场景下TLV的一种结构示意图
图5是SR-MPLS-POLICY场景下TLV的另一种结构示意图；
图6是SRV6-POLICY场景下客户端与服务端的结构示意图；
图7是SRV6-POLICY场景下TLV的一种结构示意图；
图8是SRV6-POLICY场景下TLV的另一种结构示意图；
图9是SR-TE场景下本实施例的客户端与服务端的结构示意图；
图10是SR-TE场景下TLV的结构示意图；
图11是VPN场景下客户端与服务端的结构示意图；
图12是VPN场景下TLV的结构示意图；
图13是纯IP场景下客户端与服务端的结构示意图；
图14是SR BE场景下客户端与服务端的结构示意图；
图15是指定回程IP地址信息情况下的TLV的一种结构示意图；
图16是指定回程IP地址信息情况下的TLV的另一种结构示意图；
图17是指定返程标签信息情况下的TLV的一种结构示意图；
图18是根据本申请另一实施例的链路测试方法的流程示意图；
图19是根据本申请一实施例的电子设备的结构示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合附图对本申请的各实施例进行详细的阐述。然而，本领域的普通技术人员可以理解，在本申请各实施例中，为了使读者更好地理解本申请而提出了许多技术细节。但是，即使没有这些技术细节和基于以下各实施例的种种变化和修改，也可以实现本申请所要求保护的技术方案。以下各个实施例的划分是为了描述方便，不应对本申请的具体实现方式构成任何限定，各个实施例在不矛盾的前提下可以相互结合相互引用。
本申请实施例的主要目的在于提出一种链路测试方法、电子设备及存储介质，提高查找返程链路的准确度，从而提高检测的准确性。
本申请一实施例涉及一种链路测试方法，具体流程示意图如图1所示，包括以下步骤：
步骤101，向服务端发送会话请求并建立测试会话。
具体地说，此步骤发生在控制会话协商阶段，本实施例的执行主体为客户 端，其中，客户端发送的会话请求中携带有返程链路的路径信息，服务端可以根据路径信息查找到对应的返程链路从而返回相应的报文。
步骤102，发送测试报文至服务端，并通过返程链路接收服务端发送的与测试报文对应的反射报文。
具体地说，此过程发生在测试阶段，客户端向服务端发送测试报文，服务端接收到测试报文之后会生成反射报文，且服务端会根据路径信息查找到对应的返程链路，从而将反射报文通过返程链路返回至客户端。
本实施例的会话请求中携带有返程链路的路径信息，从而在客户端向服务端发送测试报文时，服务端可以根据路径信息精确地查找到返程链路，将反射报文按照该返程链路返回，从而完成测试过程，提高查找返程链路的准确度，从而提高检测的准确性。
在一个实施例中，会话请求包括用于创建反射器的信息，用于创建反射器的信息中包含返程链路的路径信息。具体地说，服务器接收到会话请求时，也会获取用于创建反射器的信息，并使用该信息创建反射器。
在一个实施例中，发送测试报文至服务端，并通过返程链路接收所述服务端发送的与所述测试报文对应的反射报文，包括：通过本地创建的发射器发送测试报文至服务端；通过路径信息对应的返程链路接收与测试报文对应的反射报文，反射报文通过服务端中的反射器发送。具体地说，客户端包括有本地创建的发射器，服务端根据用于创建反射器的信息创建了反射器；在测试阶段，客户端通过发射器发送测试报文至服务端的反射器，反射器生成与测试报文对应的反射报文，反射器基于返程链路的路径信息查找到返程链路，并将该反射报文通过该返程链路发送至发射器。
在一个实施例中，用于创建反射器的信息为TLV信息。具体地说，TLV信息不仅包括返程链路的路径信息，还包括返程链路的类型、TLV信息的长度、返程链路的子类型。TLV信息的结构用于表示在服务端(server)创建反射器时获取反射器发送反射报文的路径信息，如图2所示，为TLV的结构示意图，其中type表示返程链路的类型(例如：sr-te、sr-mpls-policy、srv6-policy、mpls-te、vpn等)，Lenght表示该路径信息的长度，sub-type表示所带路径信息的子类型，value表示路径信息，根据不同的路径类型，携带不同的value值，也就是说， 路径信息的类型根据返程链路的类型确定，通过此种方式可以在反射器返回反射报文时，进一步提高查找的返程链路的准确性。
具体地说，Type表示路径的类型：Type为1，表示类型为sr-mpls-policy；Type为2，表示类型为srv6-policy；Type为3，表示类型为te-tunne1；Type为4，表示类型为VPN；Type为5，表示类型为返程IP地址；Type为6，表示类型为返程标签。
需要说明的是，当没有子类型sub-type时，sub-type的值为0。
具体地说，TWAMP-Server收到Request-TW-Session会话请求消息后，从Request-TW-Session中解析IP地址、端口号及携带的路径TLV等信息，并根据这些信息创建反射器，反射器中存储TLV中的路径信息即value值(例如：标签栈、segment-list、BSID、VPN-ID、VC-ID、隧道ID、返程IP地址、返程标签等)，这些信息用于测试阶段反射器发送反射报文时查找返程链路，能够确保反射器发送测试报文和反射器发送反射报文的路径是同一个链路，或确保反射报文按用户期望的路径发送。
具体地说，Sesion-sender发送测试报文到session-reflector，session-reflector收到测试报文后，生成反射报文，同时根据缓存的路径信息即value值查找返程链路，并将反射报文通过找到的返程链路发送给Sesion-sender，之后，Sesion-sender收到反射报文后进行IP性能统计。
具体地说，在控制会话协商阶段之前，还存在控制协议协商阶段，此阶段主要是为了实现客户端与服务端之间的连接以及确定通信模式。因此，在一个实施例中，在向服务端发送会话请求并建立测试会话之前，还包括：向服务端发起连接请求，接收服务端返回的应答消息，应答消息携带有服务端期望支持的通信模式；向服务端发送连接消息，连接消息携带有客户端支持通信模式的信息，服务端与客户端基于通信模式并建立连接。具体地说，服务端期望支持的通信模式为双向共路径模式。
具体地说，在TWAMP-Control协议协商阶段，首先由TWAMP-Client向TWAMP-Server发起TCP连接请求，之后由TWAMP-Server向TWAMP-Client回应一个Greeting应答消息，在应答的Greeting消息的模式字段中将本实施例所提出的“双向共路径模式”标记位置位，表示TWAMP-Server支持这种新的 通信模式。
在一个实施例中，应答消息中模式字段的一个比特位用于标识双向共路径模式。具体地说，应答消息的模式字段占用32比特，每比特表示一种通信模式，本实施例使用其中的某一未分配比特位来标识这一通信模式即双向共路径模式。
本实施例的TWAMP-Client收到Greeting消息后，由于TWAMP-Client可以支持双向共路径模式，TWAMP-Client向TWAMP-Server发送一个连接消息即Set-Up-Response消息，在该Set-Up-Response消息的模式字段中，将“双向共路径模式”标记位置位，表示TWAMP-Client支持这种新的通信模式；当TWAMP-Server端收到Set-Up-Response消息后，确认通信模式后，回应Server-Start消息来确立TWAMP控制连接；当TWAMP-Client端收到TWAMP-Server消息后，确立TWAMP控制连接，在测试阶段使用“双向共路径模式”进行测试。
具体地说，为了实现本申请的双向共路径模式，在发起控制协议协商之前，现在客户端即TWAMP-Client端和服务端即TWAMP-Server端使能这一通信模式-双向共路径模式(Bidirectional co-path mode)，在双向共路径模式下，发送链路与返程链路为同一链路。同时在TWAMP-Client端配置发射器即session-sender的信息，其中包括源IP地址、目的IP地址，源UDP端口号、目的UDP端口号、DSCP值；另外，还根据测试场景配置发射器发送报文的返程链路的TLV信息，例如：sr-policy场景需要配置sr-policy路径信息(例如color、end-point、protocol-origin、discrimination、Segment-list ID)；SR-TE场景需要配置TE-Tunnel信息(例如隧道ID)；L2VPN/l3VPN场景需要配置VPN信息(例如：AC接口信息、VPN实例名)；最后根据不同的测试场景配置反射器返回反射报文的路径信息，例如，sr-mpls-policy场景需要指定标签栈信息(LABLE-STACK)或BSID(binding-segment-list-id)；srv6-policy场景需要指定段列表(segment-list)或BSID；L2VPN/l3VPN场景需要配置VPN-ID；SR-BE场景需要指定返程IP地址或返程标签信息等。
为了更加详细地说明本申请的技术细节，以下根据不同的场景进行介绍，共分为了五种场景，然实际应用中还可以为其他场景，此处仅是举例说明。
第一种场景：SR-MPLS-POLICY场景下，TWAMP发射器发送的测试报文和反射器返回反射报文，按指定的一个候选路径发包测试的场景。如图3所示，为SR-MPLS-POLICY场景下客户端与服务端的结构示意图，其中，客户端PE1与服务端PE2分别配置SR-POLICY，客户端PE1与服务端PE2之间分别有多条候选路径Candidate Path，本实施例仅是选取其中一条路径。具体实施方式如下：
1.首先在客户端PE1与服务端PE2上使能本实施例所提出的“双向共路径模式”，客户端PE1配置sesson-sender，并指定源IP地址、目的IP地址、源端UDP口号、目的UDP端口号等，同时指定session-sender发送报文的候选路径的信息(包括color、end-point、protocol-origin、segment-list ID等)；和session-reflector发包的返程链路的路径信息，路径信息为PE2上对应sr-policy Candidate Path信息，在TLV信息种有两种表现形式，一种为Lable-stack标签栈信息，另一种为Candidate Path绑定的BSID(Binding segment ID)信息。
2.PE1发起建立TWAMP-Control连接，在TWAMP-Control连接协商过程中，在Greeting消息和reques-response消息的模式字段中，将“双向共路径模式”标志位置位。
3.当TWAMP-Control连接建立完成后，PE1在建立的控制连接上，发起会话请求，并根据配置在会话请求报文(Request-TW-Session)中携带具体的返程链路的路径信息，即PE2到PE1某条候选路径信息。如果返程路径信息为标签栈，则封装标签栈TLV。
如图4所示，为SR-MPLS-POLICY场景下TLV的一种结构示意图，Type设置为1，表示为SR-MPLS-POLICY场景，lenght为标签栈深度n乘以4加1字节，sub-type为1，表示标签栈；Value为具体标签栈信息；如果为BSID，则封装BSID TLV。
如图5所示，为SR-MPLS-POLICY场景下TLV的另一种结构示意图，Type设置为1，表示为SR-MPLS-POLICY场景，lenght为5字节，sub-type为2，表示BSID，Value为具体的BSID值。
4.PE2的TWAMP-Server收到请求报文后，解析请求报文中的IP地址、端口号和路径TLV信息。并根据这些信息创建sess-reflector反射器，其中反射 器中缓存解析的回程路径即标签栈lable-stack、BSID中的一种，根据具体的tlv-type来决定具体的信息类型。
5.当测试会话创建完成后，由Session-Sender根据配置的Candidate Path信息查找具体的发包路径，并在该路径上发送测试报文。
6.Session-Reflector收到测试报文后，生成反射报文，同时根据缓存的返程路径信息(签栈lable-stack或BSID)，查找返程路径，并将反射报文在查找到的返程路径上发送给session-sender。
7.Session-sender收到反射报文后完成链路的性能度量。
第二种场景：SRV6-POLICY场景下，TWAMP发射器发送的测试报文和反射器返回反射报文，按指定的Candidate Path(候选路径)发包测试的场景。如图6所示，为SRV6-POLICY场景下客户端与服务端的结构示意图，其中，PE1、PE2分别配置SRV6-POLICY，PE1到PE2和PE2到PE1分别有多条Candidate Path，从中选择其中一条Candidate Path作为返程链路。具体实施方式如下：
1.首先在PE1和PE2上使能TWAMP本申请所提出的“双向共路径模式”，PE1配置sesson-sender，并指定源IP地址、目的IP地址、源端UDP口号、目的UDP端口号等，同时指定session-sender发送报文的Candidate Path信息(包括color、end-point、protocol-origin、segment-list ID等)；和session-reflector发包的回程路径信息，路径信息为PE2上对应sr-policy Candidate Path信息，有两种表现形式，一种为Segment-List信息，另一种为Candidate Path绑定的BSID(Binding segment ID)信息。
2.PE1发起建立TWAMP-Control连接，在TWAMP-Control连接协商过程中，在Greeting消息和reques-response消息的模式字段中，将“双向共路径模式”标志位置位。
3.当TWAMP-Control连接建立完成后，PE1在建立的控制连接上，发起会话请求，并根据配置在会话请求报文(Request-TW-Session)中携带具体的反射器器回包路径TLV信息，即PE2到PE1某条候选路径信息。如果返程路径信息为Segment-List，则封装Segment-List TLV。
如图7所示，为SRV6-POLICY场景下TLV的一种结构示意图，Type设置为2；lenght为标签栈深度n乘以16加1字节；sub-type为1，表示标签栈；Value为具体segment信息；如果为BSID，则封装BSID TLV，如图8所示，为SRV6-POLICY场景下TLV的另一种结构示意图，Type设置为2；lenght为5字节；sub-type为2，Value为具BSID值。
4.PE2的TWAMP-Server收到请求报文后，解析请求报文中的IP地址、端口号和路径TLV信息。并根据这些信息创建sess-reflector反射器，其中反射器中缓存解析的回程路径TLV信息(即标签栈Segment-List、BSID中的一种，根据具体的tlv-type来决定具体的信息类型)。
5.当测试会话创建完成后，由Session-Sender根据配置的Candidate Path信息查找具体的发包路径，并在该路径上发送测试报文。
6.Session-Reflector收到测试报文后，生成反射报文，同时根据缓存的返程路径信息(签栈Segment-List或BSID)，查找返程路径，并将反射报文在查找到的返程路径上发送给session-sender。
7.Session-sender收到反射报文后完成链路的性能度量。
第三种场景：SR-TE或MPLS-TE场景下，TWAMP发射器发送的测试报文和反射器反射段测试报文，按指定的SR-TE发包测试的场景。如图9所示，为SR-TE场景下或MPLS-TE场景下，本实施例的客户端与服务端的结构示意图，具体实施方式如下：
1.首先在PE1和PE2上使能TWAMP本申请所提出的“双向共路径模式”，PE1配置sesson-sender，并指定源IP地址、目的IP地址、源端UDP口号、目的UDP端口号等，同时指定session-sender发送报文的SR-TE隧道的ID或MPLS-TE隧道的ID；和session-reflector发包的回程路径信息，路径信息为PE2上对应SR-TE隧道ID或MPLS-TE隧道ID。
2.PE1发起建立TWAMP-Control连接，在TWAMP-Control连接协商过程中，在Greeting消息和reques-response消息的模式字段中，将“双向共路径模式”标志位置位。
3.当TWAMP-Control连接建立完成后，PE1在建立的控制连接上，发起 会话请求，并在会话请求报文(Request-TW-Session)中携带配置指定的反射器返回路径TLV信息，即PE2到PE1的某条隧道信息，信息中包含隧道ID。
如图10所示，为SR-TE或MPLS-TE场景下TLV的结构示意图，Type设置为3；lenght为5字节；sub-type为0；Value为具体隧道ID值。
4.PE2的TWAMP-Server收到请求报文后，解析请求报文中的IP地址、端口号和路径TLV信息。并根据这些信息创建sess-reflector反射器，其中反射器中缓存解析的回程路径TLV信息，即返程隧道ID。
5.当测试会话创建完成后，由Session-Sender根据配置的隧道ID信息查找具体的发包路径，并在该路径上发送测试报文。
6.Session-Reflector收到测试报文后，生成反射报文，同时根据缓存的隧道ID信息，查找返程路径，并将反射报文在查找到的返程路径上发送给session-sender。
7.Session-sender收到反射报文后完成链路的性能度量。
第四种场景：VPN场景下包括L2VPN、L3VPN，TWAMP发射器发送的测试报文和反射器反射段测试报文，按指定的l2VPN发包测试的场景。如图11所示，为VPN场景下客户端与服务端的结构示意图，具体实施方式如下：
1.首先在PE1和PE2上使能TWAMP本申请所提出的“双向共路径模式”，PE1配置sesson-sender，并指定源IP地址、目的IP地址、源端UDP口号、目的UDP端口号等，同时指定session-sender发送报文的VPN实例信息；和session-reflector发包的回程路径信息，路径信息为PE2上对应VPN实例号(VPN-ID)或标识符，例如VC-ID、返程标签等。
2.PE1发起建立TWAMP-Control连接，在TWAMP-Control连接协商过程中，在Greeting消息和reques-response消息的模式字段中，将“双向共路径模式”标志位置位。
3.当TWAMP-Control连接建立完成后，PE1在建立的控制连接上，发起会话请求，并在会话请求报文(Request-TW-Session)中携带配置指定的反射器器回包路径TLV信息，即PE2与PE1对应的VPN-ID TLV,信息中包含返程VPN-ID。
如图12所示，为VPN场景下TLV的结构示意图，Type设置为4；lenght为5字节；sub-type为1表示L2VPN，sub-type为2表示L3VPN；Value为具体VPN-ID值。需要说明的是，VPN场景下，Value也可以为返程链路的标识符，例如VC-ID、返程标签等。
4.PE2的TWAMP-Server收到请求报文后，解析请求报文中的IP地址、端口号和路径TLV信息。并根据这些信息创建sess-reflector反射器，其中反射器中缓存解析的回程路径TLV信息，即，返程VPN-ID。
5.当测试会话创建完成后，由Session-Sender根据配置的VPN信息查找具体的发包路径，并在该路径上发送测试报文。
6.Session-Reflector收到测试报文后，生成反射报文，同时根据缓存返程路径的VPN-ID，查找返程路径，并将反射报文在查找到的返程路径上发送给session-sender。
7.Session-sender收到反射报文后完成链路的性能度量。
第五种场景：传统纯IP场景或SR BE场景下，TWAMP反射器按指定的IP或标签(lable)发送测试报文的场景，如图13所示，为纯IP场景下客户端与服务端的结构示意图，如图14所示，为SR BE场景下客户端与服务端的结构示意图，具体实施方式如下：
1.首先在PE1和PE2上使能TWAMP本申请所提出的“双向共路径模式”，PE1配置sesson-sender，并指定源IP地址、目的IP地址、源端UDP口号、目的UDP端口号等，同时指定session-reflector发包的回程IP地址信息或者返程标签信息。
2.PE1发起建立TWAMP-Control连接，在TWAMP-Control连接协商过程中，在Greeting消息和reques-response消息的模式字段中，将“双向共路径模式”标志位置位。
3.当TWAMP-Control连接建立完成后，PE1在建立的控制连接上，发起会话请求，并在会话请求报文(Request-TW-Session)中携带配置指定的反射器器回包路径TLV信息，即回程IP地址TLV，信息中包含回程IP地址信息，IP地址为反射器发送反射报文的目的IP地址。
如图15所示，为指定回程IP地址信息情况下的TLV的一种结构示意图，Type设置为5；lenght为5字节；sub-type为1表示IPV4地址；Value为具体返程IPv4地址值；如图16所示，为指定回程IP地址信息情况下的TLV的另一种结构示意图，Type设置为5；lenght为17字节；sub-type为2表示IPV6地址；Value为具体返程IPv6地址值。
如图17所示，为指定返程标签信息情况下的TLV的一种结构示意图，Type设置为6；lenght为5字节；sub-type为0；Value为具体返程标签值Label。
4.PE2的TWAMP-Server收到请求报文后，解析请求报文中的IP地址、端口号和路径TLV信息。并根据这些信息创建session-reflector反射器，其中反射器中缓存解析的回程路径TLV信息，即回程IP地址信息或返程标签信息。
5.当测试会话创建完成后，由Session-Sender根据配置的目的IP信息查找具体的发包路径，并在该路径上发送测试报文。
6.Session-Reflector收到测试报文后，生成反射报文，同时根据缓存的返程路径IP地址或返程标签信息，查找返程路径，并将反射报文在查找到的返程路径上发送给session-sender。
7.Session-sender收到反射报文后完成链路的性能度量。
本申请的另一实施例涉及一种链路测试方法，应用于服务端，具体流程示意图如图18所示，包括以下步骤：
步骤201，接收客户端发送的会话请求并建立测试会话。其中，会话请求携带有返程链路的路径信息。
步骤202，接收客户端发送的测试报文，生成与测试报文对应的反射报文。
步骤203，通过返程链路向客户端发送反射报文。
在一个实施例中，会话请求包括用于创建反射器的信息，用于创建反射器的信息中包含返程链路的路径信息。
在一个实施例中，接收客户端发送的会话请求并建立测试会话之后，还包括：根据用于创建反射器的信息创建反射器。
在一个实施例中，接收客户端发送的测试报文，生成与测试报文对应的反射报文，包括：利用反射器接收客户端的发射器发送的测试报文，并利用反射 器生成与测试报文对应的反射报文；通过返程链路向客户端发送反射报文，包括：利用反射器通过路径信息对应的返程链路向客户端发送反射报文。
在一个实施例中，根据用于创建反射器的信息创建反射器之后，还包括：将路径信息存储在反射器中。
不难发现，本实施例是与上一实施例相对应是实施例，上一实施例与本实施例相同或相应的内容在本实施例中仍然有效，为避免重复，在此不再赘述，本实施例的相关技术细节也可以应用到上一实施例中。。
上面各种方法的步骤划分，只是为了描述清楚，实现时可以合并为一个步骤或者对某些步骤进行拆分，分解为多个步骤，只要包括相同的逻辑关系，都在本专利的保护范围内；对算法中或者流程中添加无关紧要的修改或者引入无关紧要的设计，但不改变其算法和流程的核心设计都在该专利的保护范围内。
本申请一实施例涉及一种电子设备，如图19所示，包括至少一个处理器301；以及，与至少一个处理器301通信连接的存储器302；其中，存储器302存储有可被至少一个处理器301执行的指令，指令被至少一个处理器301执行，以使至少一个处理器301能够执行如上述的通讯控制方法。
其中，存储器302和处理器301采用总线方式连接，总线可以包括任意数量的互联的总线和桥，总线将一个或多个处理器301和存储器302的各种电路连接在一起。总线还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路连接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口在总线和收发机之间提供接口。收发机可以是一个元件，也可以是多个元件，比如多个接收器和发送器，提供用于在传输介质上与各种其他装置通信的单元。经处理器301处理的数据通过天线在无线介质上进行传输，进一步，天线还接收数据并将数据传送给处理器301。
处理器301负责管理总线和通常的处理，还可以提供各种功能，包括定时，外围接口，电压调节、电源管理以及其他控制功能。而存储器302可以被用于存储处理器301在执行操作时所使用的数据。
本申请一实施例涉及一种计算机可读存储介质，存储有计算机程序。计算机程序被处理器执行时实现上述方法实施例。
即，本领域技术人员可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
本领域的普通技术人员可以理解，上述各实施例是实现本申请的具体实施例，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本申请的精神和范围。

Claims (16)

  1. 一种链路测试方法，应用于客户端，所述方法包括：
    向服务端发送会话请求并建立测试会话，所述会话请求携带有返程链路的路径信息；
    发送测试报文至所述服务端，并通过所述返程链路接收所述服务端发送的与所述测试报文对应的反射报文。
  2. 根据权利要求1所述的链路测试方法，其中，所述会话请求包括用于创建反射器的信息，所述用于创建反射器的信息中包含所述返程链路的路径信息。
  3. 根据权利要求2所述的链路测试方法，其中，所述发送测试报文至所述服务端，并通过所述返程链路接收所述服务端发送的与所述测试报文对应的反射报文，包括：
    通过本地创建的发射器发送测试报文至所述服务端；
    通过所述路径信息对应的所述返程链路接收与所述测试报文对应的反射报文，所述反射报文通过所述服务端中的反射器发送。
  4. 根据权利要求1所述的链路测试方法，其中，所述用于创建反射器的信息为返程TLV信息。
  5. 根据权利要求4所述的链路测试方法，其中，所述TLV信息包括所述返程链路的类型、所述TLV信息的长度、所述返程链路的子类型、所述返程链路的路径信息。
  6. 根据权利要求1至5中任一项所述的链路测试方法，其中，在所述向服务端发送会话请求并建立测试会话之前，还包括：
    向所述服务端发起连接请求；
    接收所述服务端返回的应答消息，所述应答消息携带有所述服务端期望支持的通信模式；
    向所述服务端发送连接消息，所述连接消息携带有所述客户端支持所述通信模式的信息，所述服务端与所述客户端基于所述通信模式建立连接。
  7. 根据权利要求6所述的链路测试方法，其中，所述服务端期望支持的通信模式为双向共路径模式。
  8. 根据权利要求7所述的链路测试方法，其中，所述应答消息中模式字段 的一个比特位用于标识所述双向共路径模式。
  9. 根据权利要求1至8中任一项所述的链路测试方法，其中，在SR-MPLS-POLICY场景下，所述路径信息表示为标签栈信息或者所述返程链路所绑定的BSID信息；在SRV6-POLICY场景下，所述路径信息表示为Segment-List信息或者所述返程链路所绑定的BSID信息；在SR-TE或MPLS-TE场景下，所述路径信息为SR-TE的隧道ID或MPLS-TE的隧道ID；在VPN场景下，所述路径信息为VPN实例号或返程链路的标识符；在IP场景或SR BE场景下，所述路径信息为回程IP地址信息或返程标签信息。
  10. 一种链路测试方法，应用于服务端，所述方法包括：
    接收客户端发送的会话请求并建立测试会话，所述会话请求携带有返程链路的路径信息；
    接收所述客户端发送的测试报文，生成与所述测试报文对应的反射报文；
    通过所述返程链路向所述客户端发送所述反射报文。
  11. 根据权利要求10所述的链路测试方法，其中，所述会话请求包括用于创建反射器的信息，所述用于创建反射器的信息中包含所述返程链路的路径信息。
  12. 根据权利要求11所述的链路测试方法，其中，所述接收客户端发送的会话请求并建立测试会话之后，还包括：
    根据所述用于创建反射器的信息创建反射器。
  13. 根据权利要求12所述的链路测试方法，其中，所述接收所述客户端发送的测试报文，生成与所述测试报文对应的反射报文，包括：
    利用所述反射器接收所述客户端的发射器发送的测试报文，并利用所述反射器生成与所述测试报文对应的反射报文；
    所述通过所述返程链路向所述客户端发送所述反射报文，包括：
    利用所述反射器通过所述路径信息对应的所述返程链路向所述客户端发送所述反射报文。
  14. 根据权利要求12或13所述的链路测试方法，其中，所述根据所述用于创建反射器的信息创建反射器之后，还包括：
    将所述路径信息存储在所述反射器中。
  15. 一种电子设备，包括：
    至少一个处理器；以及，
    与所述至少一个处理器通信连接的存储器；其中，
    所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求1至9中任一项所述的链路测试方法，或执行如权利要求10至14任一项所述的链路测试方法。
  16. 一种计算机可读存储介质，存储有计算机程序，所述计算机程序被处理器执行时实现权利要求1至9中任一项所述的链路测试方法，或实现权利要求10至14任一项所述的链路测试方法。
PCT/CN2022/103491 2021-08-27 2022-07-01 链路测试方法、电子设备及存储介质 WO2023024706A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110996602.7 2021-08-27
CN202110996602.7A CN115733769A (zh) 2021-08-27 2021-08-27 链路测试方法、电子设备及存储介质

Publications (1)

Publication Number Publication Date
WO2023024706A1 true WO2023024706A1 (zh) 2023-03-02

Family

ID=85290342

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/103491 WO2023024706A1 (zh) 2021-08-27 2022-07-01 链路测试方法、电子设备及存储介质

Country Status (2)

Country Link
CN (1) CN115733769A (zh)
WO (1) WO2023024706A1 (zh)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104009961A (zh) * 2013-02-25 2014-08-27 杭州华三通信技术有限公司 一种PPPoE会话标识分配方法及设备
EP3099015A1 (en) * 2015-05-25 2016-11-30 Juniper Networks, Inc. Selecting and monitoring a plurality of services key performance indicators using twamp
CN107979619A (zh) * 2016-10-21 2018-05-01 中兴通讯股份有限公司 一种twamp会话协商方法、客户端及服务端
CN111385822A (zh) * 2018-12-29 2020-07-07 华为技术有限公司 一种配置方法及控制器
CN111866088A (zh) * 2020-06-29 2020-10-30 深圳壹账通智能科技有限公司 基于区块链的测试方法及装置、计算机设备、存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104009961A (zh) * 2013-02-25 2014-08-27 杭州华三通信技术有限公司 一种PPPoE会话标识分配方法及设备
EP3099015A1 (en) * 2015-05-25 2016-11-30 Juniper Networks, Inc. Selecting and monitoring a plurality of services key performance indicators using twamp
CN107979619A (zh) * 2016-10-21 2018-05-01 中兴通讯股份有限公司 一种twamp会话协商方法、客户端及服务端
CN111385822A (zh) * 2018-12-29 2020-07-07 华为技术有限公司 一种配置方法及控制器
CN111866088A (zh) * 2020-06-29 2020-10-30 深圳壹账通智能科技有限公司 基于区块链的测试方法及装置、计算机设备、存储介质

Also Published As

Publication number Publication date
CN115733769A (zh) 2023-03-03

Similar Documents

Publication Publication Date Title
US8576847B2 (en) Mechanisms for discovering path maximum transmission unit
TWI744359B (zh) 一種資料傳輸的方法及網路設備
CA3010741C (en) Method and system for automatically bypassing network proxies in the presence of interdependent traffic flows
KR102592206B1 (ko) 차량 내 sdn 기반의 네트워크 관리 장치 및 그 제어 방법
JP6269999B2 (ja) パケット処理方法および装置
EP3331205B1 (en) Data packet transmission method utilized in ipv6 network and device utilizing same
WO2017000593A1 (zh) 报文处理方法及装置
US20110040968A1 (en) Method and system for forwarding data between private networks
WO2020073685A1 (zh) 转发路径确定方法、装置、系统、计算机设备及存储介质
WO2017028398A1 (zh) 通信处理方法和装置
US11418951B2 (en) Method for identifying encrypted data stream, device, storage medium and system
WO2022083563A1 (zh) 链路检测方法、链路检测装置、终端设备和存储介质
WO2020038443A1 (zh) 桥接通信的方法和设备
WO2022062679A1 (zh) 数据处理方法、系统、封装节点和解封装节点
JP2015177263A (ja) 通信装置、情報処理装置、通信方法および通信プログラム
Tulumello et al. Micro SIDs: A solution for efficient representation of segment IDs in SRv6 networks
WO2022134671A1 (zh) 数据传输方法、电子设备和存储介质
US11464057B2 (en) Method and apparatus for high speed processing of GTP-U packet in a mobile network
WO2023024706A1 (zh) 链路测试方法、电子设备及存储介质
WO2023035836A1 (zh) 一种报文处理方法及相关装置
WO2023173876A1 (zh) 数据通信方法、装置、设备和介质
CN111800340B (zh) 数据包转发方法和装置
CN114598636A (zh) 流量调度方法、设备及系统
WO2020147617A1 (zh) 数据前转的方法和设备
JP2016063382A (ja) 通信システム、通信方法、および、転送装置

Legal Events

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

Ref document number: 22860053

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE