CN107979619B

CN107979619B - TWAMP session negotiation method, client and server

Info

Publication number: CN107979619B
Application number: CN201610921057.4A
Authority: CN
Inventors: 窦战伟; 卢伟; 郭俊
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2016-10-21
Filing date: 2016-10-21
Publication date: 2021-06-25
Anticipated expiration: 2036-10-21
Also published as: CN107979619A

Abstract

The invention discloses a TWAMP session negotiation method, a client and a server, wherein the method comprises the following steps: the client and the server negotiate a private network tag carrying mode; when the client and the server both support a private network label carrying mode, a session request message for any VPN sent to the server carries a private network label of the VPN, and the server extracts the VPN private network label from the session request message and uses the VPN private network label as identification information for distinguishing different session requests. The invention provides a new communication mode, and a client carries a VPN private network label when initiating a session request under the mode, so that a server extracts the VPN private network label as a basis for distinguishing the session request after receiving the session request and can also be used as a basis for subsequently distinguishing a test message, thereby perfectly solving the problem that different session requests and test messages cannot be distinguished when an IP address and a port number are overlapped in L3VPN networking.

Description

TWAMP session negotiation method, client and server

Technical Field

The present invention relates to the field of communications, and in particular, to a TWAMP (Two-Way Active Measurement Protocol) session negotiation method, a client, and a server.

Background

The TWAMP protocol is a protocol for measuring IP performance, and is mainly used for measuring performance such as IP network link delay and packet loss rate. The TWAMP protocol consists of two part protocols: TWAMP Control protocol (TWAMP-Control) and TWAMP Test protocol (TWAMP-Test). TWAMP-Control is mainly used to initialize, start and stop test sessions. TWAMP-Test is mainly used to interact Test packets between the endpoints of the Test while performing measurements of IP performance.

TWAMP generally consists of 4 logical entities, and the simple architecture is shown in fig. 1:

Control-Client: the client-TWAMP test initiating end sends a request for establishing control connection to the Server entity, negotiates the communication mode of the message, receives the port number of the test message at the Session-Reflector end, and the like. Control-Client controls the start and termination of TWAMP-Test sessions.

Server: and the server receives a request for establishing Control connection sent by the Control-Client terminal, negotiates a message communication mode with the Control-Client terminal, receives a port number of a test message by the Session-Reflector terminal and the like. The Server side manages one or more TWAMP-Test sessions.

Session-Sender: and sending the node of the Test message to the Session-Reflector in the TWAMP-Test Session, receiving the Test message reflected by the Session-Reflector, collecting the performance information, and counting the measurement result.

Session-Reflector: and in the TWAMP-Test Session, receiving a Test message from a Session-Sender end and sending a response message.

In the Control protocol negotiation phase, first, the Control-Client initiates a TCP Control connection to the Server, and the Server side responds with a Greeting message (as shown in fig. 2), and indicates the communication mode that it desires to support in the mode field of the message (each bit of the mode field identifies one communication mode). After receiving the Greeting message, the Control-Client sends a Set-Up-Response message (as shown in fig. 3) to the Server, and indicates the selected communication mode and the related support information such as authentication, encryption and the like in the mode field of the message; the Server responds with a Server-Start message (as shown in fig. 4), which contains the mode received by the Server and the Start time. So far, the establishment of the TWAMP-Control connection is completed between the Client and the Server.

In the negotiation stage of the Control Session, the Control-Client requests the Server end to create a test Session by sending a Request-TW-Session message (as shown in fig. 5); the Server responds through Accept-Session (as shown in fig. 6), which includes information about whether to Accept and relevant support. Multiple test sessions may be created between the Control-Client and the Server on each TWAMP-Control connection.

In the testing stage, the Session-Sender and Session-reflector send testing messages to each other according to the TWAMP testing protocol, and the performance of the link is measured.

In the session negotiation stage, the Control-Client generally uses information such as a source IP address, a destination IP address, a source UDP port number, and a destination UDP port number to send a session request to the Server, and the Server uses the information to distinguish different test sessions. However, in the L3VPN networking environment, private network IP addresses may overlap, as shown in fig. 7 and 8, IP addresses 192.168.1.1 and 192.168.1.2 may be in either VPN1 or VPN 2.

Taking fig. 7 as an example, when the device PE1 uses the same IP address and the same port number to send session requests to the Server PE2 device for the VPN1 and the VPN2, respectively, on the same control connection, the Server cannot distinguish which VPN the two session requests are for. Thus, the Server end regards the two session requests as the same session request and creates a test session.

Taking fig. 8 as an example, when the device PE1 and the device PE3 respectively use the same IP address and port number to send Session requests to the Server-side device PE2 on different control connections, even though the Server can distinguish different test requests according to the control connections to respectively create different test sessions, in the test phase, the test packets are not dependent on the control connections, and when the same test packet reaches the Session-reflector, the Session-reflector is also difficult to distinguish which test Session the test packet belongs, thereby bringing difficulty to the link IP performance measurement.

In addition, when IP addresses overlap, although different sessions can be distinguished using UDP port numbers, this also causes the following problems.

1, at the Server side, the UDP port number resources are limited, and when TWAMP measurement is deployed in a large amount, a different port number needs to be allocated to each test session, which causes waste of UDP port number resources.

Taking fig. 4 as an example, since TWAMP-Client is respectively deployed on different devices, uniqueness check cannot be performed on UDP port numbers and IP addresses of test sessions, which brings certain difficulty to network deployment.

3, in order to simplify network deployment, the problem of overlapping IP addresses cannot be solved under the condition that the UDP port numbers of the test session source and the destination use known port numbers.

Disclosure of Invention

The invention provides a TWAMP session negotiation method, a client and a server, which are used for solving the problem that different session requests cannot be effectively distinguished when addresses of different L3VPN networking are overlapped in the prior art.

According to an aspect of the present invention, there is provided a TWAMP session negotiation method, including:

the client and the server negotiate a private network tag carrying mode;

when the client and the server both support a private network label carrying mode, a session request message for any virtual private network VPN sent to the server carries a private network label of the VPN.

According to another aspect of the present invention, there is provided a TWAMP session negotiation method, including:

the server side and the client side negotiate a private network tag carrying mode;

when the server and the client both support a private network label carrying mode, after receiving a session request message sent by the client, the server extracts a VPN private network label from the session request message, and the VPN private network label is used as identification information for distinguishing different session requests.

According to a third aspect of the present invention, there is provided a client for TWAMP session negotiation, comprising:

the first negotiation module is used for carrying out negotiation of a private network tag carrying mode with the server;

and the message sending module is used for sending a session request message aiming at any virtual private network VPN to the server side when the client side and the server side both support a private network label carrying mode, wherein the session request message carries the private network label of the VPN.

According to a fourth aspect of the present invention, there is provided a service end for TWAMP session negotiation, including:

the second negotiation module is used for carrying out negotiation of a private network tag carrying mode with the client;

and the message processing module is used for extracting a VPN private network label from the session request message as identification information for distinguishing different session requests after receiving the session request message sent by the client when the server and the client both support a private network label carrying mode.

According to a fifth aspect of the present invention, there is provided a client for TWAMP session negotiation, comprising: a memory and a processor; the memory has stored therein computer instructions, which, upon execution by the processor, perform the method of:

carrying out negotiation of private network label carrying mode with a server;

According to a sixth aspect of the present invention, there is provided a service end for TWAMP session negotiation, including: a memory and a processor; the memory has stored therein computer instructions, which, upon execution by the processor, perform the method of:

negotiating a private network tag carrying mode with a client;

when the server side and the client side both support a private network label carrying mode, after receiving a session request message sent by the client side, extracting a VPN private network label from the session request message, wherein the VPN private network label is used as identification information for distinguishing different session requests.

The invention has the following beneficial effects:

the invention provides a new communication mode, namely a private network label carrying mode, wherein a client carries a VPN private network label when initiating a session request in the mode, so that a server extracts the VPN private network label as a basis for distinguishing the session request after receiving the session request and can also be used as a basis for distinguishing a test message in a subsequent test stage, and the problem that different session requests and test messages cannot be distinguished when an IP address and a port number are overlapped in L3VPN networking is perfectly solved.

The foregoing description is only an overview of the technical solutions of the present invention, and the embodiments of the present invention are described below in order to make the technical means of the present invention more clearly understood and to make the above and other objects, features, and advantages of the present invention more clearly understandable.

Drawings

Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The drawings are only for purposes of illustrating the preferred embodiments and are not to be construed as limiting the invention. Also, like reference numerals are used to refer to like parts throughout the drawings. In the drawings:

FIG. 1 is a simple architecture of the TWAMP protocol;

FIG. 2 is a schematic diagram of a Greeting packet encapsulation format;

FIG. 3 is a diagram illustrating a packet encapsulation format of a Set-up-response packet;

FIG. 4 is a diagram illustrating a Server-Start packet encapsulation format;

FIG. 5 is a diagram illustrating a Request-TW-Session message encapsulation format;

FIG. 6 is a schematic diagram of an Accept-Session message encapsulation format;

fig. 7 is a simple schematic diagram of an address overlap scenario in L3VPN networking;

fig. 8 is a simplified schematic diagram of another address overlap scenario in L3VPN networking;

fig. 9 is a flowchart of a TWAMP session negotiation method according to a first embodiment of the present invention;

fig. 10 is a schematic diagram of a message format in which a private network label of a VPN is carried in an MBZ field of a session request message in the first embodiment of the present invention;

fig. 11 is a schematic diagram of a message format in which a field is newly added in a session request message to carry a private network label of a VPN according to the first embodiment of the present invention;

fig. 12 is a flowchart of a TWAMP session negotiation method according to a second embodiment of the present invention;

fig. 13 is a schematic networking diagram illustrating an application of a TWAMP session negotiation method according to a fourth embodiment of the present invention;

fig. 14 is a schematic networking diagram of an application of a TWAMP session negotiation method according to a fifth embodiment of the present invention;

fig. 15 is a schematic networking diagram illustrating an application of a TWAMP session negotiation method according to a sixth embodiment of the present invention;

fig. 16 is a schematic networking diagram illustrating an application of a TWAMP session negotiation method according to a seventh embodiment of the present invention;

fig. 17 is a schematic networking diagram illustrating an application of a TWAMP session negotiation method according to an eighth embodiment of the present invention;

fig. 18 is a block diagram illustrating a configuration of a client for TWAMP session negotiation according to a ninth embodiment of the present invention;

fig. 19 is a block diagram of a server for TWAMP session negotiation according to a tenth embodiment of the present invention.

Detailed Description

Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

In a first embodiment of the present invention, there is provided a TWAMP session negotiation method, as shown in fig. 9, including the following steps:

step S901, the client and the server negotiate the private network label carrying mode;

in the embodiment of the invention, the client and the server inform the opposite terminal whether the home terminal supports the private network label carrying mode or not through the interactive mode negotiation message.

In some embodiments, whether the opposite terminal supports the private network tag carrying mode or not can be determined by determining whether a private network tag carrying mode flag bit in the interactive mode negotiation message is set or not between the client and the server.

Further, in order to improve compatibility with the TWAMP protocol, the mode negotiation message in this embodiment may be: a communication mode negotiation message used by the control protocol negotiation stage. That is, the communication mode negotiation message is multiplexed, and the negotiation of the private network label carrying mode is performed. The communication mode negotiation message used in the control protocol negotiation stage includes: the server sends a Greeting message to the client, and the client feeds back a Set-Up-Response message to the server. In this embodiment, the flag bit of the private network tag carrying mode may multiplex one or more bits of the communication mode negotiation message that are not occupied in the mode field.

Step S902, when both the client and the server support the private network label carrying mode, the session request packet for any VPN sent to the server carries the private network label of the VPN.

In the embodiment of the present invention, the manner of carrying the private network label of the VPN in the session request message includes, but is not limited to:

the first method is as follows: the client carries the VPN private network label information by multiplexing the MBZ field in the session request message; as shown in fig. 10, the VPN private network label is carried in the lower four bytes of the MBZ field in the session request message.

And in the second mode, the client carries the VPN private network label information by newly adding a VPN private network label field in the session request message. The client may add a VPN private network tag field between the MBZ and the HMAC field in the session request message to carry the VPN private network tag information, as shown in fig. 11 specifically; or, the client may add a VPN private network tag field after the HMAC field in the session request message to carry the VPN private network tag information.

The first mode is multiplexing of the MBZ field, and compared with the second mode, the method avoids the expansion of the session request message field, and the implementation mode is simpler and more efficient.

In summary, according to the method of this embodiment, when determining that both the home terminal and the server terminal support the private network tag carrying mode, the client terminal carries the VPN private network tag when initiating the session request, so as to provide information support for the server terminal to identify the session request.

In a second embodiment of the present invention, there is provided a TWAMP session negotiation method, as shown in fig. 12, including the following steps:

step S1201, the server and the client negotiate the private network label carrying mode;

corresponding to the first embodiment, in the embodiment of the present invention, the server and the client negotiate a message through an interaction mode to inform the opposite terminal whether the home terminal supports the private network tag carrying mode.

In some embodiments, whether the opposite terminal supports the private network tag carrying mode or not can be determined by determining whether a private network tag carrying mode flag bit in the interactive mode negotiation message is set or not between the server and the client.

Step S1202, when the server and the client both support a private network label carrying mode, after receiving a session request message sent by the client, the server extracts a VPN private network label from the session request message, and the VPN private network label is used as identification information for distinguishing different session requests.

In the embodiment of the present invention, the manner of extracting the VPN private network label from the session request message by the server includes: the server side extracts a VPN private network label from an MBZ field in the session request message; or the server side extracts the VPN private network label from the newly added VPN private network label field in the session request message.

Furthermore, in the embodiment of the present invention, after the server extracts the identification information, it determines whether the identification information of the currently created test session is completely the same as the extracted identification information, and if so, refuses to create a new test session; otherwise, a new test session is created, and the extracted identification information is stored as the identification information of the created new test session to be used as the basis for removing the duplicate of the session request message and distinguishing the test messages in the test stage.

In an optional embodiment of the present invention, when the server extracts the VPN private network tag from the session request packet, the server further extracts a source IP, a destination IP, a source port number, and a destination port number of the packet, and cooperatively extracts the VPN private network tag as identification information for distinguishing different session requests. In the embodiment, both the IP address and the port number are used as the identification information, so that the efficiency of re-query of the session request message can be improved, specifically, since the IP address and the port number are carried in the message header, after the message header is analyzed to obtain the IP address and the port number, if the same test session does not exist according to the IP address and the port number, the current request can be directly judged to be a non-repeated request, and only when the same test session exists, the private network tag carried in the message is continuously used for judging whether the session request is a repeated session request, so that the query efficiency is improved to a certain extent.

Further, in the embodiment of the present invention, in the test stage:

when the server and the test session reflection node belong to the same device, the test messages of different test sessions are directly distinguished according to the stored identification information;

when the server and the test session reflection node do not belong to the same device, the server provides the identification information of the test session to the test session reflection node, so that the test session reflection node can distinguish test messages of different test sessions according to the identification information.

As can be seen from the first and second embodiments, the present invention provides a new TWAMP communication mode and TWAMP session negotiation method to solve the problem of TWAMP test session negotiation caused by address overlapping in the L3VPN networking. The method identifies a new communication Mode, namely a Private network Label Carried Mode (Private Label Carried Mode), by using a new bit of a Mode field in a TWAMP-Control protocol Greeting message. In the new communication mode, the TWAMP-Control protocol uses a new Request-TW-Session Request message format to perform a test Session negotiation, and the new Request-TW-Session message includes a private network label of the L3VPN with four bytes, as shown in fig. 10 and 11, the private network label may be encapsulated by multiplexing the lower four bytes of the 8-byte MBZ, or may be encapsulated by adding 4 bytes behind the 8-byte MBZ. At the Server end, when the corresponding IP address and port number and other information in the request message are the same, the Server distinguishes different session requests through the VPN private network label in the request message. In the testing stage, when the IP address and the port number in the test message are the same, which test session the message belongs to can be determined according to the private network label of the test message, thereby perfectly solving the problem of overlapping of the IP address and the port number in the L3VPN networking, and simultaneously, under the condition that the VPN addresses are not overlapped, the communication mode and the new request message format provided by the invention can be used, which provides a uniform solution for the TWAMP measurement in the L3VPN scene deployment, and does not need to consider the problem of overlapping of the addresses.

The following examples are provided to illustrate the practice of the present invention in more detail.

In a third embodiment of the present invention, a TWAMP session negotiation method is provided, a networking scenario applied by the method is shown in fig. 7, PE1 serves as a TWAMP-Client, PE2 serves as a TWAMP-Server, CE1 and CE2 are in a VPN1, CE3 and CE4 are in a VPN2, CE1 and CE3 configure the same source private network IP address 192.168.1.1, and CE2 and CE4 configure the same destination private network IP address 192.168.1.2. If TWAMP detection is deployed between PE1 and PE2, when an IP address of CE1, CE2, CE3 and CE4 is used for simulating a user incoming message to perform L3-UNI measurement, a specific scheme for testing session negotiation of VPN1 and VPN2 is as follows:

before initiating the negotiation of the control protocol, a new communication Mode, Private Label Carried Mode (Private Label Carried Mode), is enabled at the TWAMP-Client side and the PE2TWAMP-Server side of the PE 1.

2, in the negotiation stage of the TWAMP-Control protocol, setting a 'private label carrying mode' flag bit in a mode field of a Greeting message answered by the TWAMP-Server end to indicate that the TWAMP-Server supports the new communication mode (the mode field occupies 32 bits, each bit represents a new communication mode, currently, the lower 7 bits are occupied by other modes, and the invention uses a certain bit of 8 to 31 bits to identify the new communication mode proposed by the invention).

And 3, after receiving the Greeting message, the TWAMP-Client judges whether the Client supports the new communication mode provided by the invention, and if so, the position of the new communication mode mark is Set in a mode field of a Set-Up-Response message sent by the TWAMP-Client to indicate that the TWAMP-Client supports the new communication mode.

4, after the Server end receives the Set-Up-Response message and confirms the communication mode, responding to the Server-Start message to establish the control connection.

5, in a TWAMP Session negotiation stage, the TWAMP Client initiates a Request-TW-Session Request for VPN1 and VPN2 respectively on the established control connection, and if the TWAMP Client uses the "private label carrying mode" proposed by the present invention, then in sending the Request-TW-Session Request message, in addition to the IP address and port number of CE1, CE2, CE3, and CE4, four bytes of VPN private network label information are carried, and the label information may be encapsulated by multiplexing the lower four bytes of the MBZ field in the Request message, as shown in fig. 10, or 4 bytes of information may be appended after 8 bytes of MBZ and before the HMAC field, and the label information is encapsulated, as shown in fig. 11, the embodiment of the present invention uses the first mode for encapsulation. The IP addresses and port numbers in the two session request messages may be the same or different, but the VPN labels are different.

After receiving Request-TWAMP-Server Session Request message, if supporting the invention to propose 'private label carrying mode', then resolving information such as IP address, port number and carried private network label from the Request message, if finding that the IP address and port number are the same as the existing test Session but the carried private network label is different, then creating a new test Session, and keeping the resolved private label information in the Session. If the private label carrying mode provided by the invention is not supported, the private network label information is not analyzed, the TWAMP-Server searches whether the same test session exists according to the information such as the IP address, the port number and the like, and if the same test session exists, the session request is considered to be a repeated session request.

And 7, in the TWAMP test stage, respectively sending a test message to a Session-Reflector by the Session-Sender aiming at each test Session to measure the link performance, after the Session-Reflector receives the test message, analyzing information such as an IP address, a port number, an L3VPN private network label and the like from the message, then searching which test Session the message belongs to according to the information, and respectively responding to each test Session and responding to a response message. As shown in fig. 7, when the IP addresses and port numbers of the test sessions of VPN1 and VPN2 are the same, the messages can be distinguished according to the L3VPN private network label, and belong to a test session of VPN1 or a test session of VPN 2.

Similarly, after the Session-Sender receives the test packet reflected by the Session-Reflector, if the IP address and the port number in the packet are the same, the TWAMP-Sender may also distinguish the test packet of the test Session to which the packet belongs according to the L3VPN private network tag information of the packet.

It should be noted that the CE device related in the present invention is a customer edge device, but is not limited to a CE device, and may also be a base station controller, a server, a working host, and the like.

In a fourth embodiment of the present invention, a network deployment scenario applied by the method is shown in fig. 13, and in this embodiment, different test sessions are respectively created for different VPNs by using different TWAMP-Control connections on different PE nodes, and a scenario application in which a user enters a packet and performs an L3-UNI test is simulated by borrowing a CE IP address. The PE1 and PE3 are used as Control-Client and Session-Sender, the PE2 is used as Server and Session-Reflector, and the IP addresses of the CE devices of the VPN1 and VPN2 are overlapped. Mainly comprises the following steps:

1, firstly enabling a 'private label carrying mode' provided by the invention on PE1, PE2 and PE3, initiating the establishment of TWAMP-Control connection by PE1 and PE3, and setting a 'private label carrying mode' flag bit in mode fields of a Greeting message and a request-response message in a TWAP-Control connection negotiation process.

2, after the TWAMP-Control connection is established, PE1 initiates a Request-TW-Session Request for VPN1 on the established Control connection, where the Request message includes the IP addresses and port numbers of CE1 and CE2, and encapsulates the private network tag information of VPN1 in the lower 4 bytes of the 8-byte MBZ field of the message. The PE2 initiates a Request-TW-Session Request for the VPN2 on the established control connection, where the Request message includes the IP addresses and port numbers of the CE3 and CE4, respectively, and at the same time, encapsulates the private network tag information of the VPN2 in the low 4 bytes of the MBZ field of 8 bytes of the message. The IP addresses and port numbers in the two session request messages may be the same or different, but the VPN labels are different.

3, after receiving the request message, the TWAMP-Server of PE2 analyzes the information such as IP address, port number, VPN private network label, etc. in the request message, and creates different test sessions when judging that there is no same test session according to the information. When the IP address and port number in both session requests are the same, different test sessions can be distinguished according to the VPN private network label (private network label, unique in the L3VPN network).

And 4, after the test Session is established, the Session-Sender sends a test message to the Session-Reflector respectively aiming at each test Session to carry out link performance measurement.

And 5, after receiving the test message, the Session-Reflector determines which test Session the test message is according to the IP address, the port number and the L3VPN private network label, and respectively responds to each test Session. And after the Session-Sender receives the response message of each test Session, finishing the performance measurement of the link.

In a fifth embodiment of the present invention, a networking scenario of an application of the TWAMP session negotiation method is shown in fig. 14, and in this embodiment, different test sessions are respectively created for different VPNs by using the same TWAMP-Control connection on the same PE node, and a scenario application of L3-UNI test is performed by using a PE L3-UNI interface IP address. The PE1 and the PE3 are used as Control-Client and Session-Sender, the PE2 is used as Server and Session-Reflector, and IP addresses of L3-UNI interfaces of the VPN1 and the VPN2 are overlapped on the PE equipment. Mainly comprises the following steps:

1, firstly enabling a private label carrying mode provided by the invention of TWAMP on PE1 and PE2, initiating the establishment of TWAMP-Control connection by PE1, and setting a flag bit of the private label carrying mode in mode fields of a Greeting message and a request-response message in a TWAP-Control connection negotiation process.

2, after the TWAMP-Control connection is established, PE1 initiates a Request-TW-Session Request for VPN1 and VPN2 on the established Control connection, where the Request message includes the IP addresses and port numbers of the CE1 access interface, the CE2 access interface, the CE3 access interface, and the CE4 access interface, and at the same time, encapsulates the private network label information of the VPN in the low 4 bytes of the 8-byte MBZ field of the message. The IP addresses and port numbers in the two session request messages may be the same or different, but the VPN labels are different.

In a sixth embodiment of the present invention, a network deployment scenario of the method application is shown in fig. 15, and this embodiment is a scenario application in which different TWAMP-Control connections are used to create different test sessions for different VPNs on different PE nodes, and a PE L3-UNI interface IP is used to perform an L3UNI test. The PE1 and the PE3 are used as Control-Client and Session-Sender, the PE2 is used as Server and Session-Reflector, and IP addresses of L3-UNI interfaces of the VPN1 and the VPN2 are overlapped on the PE equipment. Mainly comprises the following steps:

2, after the TWAMP-Control connection is established, PE1 initiates a Request-TW-Session Request for VPN1 on the established Control connection, where the Request message includes the IP addresses and port numbers of CE1 and CE2L3UNI interfaces, and the private network label information of VPN1 is encapsulated in the lower 4 bytes of the 8-byte MBZ field of the message. The PE2 initiates a Request-TW-Session Request for the VPN2 on the established control connection, where the Request message includes the IP addresses and port numbers of the CE3 and CE4L3UNI interfaces, and at the same time, encapsulates the private network label information of the VPN2 in the low 4 bytes of the MBZ field of 8 bytes of the message. The IP addresses and port numbers in the two session request messages may be the same or different, but the VPN labels are different.

In a seventh embodiment of the present invention, a networking scenario applied by the method is shown in fig. 16, and in this embodiment, different test sessions are created by initiating TWAMP session requests to the same PE device for different VPNs on different CE nodes, and an IP link metric from the CE to the access PE device is performed. Wherein, CE1, CE3 are as Control-Client and Session-Sender, PE1 is as Server and Session-Reflector, IP addresses of L3-UNI interfaces of VPN1 and VPN2 are overlapped on PE equipment, and addresses of CE1, CE3 are overlapped. Mainly comprises the following steps:

1, firstly enabling a 'private label carrying mode' provided by the invention on CE1, CE3 and PE1, initiating the establishment of TWAMP-Control connection to PE1 by CE1 and CE3, and setting a 'private label carrying mode' flag bit in mode fields of a Greeting message and a request-response message in a TWAP-Control connection negotiation process.

2, after the TWAMP-Control connection is established, the CE1 initiates a Request-TW-Session Request for the VPN1 on the established Control connection, where the Request message includes the CE1IP address, the IP address and the port number of the PE1L3UNI interface, and at the same time, encapsulates the private network tag information of the VPN1 in the low 4 bytes of the 8-byte MBZ field of the message. The CE3 initiates a Request-TW-Session Request for the VPN2 on the established control connection, where the Request message includes the CE3IP address, the IP address and the port number of the PE1L3UNI interface, and at the same time, encapsulates the private network tag information of the VPN2 in the low 4 bytes of the MBZ field of 8 bytes of the message. The IP addresses and port numbers in the two session request messages may be the same or different, but the VPN labels are different.

3, after receiving the request message, the TWAMP-Server of PE1 analyzes the information such as IP address, port number, VPN private network label, etc. in the request message, and creates different test sessions when judging that there is no same test session according to the information. When the IP address and port number in both session requests are the same, different test sessions can be distinguished according to the VPN private network label (private network label, unique in the L3VPN network).

In an eighth embodiment of the present invention, a network deployment scenario applied by the method is shown in fig. 17, and this embodiment is a scenario application in which, under the condition that L3VPN addresses are not overlapped, different test sessions are respectively created for different VPNs by using the same TWAMP-Control connection on the same PE node, and an L3-UNI test is performed by using an IP address of an L3-UNI interface of a PE device. In the figure, PE1 serves as a Control-Client and a Session-Sender, PE2 serves as a Server and a Session-Reflector, and IP addresses of L3-UNI interfaces of VPN1 and VPN2 do not overlap on a PE device. Mainly comprises the following steps:

1, firstly enabling a private label carrying mode provided by the invention of TWAMP on PE1 and PE2, initiating the establishment of TWAMP-Control connection by PE1, and setting a flag bit of the private label carrying mode in mode fields of a Greeting message and a requests-response message in a TWAP-Control connection negotiation process.

2, after the TWAMP-Control connection is established, PE1 initiates a Request-TW-Session Request for VPN1 and VPN2 on the established Control connection, respectively, where the Request message includes IP addresses and port numbers of CE1, CE2, CE3, and CE4, and at the same time, encapsulates the private network tag information of VPN in the low 4 bytes of the 8-byte MBZ field of the message. The IP addresses and port numbers in the two session request messages may be the same or different, but the VPN labels are different.

3, after receiving the request message, the TWAMP-Server of PE2 analyzes the information such as IP address, port number, VPN private network label, etc. in the request message, and creates different test sessions when judging that there is no same test session according to the information.

In a ninth embodiment of the present invention, there is provided a client for TWAMP session negotiation, as shown in fig. 18, the client comprising:

a first negotiation module 1801, configured to perform negotiation of a private network tag carrying mode with a server;

a message sending module 1802, configured to send, to the server, a session request message for any VPN to carry a private network label of the VPN when both the client and the server support a private network label carrying mode.

In the embodiment of the present invention, the first negotiation module 1801 interacts a mode negotiation message with the server, and determines whether the opposite terminal supports the private network tag carrying mode by determining whether a private network tag carrying mode flag bit in the interacted mode negotiation message is set.

Further, in order to improve compatibility with the TWAMP protocol, the mode negotiation message in this embodiment is: a communication mode negotiation message used in a control protocol negotiation stage; that is, the communication mode negotiation message is multiplexed, and the negotiation of the private network label carrying mode is performed. The communication mode negotiation message used in the control protocol negotiation stage includes: the server sends a Greeting message to the client, and the client feeds back a Set-Up-Response message to the server. In this embodiment, the flag bit of the private network tag carrying mode may multiplex one or more bits of the communication mode negotiation message that are not occupied in the mode field.

Further, in the embodiment of the present invention, the message sending module 1802 is specifically configured to multiplex the field that must be zero MBZ in the session request message, and carry the VPN private network label information; or the client carries the VPN private network label information by adding a VPN private network label field in the session request message.

In summary, in this embodiment, when determining that both the home terminal and the server terminal support the private network tag carrying mode, the client terminal carries the VPN private network tag when initiating the session request, so as to provide information support for the server terminal to identify the session request.

In a tenth embodiment of the present invention, there is provided a server for TWAMP session negotiation, as shown in fig. 19, the server comprising:

a second negotiation module 1901, configured to perform negotiation of a private network tag carrying mode with a client;

the message processing module 1902 is configured to, when the server and the client both support a private network tag carrying mode, extract a VPN private network tag from a session request message sent by the client after receiving the session request message, where the VPN private network tag is used as identification information for distinguishing different session requests.

In this embodiment of the present invention, the second negotiation module 1901 interacts with the client for mode negotiation message, and determines whether the opposite end supports the private network tag carrying mode by determining whether the private network tag carrying mode flag bit in the interacted mode negotiation message is set.

Further, in the embodiment of the present invention, the message processing module 1902 is specifically configured to extract a VPN private network tag from an MBZ field in the session request message; or, the server side extracts a VPN private network label from a newly added VPN private network label field in the session request message.

Further, in the embodiment of the present invention, the message processing module 1902 is further configured to determine whether the extracted identification information is completely the same as identification information of a currently created test session, and if so, refuse to create a new test session; otherwise, a new test session is created, and the extracted identification information is stored as the identification information of the created new test session to be used as the basis for removing the duplicate of the session request message and distinguishing the test messages in the test stage.

In an optional embodiment of the present invention, when the message processing module 1902 extracts a VPN private network tag from the session request message, it also extracts a source IP, a destination IP, a source port number, and a destination port number of the message, and cooperatively extracts the VPN private network tag as identification information for distinguishing different session requests. In this embodiment, the efficiency of the session request message deduplication query can be improved by using both the IP address and the port number as the identification information.

Further, in the embodiment of the present invention, in the test stage:

In summary, the server in this embodiment uses the VPN private network tag carried in the session request message as the identification information, so that different session requests can be distinguished, and the problem that the session requests and the test messages cannot be distinguished when IP addresses and port numbers are overlapped in L3VPN networking is perfectly solved.

In an eleventh embodiment of the present invention, there is provided a client for TWAMP session negotiation, comprising: a memory and a processor; the memory has stored therein computer instructions, which, upon execution by the processor, perform the method of:

carrying out negotiation of private network label carrying mode with a server;

Further, in this embodiment, the processor interacts with the server for the mode negotiation message, and determines whether the peer supports the private network tag carrying mode by determining whether a private network tag carrying mode flag bit in the interacted mode negotiation message is set.

Further, in the embodiment of the present invention, the processor multiplexes the field that must be zero MBZ in the session request message, and carries the VPN private network label information; or the client carries the VPN private network label information by adding a VPN private network label field in the session request message.

In a twelfth embodiment of the present invention, a server for TWAMP session negotiation is provided, which includes: a memory and a processor; the memory has stored therein computer instructions, which, upon execution by the processor, perform the method of:

negotiating a private network tag carrying mode with a client;

Further, in this embodiment, the processor, by executing the computer instructions, further executes the following method:

judging whether the extracted identification information is completely the same as the identification information of the currently established test session, if so, refusing to establish a new test session; otherwise, a new test session is created, and the extracted identification information is stored as the identification information of the created new test session to be used as the basis for the duplicate removal of the session request message and the differentiation of the test message in the test stage.

In an optional embodiment of the present invention, when the processor extracts the VPN private network tag from the session request message, the processor further extracts a source IP, a destination IP, a source port number, and a destination port number of the message, and cooperatively extracts the VPN private network tag as identification information for distinguishing different session requests. In this embodiment, the efficiency of the session request message deduplication query can be improved by using both the IP address and the port number as the identification information.

It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

The above-mentioned serial numbers of the embodiments of the present invention are merely for description and do not represent the merits of the embodiments.

Through the above description of the embodiments, those skilled in the art will clearly understand that the method of the above embodiments can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware, but in many cases, the former is a better implementation manner. Based on such understanding, the technical solutions of the present invention may be embodied in the form of a software product, which is stored in a storage medium (such as ROM/RAM, magnetic disk, optical disk) and includes instructions for enabling a terminal device (such as a mobile phone, a computer, a server, an air conditioner, or a network device) to execute the method according to the embodiments of the present invention.

The above description is only a preferred embodiment of the present invention, and not intended to limit the scope of the present invention, and all modifications of equivalent structures and equivalent processes, which are made by using the contents of the present specification and the accompanying drawings, or directly or indirectly applied to other related technical fields, are included in the scope of the present invention.

Claims

1. A bidirectional active measurement protocol TWAMP session negotiation method is characterized by comprising the following steps:

the client and the server negotiate a private network tag carrying mode;

2. The method of claim 1, wherein the client and the server perform negotiation of private network label carrying mode, comprising:

and the client side and the server side interact the mode negotiation message and judge whether the opposite side supports the private network label carrying mode by judging whether a private network label carrying mode flag bit in the interactive mode negotiation message is set or not.

3. The method of claim 2,

the mode negotiation message is: a communication mode negotiation message used in a control protocol negotiation stage;

the flag bit of the private network tag carrying mode is one or more bits which are not occupied in the mode field of the communication mode negotiation message.

4. The method of claim 3, wherein the communication mode negotiation messages used by the control protocol negotiation stage comprise: the server sends a Greeting message to the client, and the client feeds back a Set-Up-Response message to the server.

5. The method according to any one of claims 1 to 4,

the client carries the VPN private network label information by multiplexing the field which must be zero MBZ in the session request message;

or the client carries the VPN private network label information by adding a VPN private network label field in the session request message.

6. The method of claim 5,

the client adds a VPN private network label field between the MBZ in the session request message and a hash information check code HMAC field and carries VPN private network label information;

or, the client adds a VPN private network label field after the HMAC field in the session request message, and carries the VPN private network label information.

7. A bidirectional active measurement protocol TWAMP session negotiation method is characterized by comprising the following steps:

8. The method of claim 7, wherein the server and the client perform negotiation of private network label carrying mode, comprising:

and the server side and the client side interact the mode negotiation message, and judge whether the opposite side supports the private network label carrying mode by judging whether the private network label carrying mode flag bit in the interactive mode negotiation message is set or not.

9. The method of claim 8,

the mode negotiation message includes: a communication mode negotiation message used in a control protocol negotiation stage;

10. The method of claim 9, wherein the communication mode negotiation messages used by the control protocol negotiation stage comprise: the server sends a Greeting message to the client, and the client feeds back a Set-Up-Response message to the server.

11. The method according to any one of claims 7 to 10, wherein said extracting a VPN private network label from said session request message comprises:

the server side extracts a VPN private network label from an MBZ field in the session request message;

or, the server side extracts a VPN private network label from a newly added VPN private network label field in the session request message.

12. The method of claim 7, wherein said extracting a VPN private network label from said session request message further comprises:

and extracting a source IP, a destination IP, a source port number and a destination port number of the message, and cooperatively extracting the VPN private network label as identification information for distinguishing different session requests.

13. The method of claim 7 or 12, further comprising:

the server judges whether the extracted identification information is completely the same as the identification information of the currently established test session, and if so, refuses to establish a new test session; otherwise, a new test session is created, and the extracted identification information is stored as the identification information of the created new test session to be used as the basis for the duplicate removal of the session request message and the differentiation of the test message in the test stage.

14. A client for TWAMP session negotiation, comprising:

15. The client according to claim 14, wherein the first negotiation module is specifically configured to interact with a service end to perform mode negotiation, and determine whether an opposite end supports the private network tag carrying mode by determining whether a private network tag carrying mode flag bit in the interacted mode negotiation message is set.

16. The client of claim 15,

17. The client of claim 16, wherein the communication mode negotiation messages used by the control protocol negotiation stage comprise: the server sends a Greeting message to the client, and the client feeds back a Set-Up-Response message to the server.

18. The client according to any one of claims 14 to 17, wherein the message sending module is specifically configured to carry the VPN private network label information by multiplexing a field that is required to be zero MBZ in the session request message; or the client carries the VPN private network label information by adding a VPN private network label field in the session request message.

19. A server for TWAMP session negotiation, comprising:

20. The server-side of claim 19, wherein the second negotiation module is specifically configured to interact with a client for mode negotiation messages, and determine whether the opposite-side terminal supports the private network tag carrying mode by determining whether a private network tag carrying mode flag bit in the interacted mode negotiation messages is set.

21. The server according to claim 20,

22. The server according to claim 21, wherein the communication mode negotiation message used in the control protocol negotiation stage comprises: the server sends a Greeting message to the client, and the client feeds back a Set-Up-Response message to the server.

23. The server according to any one of claims 19 to 22, wherein the message processing module is specifically configured to extract a VPN private network label from an MBZ field in the session request message; or, the server side extracts a VPN private network label from a newly added VPN private network label field in the session request message.

24. The server according to claim 19, wherein the message processing module is further configured to extract a source IP, a destination IP, a source port number, and a destination port number of the message, and cooperate with the extracted VPN private network tag to serve as identification information for distinguishing different session requests.

25. The server according to claim 19 or 24, wherein the message processing module is further configured to determine whether the extracted identification information is completely the same as identification information of a currently created test session, and if so, refuse to create a new test session; otherwise, a new test session is created, and the extracted identification information is stored as the identification information of the created new test session to be used as the basis for the duplicate removal of the session request message and the differentiation of the test message in the test stage.

26. A client for TWAMP session negotiation, comprising: a memory and a processor; the memory has stored therein computer instructions, which, upon execution by the processor, perform the method of:

carrying out negotiation of private network label carrying mode with a server;

27. A server for TWAMP session negotiation, comprising: a memory and a processor; the memory has stored therein computer instructions, which, upon execution by the processor, perform the method of:

negotiating a private network tag carrying mode with a client;

28. The server according to claim 27, wherein the processor, by executing the computer instructions, further performs the method of: