Tunnel establishment method, device and storage medium

Abstract

The application discloses a tunnel establishment method, device and storage medium. The tunnel establishment method is applied to a path computation element (PCE) and comprises the following steps: tunnel association parameters to be issued are acquired; the tunnel association parameters are carried in a path computation element communication protocol (PCEP) message; the PCEP message carrying the tunnel association parameters is sent to a target path computation client (PCC), so that the PCC performs tunnel attribute configuration according to the tunnel association parameters. In the embodiment of the application, the tunnel association parameters can be carried in the PCEP message, at least one tunnel association parameter can be carried and issued to the PCC, the tunnel association parameters can be issued when the PCE initiatively creates the tunnel, the expansibility is high, and after the PCInitial tunnel is successfully created, the object can also be carried in a PCUpd message, so that the adding, deleting and updating operations of the tunnel association parameters are completed.

Description

Technical Field

[0001] This invention relates to the field of data communication, and more particularly to tunnel establishment methods, equipment, and storage media. Background Technology

[0002] Traditional routing methods with constraints based on topology collected at the device side can effectively address tunnel establishment needs within a single domain. However, due to the lack of access to cross-domain topology information, they often fail to meet the requirements for cross-domain tunnel establishment. In many scenarios, however, routing across large topologies and multiple domains is necessary. This necessitates a dedicated path computation device / component to collect network-wide and cross-domain topology information to calculate cross-domain paths. This dedicated routing device / component is called a Path Computation Element (PCE); while the traditional router device, acting as the requester, initiates routing requests to the PCE, becoming a Path Computation Client (PCC). The PCC and PCE communicate and establish PCEP sessions using the Path Computation Element Communication Protocol (PCEP).

[0003] With the development of SDN technology, PCE is no longer just a centralized path computing service component; it can also proactively perform dynamic planning and optimization of tunnels already established on PCC. PCE can directly send tunnel creation requests to PCC via the PCInitial (PathComputation LSP Initiate Request) message from PCEP. PCC then dynamically creates a tunnel based on the parameters specified in the PCInitial message. However, tunnels created via PCInitial only complete the tunnel creation process; policies and attributes associated with the tunnel cannot currently be extended and sent via the PCEP protocol. This presents significant challenges for engineering applications of tunnels created via PCInitial. Summary of the Invention

[0004] The main objective of this invention is to propose a tunnel establishment method, device, and storage medium, which aims to enable the distribution of tunnel-associated attributes when tunnel establishment is completed using the PCEP protocol.

[0005] In a first aspect, embodiments of the present invention provide a tunnel establishment method applied to a path calculation unit (PCE), comprising: obtaining tunnel association parameters to be sent; and carrying the tunnel association parameters in a PCEP message;

[0006] The PCEP message carrying the tunnel association parameters is sent to the target path calculation client (PCC), enabling the PCC to configure tunnel attributes based on the tunnel association parameters. According to the solution provided in this embodiment, by carrying tunnel association parameters in the PCEP message, at least one tunnel association parameter can be carried and sent to the PCC. This achieves the sending of association parameters when the PCE actively creates a tunnel, offering strong scalability. After the PCInitial tunnel is successfully created, the object can also be carried in the PCUpd message to complete the addition / deletion / update operations of the tunnel association parameters.

[0007] Secondly, this invention provides a tunnel establishment method applied to a path calculation client (PCC), comprising: receiving a PCEP message sent by a path calculation unit (PCE); parsing tunnel association parameters carried in the PCEP message; and configuring tunnel attributes according to the tunnel association parameters. According to the solution provided by this embodiment, by carrying tunnel association parameters in the PCEP message, at least one tunnel association parameter can be carried and sent to the PCC, realizing the sending of association parameters when the PCE actively creates a tunnel. This method has strong scalability. After the PCInitial tunnel is successfully created, the object can also be carried in the PCUpd message to complete the addition / deletion / update operation of the tunnel association parameters.

[0008] Thirdly, embodiments of the present invention also provide an apparatus, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the data processing method as described in the first aspect.

[0009] Fourthly, embodiments of the present invention also provide an apparatus, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the data processing method as described in the second aspect.

[0010] Fifthly, embodiments of the present invention also provide a communication system comprising the device as described in the third aspect and the device as described in the fourth aspect above.

[0011] In a sixth aspect, embodiments of the present invention also provide a computer-readable storage medium storing computer-executable instructions for performing the data processing method as described in the first aspect.

[0012] In a seventh aspect, embodiments of the present invention also provide a computer-readable storage medium storing computer-executable instructions for performing the data processing method as described in the second aspect.

[0013] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures particularly pointed out in the description, claims, and drawings. Attached Figure Description

[0014] Figure 1 This is a flowchart of the tunnel establishment method provided in Implementation Example 1;

[0015] Figure 2 This is a schematic diagram of the system architecture platform provided in Implementation Example 1;

[0016] Figure 3 This is a schematic diagram of the tunnel attribute information provided in Embodiment 1;

[0017] Figure 4 This is a schematic diagram of the tunnel association parameters when the parameter type is static routing, as provided in Example 1;

[0018] Figure 5 This is a schematic diagram of the tunnel association parameters when the parameter type is DSCP, as provided in Example 1;

[0019] Figure 6 This is a schematic diagram of tunnel association parameters when the parameter type is BFD detection, as provided in Example 1;

[0020] Figure 7 This is a flowchart of the tunnel establishment method provided in Example 2;

[0021] Figure 8 This is a schematic diagram showing that the tunnel attribute information provided in Embodiment 2 includes multiple tunnel-related parameters;

[0022] Figure 9 This is a schematic diagram of the internal modules of the device provided in Embodiment 3;

[0023] Figure 10 This is a schematic diagram of the internal modules of the device provided in Embodiment 4. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0025] It should be noted that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, or the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0026] In the following description, the use of suffixes such as "module," "part," or "unit" to denote elements is solely for the purpose of illustrative purposes and has no inherent meaning. Therefore, "module," "part," or "unit" may be used interchangeably.

[0027] Example 1

[0028] like Figure 1 As shown in the figure, this embodiment provides a flowchart of a tunnel establishment method, which is applied to the path calculation element (PCE). The method includes the following steps.

[0029] Step S110: Obtain the tunnel association parameters to be issued.

[0030] Specifically, this embodiment operates in the following environment: Figure 2 In the network shown, the Path Computation Element (PCE) serves as a centralized path calculation service component. Based on the current communication system's communication status and load, it dynamically plans and optimizes established and unestablished tunnels within the communication system. Based on the dynamic planning or optimization results, it determines the associated parameters of a specific tunnel. These tunnel associated parameters are then transmitted to the path calculation client (PCC) via the PCEP (Path Computation Element Communication Protocol). Figure 2 Node A is shown in the diagram. It should be understood that the embodiments of the present invention are not limited to the method of obtaining tunnel association parameters, and the path calculation unit PCE can also obtain tunnel association parameters by reading configuration or by receiving input.

[0031] Step S120: The tunnel association parameters are carried in the path calculation unit communication protocol PCEP message.

[0032] Specifically, tunnel association parameters can be carried in tunnel attribute information according to their type. The data structure corresponding to the tunnel attribute information in this embodiment is as follows: Figure 3As shown, the format follows the definition of PCEP Object in RFC5440, as follows: The Object-Class value is a newly defined value (requires IANA allocation; the illustrative value in this embodiment is 65535), the OT value is 1, and the Object Length (equivalent to the first length information) is the sum of the length of the object header and the lengths of all optional Length Type Parameters (TLVs) in the data bearer; one of the length type values ​​is used to carry a tunnel association parameter. Obviously, the Object Length can also be only the length of the object header, i.e., excluding any tunnel association parameters. In this case, the path calculation client PCC, as the receiver, receives such tunnel attribute information and will not perform any operation, or will send a response to the path calculation unit PCE indicating that the issued tunnel attribute information is incorrect.

[0033] The optional long type parameter (also referred to as Optional TLV, Optional Type-Length-Value) is variable-length and can carry one or more parameter TLVs associated with the tunnel. Each parameter TLV includes: the parameter type, parameter length, and data content of the tunnel-associated parameter. The parameter length identifies the length of the tunnel-associated parameter; it can include only the length of the tunnel-associated parameter, or it can be the total length of the parameter TLV carrying that tunnel-associated parameter (i.e., the total length including the parameter type, parameter length, and data content). In this embodiment, the parameter length includes the length of the length-type parameter TLV carrying the tunnel-associated parameter.

[0034] like Figures 4 to 6 Three different types of TLV are given. Figure 4 If the length type parameter TLV carries tunnel association parameters of type: static routing parameters, then the data content includes: IP address and network mask. Figure 4 The examples given are IPv4 versions of IP addresses and are for illustrative purposes only. They do not limit the version of the IP address. Figure 5 If the length type parameter TLV carries a tunnel association parameter of type DSCP (Differentiated Service Code Point), then the data content part includes: DSCP parameter value. Figure 6 If the length type parameter TLV carries tunnel association parameters of type: Bidirectional Forwarding Detection (BFD), then the data content part includes: BFD type, reserved words, detection period, and timeout multiple. Figures 4 to 6These are just a few examples; other tunnel-related parameters can also be similarly loaded into TLVs. The Path Calculation Unit (PCE) carries one or more length-type parameter TLVs in the tunnel attribute information as needed. TLVs can have different types and are used to carry the corresponding tunnel-related parameters. These are then sent to the corresponding PCC so that the PCC can perform appropriate configurations or updates based on the tunnel-related parameters.

[0035] S130, a PCEP message carrying tunnel association parameters is sent to the target path calculation client PCC, so that PCC can configure tunnel attributes according to the tunnel association parameters.

[0036] In this embodiment, tunnel attribute information can be carried in a PCInit message or a PCUpd message and sent to the target path calculation client PCC.

[0037] Specifically, the path calculation unit (PCE) carries tunnel attribute information in a PCInit message and sends it to the target path calculation client (PCC). Upon detecting the PCInit message, the PCC creates the corresponding tunnel and configures the appropriate parameters based on the tunnel attribute information. The path calculation unit (PCE) actively creates the tunnel and sends out the associated tunnel parameters, thus completing the process.

[0038] The path calculation unit (PCE) carries tunnel attribute information in a PCUpd message and sends it to the target path calculation client (PCC). The PCC detects the PCUpd message and updates the corresponding parameters based on the tunnel attribute information. After actively creating a tunnel, the PCE can add, delete, or update tunnel-related parameters by carrying tunnel attribute information in the PCUpd message.

[0039] The following will combine Figures 4 to 6 The three types of length type parameters (TLV) in the document provide a detailed explanation of the process for issuing tunnel association parameters.

[0040] Through such Figure 4 The TLV (Length Type Parameter) shown indicates that tunnels actively created by the PCE can be routed via static routes. RFC 8281 only defines that the PCE sends a tunnel creation message to the PCC via the PCInitiate message, but it doesn't specify how to direct user traffic to that tunnel after creation. Therefore, a directly created tunnel cannot handle service traffic and is meaningless, only wasting network bandwidth resources. In this embodiment, when the PCE sends the PCInitiate message, it can carry parameters such as... Figure 3 The tunnel attribute information shown carries, for example, the tunnel attribute information shown. Figure 4The TLV (Length Type Variable) parameter of the static route type defined shown contains the static route (IP address / mask information) set for the tunnel. Thus, when the tunnel is created, traffic is redirected through this static route, and user traffic destined for this static route network segment will be carried by the tunnel and sent to its corresponding destination.

[0041] Through such Figure 5 The length type parameter TLV shown indicates that tunnels actively created by the PCE can be routed via DSCP. Using static routing to route traffic through tunnels is coarse-grained and cannot provide different quality of service to different users. In this embodiment, when the PCE sends the PCInit message, it can carry parameters such as... Figure 3 The tunnel attribute information shown carries, for example, the tunnel attribute information shown. Figure 5 The definition shows the length type parameter TLV of the DSCP parameter type. This TLV sets the DSCP parameter value for the tunnel. Through this setting, the tunnel created will be bound to a specific DSCP value. On devices that support inbound tunneling based on the DSCP of IP packets, the operator's edge PE (provider edg) node can match inbound traffic according to the DSCP value in the IP packet. Service traffic with different DSCP values ​​will be matched to different tunnels. Tunnels with DSCP configured directly match SR-TE tunnels based on the DSCP value in the IP service traffic, allowing for more flexible matching based on service requirements. Figure 5 The DSCP parameter values ​​shown are used to deploy the SR-TE tunnel.

[0042] Through such Figure 6 The length type parameter TLV shown indicates that the PCE can quickly detect node or link failures and perform switching operations. The PCE can autonomously create SR-TE tunnels via PCInit messages. However, since SR-TE tunnels lack signaling, they cannot quickly detect and switch when a node or link on the path of the SR-TE tunnel fails. Therefore, in practical applications, BFD detection needs to be configured for SR-TE tunnels to ensure that in the event of a failure, the SR-TE tunnel can quickly switch to a backup path, achieving the engineering requirement of a fast switch within 50ms. Specifically, in this embodiment, the PCE can carry the following when sending the PCInit message: Figure 3 The tunnel attribute information shown carries, for example, the tunnel attribute information shown. Figure 6 The TLV (Length Type Variable) parameter defines the BFD detection type. This TLV sets the BFD type and specific BFD detection parameters for the tunnel: detection period and timeout multiplier. When the PCC receives this parameter, it will initiate BFD detection for the tunnel after tunnel creation, based on the BFD type, detection period, and timeout multiplier, thereby achieving rapid detection of the tunnel.

[0043] It should be understood that, in another embodiment of the present invention, the first length information in the tunnel attribute information may also only identify the second length of the tunnel association parameter carried; wherein, the second length may be the total length of the length type parameter TLV (i.e., the length of the Optional TLV) that carries the tunnel association parameter, or it may be the sum of the parameter lengths in the TLVs of the Optional TLV.

[0044] Example 2

[0045] like Figure 7 As shown in the figure, this embodiment provides a flowchart of a tunnel establishment method, which is applied to the path calculation client PCC. The method includes the following steps.

[0046] Step S210: Receive the PCEP message sent by the path calculation unit PCE.

[0047] In this embodiment, the PCEP message includes at least one of the PCInit message and the PCUpd message.

[0048] The PCInit message, also known as the PCInitiate message, is the message used by PCEP to initiate the establishment of a tunnel. The PCUpd message, also known as the PCEP Update message, is the PCEP update message.

[0049] Step S220: Parse the tunnel association parameters carried in the PCEP message.

[0050] In this embodiment, specifically, it includes: obtaining tunnel attribute information carried in the PCEP message; and then parsing tunnel association parameters from the tunnel attribute information.

[0051] Taking the PCInitiate message as an example, the parsing process of tunnel attribute information is as follows. When the path calculation client (PCC) receives the PCInitiate message, if it detects that it carries tunnel attribute information, it creates a new tunnel and reads that tunnel attribute information. The structure of the tunnel attribute information is as follows: Figure 3 As shown, this includes object type, OT, object length, and variable-length type parameters. The object length corresponds to the first length information, including the header length of the tunnel attribute information and the length of the variable-length type parameters. The header of the tunnel attribute information is the portion of the tunnel attribute information excluding the variable-length type parameters, including: object type, OT, Res, P, I, and object length. The unit of object length is bytes. Figure 3As shown, the header length of the tunnel attribute information is 32 bits, or 4 bytes. If the path calculation client PCC does not detect the tunnel attribute information, or if the length of the detected tunnel attribute information object is 4 bytes, it indicates that no tunnel-related parameters have been sent. The path calculation client PCC does not perform any operation, or returns the corresponding response code to inform the PCE that no tunnel-related parameters have been sent.

[0052] The specific process of parsing tunnel-related parameters from tunnel attribute information is as follows.

[0053] Specifically, taking the object length in the tunnel attribute information, which includes the header length of the tunnel attribute information and the length of variable-length type parameters, as an example, if the path calculation client PCC detects the tunnel attribute information and the object length in the tunnel attribute information is greater than 4, then it obtains the data block where the tunnel association parameters are located based on the object length. For example, if the object length in the tunnel attribute information is greater than 4 and is N (N is an integer greater than 4), it indicates that the tunnel association parameters are located from the 5th byte to the Nth byte in the tunnel attribute information.

[0054] like Figure 3 and Figure 4 As shown, if a tunnel association parameter is carried, and the type of this tunnel association parameter is a static route parameter, then the long type parameter TLV corresponding to the tunnel association parameter is 12 bytes. The object length in the tunnel attribute information detected by PCC at this time is 12 + 4 = 16 bytes. Therefore, bytes 5 to 16 represent the location of the tunnel association parameter. If the parameter type read from the TLV is the number corresponding to a static route, then the end of the tunnel association parameter can be located based on the parameter length. Based on the structure corresponding to the static route (such as...),... Figure 4 As shown (in the image), the data content corresponding to the tunnel's associated parameters can be parsed out: IP address and network mask. It should be noted that... Figure 4 The examples given are IPv4 versions of IP addresses and are for illustrative purposes only. They do not limit the version of the IP address.

[0055] like Figure 3 and Figure 5 As shown, if a tunnel association parameter is carried, and the type of this tunnel association parameter is a DSCP parameter, then the long type parameter TLV corresponding to the tunnel association parameter is 8 bytes. The object length in the tunnel attribute information detected by PCC at this time is 8 + 4 = 12 bytes. Therefore, bytes 5 to 12 represent the location of the tunnel association parameter. If the parameter type read from the TLV is the number corresponding to DSCP, then the end of the tunnel association parameter can be located based on the parameter length, according to the structure corresponding to DSCP (such as...). Figure 5 As shown), the data content corresponding to the tunnel association parameters can be parsed out: DSCP parameter values.

[0056] like Figure 3 and Figure 6 As shown, if a tunnel association parameter is carried, and the type of this tunnel association parameter is BFD detection, then the long type parameter TLV corresponding to the tunnel association parameter is 12 bytes. The object length in the tunnel attribute information detected by PCC is 12 + 4 = 16 bytes. Therefore, bytes 5 to 16 represent the location of the tunnel association parameter. If the parameter type read from the TLV is the number corresponding to BFD detection, then the end of the tunnel association parameter can be located based on the parameter length. Based on the structure corresponding to BFD detection (such as...),... Figure 6 As shown, the data content corresponding to the tunnel association parameters can be parsed out: the type of BFD and the specific BFD detection parameters; among which, the BFD detection parameters include: detection period and timeout multiple.

[0057] Step S230: Configure tunnel attributes based on tunnel association parameters.

[0058] Specifically, if the path calculation client PCC receives tunnel association parameters carried in the PCInit message, it configures the corresponding attribute information according to the tunnel association parameters after tunnel creation. If the path calculation client PCC receives tunnel association parameters carried in the PCUpd message, it updates the corresponding attribute information according to the tunnel association parameters. For example, if the tunnel association parameter received by the path calculation client PCC is a static route parameter, it sets up traffic redirection for the tunnel based on the IP address and network mask, so that user traffic destined for the static route network segment is carried by the tunnel and sent to the corresponding destination. For example, if the tunnel association parameter received by the path calculation client PCC is a DSCP parameter, the tunnel created this time will be bound to the given DSCP value parameter, so that on devices that support DSCP inbound tunnels based on IP packets, the operator's edge PE (provider edg) node can match inbound traffic according to the DSCP value in the IP packet, and service traffic with different DSCP values ​​will be matched to different tunnels. Tunnels with DSCP set directly match SR TE tunnels according to the DSCP value in the IP service traffic, which can more flexibly match services through such Figure 5 The DSCP parameter values ​​shown are used to deploy SR-TE tunnels. For example, if the tunnel association parameter received by the path calculation client PCC is BFD detection, then BFD detection is enabled for the tunnel based on the type, detection period, and timeout multiplier of the BFD, thereby achieving the purpose of fast detection for the tunnel.

[0059] In this embodiment, the tunnel attribute information in a single PCInit message and PCUpd message can also carry multiple sets of tunnel association parameters. The following example, where the tunnel attribute information simultaneously carries static routing and BFD detection, illustrates the process of distributing tunnel association parameters.

[0060] The path calculation unit (PCE) obtains the IP address and network mask of the static route to be set, and generates a path like... Figure 4 The type shown is the long type parameter TLV of the static route; obtain the type, detection period and timeout multiple of the BFD to be set, and generate a parameter in the form of... Figure 6 The type shown is the long type parameter TLV for BFD detection. Then it is placed as follows: Figure 3 The optional long type parameters (Optional TLVs) portion of the tunnel attribute information is shown. In this embodiment, the parameter length of the tunnel attribute information (equivalent to the first length information) is the sum of the length of the tunnel attribute header and the length of the optional long type parameters (Optional TLVs). In this example, the parameter length of the tunnel attribute information is 28 (4+12+12) bytes; the parameter length corresponding to the long type parameter TLV of type static routing parameter (e.g., Figure 4 The parameter length of the long type parameter TLV of type BFD detection is 12 (as shown). Figure 6 (As shown) is 12. Then, the path calculation unit PCE carries this tunnel attribute information in the PCInit message and sends it to the target path calculation client PCC through the PCEP protocol.

[0061] The path calculation client PCC receives the PCInit message, creates a tunnel, and extracts the tunnel attribute information. Based on the 28-byte length of the tunnel attribute information parameters, bytes 5 through 28 contain associated parameter information. Locating the 5th byte of the tunnel attribute information, the first long type parameter (TLV) is identified as a static route parameter, and its length is 12 bytes. Based on... Figure 4 The structure shown allows extraction of the corresponding attributes: IP address and network code, enabling appropriate settings for the tunnel. Then, based on the first long type parameter's length of 12, locating the 17th byte of the tunnel attribute information, we can obtain the second long type parameter TLV's type as BFD detection, and since the second long type parameter's length is also 12, according to... Figure 6 The structure shown allows for the extraction of relevant attributes: BFD type, detection period, and timeout multiplier, enabling the corresponding settings for the tunnel. The newly created tunnel thus possesses two attributes: it can be routed via static routing, and it can perform BFD detection based on the received parameters (BFD type, detection period, and timeout multiplier).

[0062] It should be understood that for an established tunnel, if the path calculation unit needs to add / delete / update the relevant tunnel parameters during dynamic planning or optimization, the tunnel attribute information can be loaded as described above and sent through the PCUpd message so that the relevant parameters of the target tunnel can be added / deleted / updated accordingly.

[0063] In this embodiment, the first length information of the tunnel attribute information (i.e., such as...) Figure 3 The object length in the header (in the text) represents the overall length of the tunnel attribute information, including the header and the length of optional long type parameters. The parameter length within each long type parameter represents the overall length of the long type parameter, such as... Figure 8 As shown, this includes: parameter type, parameter length, and the size of the data content in bytes. The path calculation client PCC receives the PCInit or PCUpd message, obtains the tunnel attribute information, and refers to... Figure 8 The first length information (i.e., ...) can be read from the header of the tunnel attribute information. Figure 3 The first length information is the total length of the tunnel attribute information. Based on this first length information, the length of the optional long type parameters (Optional TLVs) in the tunnel attribute information can be determined (i.e., the second length of the tunnel-related parameters carried by the tunnel attribute information). Based on this second length, the position of the tunnel-related parameters in the tunnel attribute information can be located, and the tunnel-related parameters can be parsed out. Specifically, the starting position of the tunnel-related parameters is obtained, and the parameter type and parameter length of the first long type parameter TLV are read. The data content of the first long type parameter is read according to the current parameter type, and the next long type parameter TLV is located according to the current parameter length. Based on the current parameter length and the position of the current long type parameter TLV, it is determined whether the data carrying area of ​​the tunnel attribute information has been read completely. If it has not been read completely, the next long type parameter is read until the end of the data carrying area pointed to by the first length information is reached.

[0064] In other embodiments of the present invention, the first length information of the tunnel attribute information only identifies the length of the optional long type parameters (Optional TLVs) carrying the tunnel-related parameters, excluding the header length of the tunnel attribute information; the parameter length in each long type parameter only represents the length of the tunnel-related parameters carried (i.e., Figure 8 The length of the data content (in the text). For example, such as... Figure 4 The parameter shown is a long type parameter (TLV) for static routing parameters, and its length is 8 bytes; for example... Figure 5 The parameter shown is a long type parameter TLV of type DSCP, and its length is 4 bytes; for example... Figure 6The long type parameter BFD detection shown indicates that the long type parameter TLV has a parameter length of 8 bytes. Therefore... Figures 4 to 6 The headers (parameter type and length) of the long parameters shown are both 2 bytes. Therefore, the path calculation client PCC receives the PCInit or PCUpd message, retrieves the tunnel attribute information, and refers to... Figure 8 The first length information (i.e., ...) can be read from the header of the tunnel attribute information. Figure 3 The first length information is the total length of the variable-length type parameters of the tunnel attribute information (i.e., the length of the Optional TLV), which is the second length of the tunnel-related parameters carried by the tunnel attribute information. Based on this second length, the position of the tunnel-related parameters in the tunnel attribute information can be located, and the tunnel-related parameters can be parsed. Specifically, the starting position of the tunnel-related parameters is obtained, and the parameter type and parameter length of the first long type parameter TLV are read. The data content of the first long type parameter is read according to the current parameter type, and the next long type parameter TLV is located according to the current parameter length. The position of the current long type parameter TLV is used to determine whether the data carrying area of ​​the tunnel attribute information has been completely read. If it has not been completely read, the next long type parameter is read until the end of the data carrying area pointed to by the first length information is reached.

[0065] Example 3

[0066] Based on the tunnel establishment method proposed in the foregoing embodiments, Embodiment 3 of the present invention proposes a first device, which is used to send tunnel association parameters to the target path calculation client PCC.

[0067] Reference Figure 9 The internal modules of the first device 100 in this embodiment include: an acquisition unit 110, a loading unit 120, and a first sending unit 130. The acquisition unit 110 is used to acquire tunnel association parameters to be sent. The loading unit 120 is used to carry the tunnel association parameters in a PCEP message. For example, depending on the type of the tunnel association parameters, the tunnel association parameters are carried in tunnel attribute information; and the tunnel attribute information is carried in a PCInit message or a PCUpd message. The first sending unit 130 is used to send the PCEP message carrying the tunnel association parameters to the target path calculation client PCC, so that the PCC configures tunnel attributes according to the tunnel association parameters.

[0068] Specifically, the first device 100 in this embodiment operates as follows: Figure 2In the network shown, the path calculation unit (PCE) dynamically plans and optimizes existing and non-existing tunnels in the communication system based on the current communication status and load. It then determines the associated parameters of a specific tunnel based on the dynamic planning or optimization results. These tunnel associated parameters are sent to the path calculation client (PCC) via the PCEP protocol. Figure 2 Node A is shown in the diagram. It should be understood that the embodiments of the present invention do not limit the method by which the acquisition unit 110 acquires tunnel association parameters, and the acquisition unit 110 of the first device 100 may also acquire tunnel association parameters by reading configuration or by receiving input.

[0069] The loading unit 120 of the first device 100 carries the tunnel association parameters to be sent into the tunnel attribute information. The data structure corresponding to the tunnel attribute information in this embodiment is as follows: Figure 3 As shown, the format follows the definition of PCEP Object in RFC5440, as follows: The Object-Class value is a newly defined value (requires IANA allocation; the illustrative value in this embodiment is 65535), the OT value is 1, and the Object Length (equivalent to the first length information) is the sum of the length of the object header and the lengths of all optional length-type parameters (TLVs) carried afterward; one of the length-type values ​​is used to carry a tunnel association parameter. The optional length-type parameters (also referred to as Optional TLVs, Optional Type-Length-Values) are variable-length and can carry one or more tunnel-associated parameter TLVs. Each parameter TLV includes: the parameter type, parameter length, and data content of the tunnel association parameter. The parameter length identifies the length of the tunnel association parameter; it can include only the length of the tunnel association parameter or the total length of the parameter TLV carrying that tunnel association parameter (i.e., the total length including the parameter type, parameter length, and data content of the tunnel association parameter).

[0070] The device unit 120 of the first device 100 generates a corresponding type of TLV based on the type of the tunnel association parameters to be issued, and fills it into the optional long type parameters (Optional TLVs). For example... Figures 4 to 6 Three different types of TLV are given. Figure 4 If the length type parameter TLV carries tunnel association parameters of type: static routing parameters, then the data content includes: IP address and network mask. Figure 4 The examples given are IPv4 versions of IP addresses and are for illustrative purposes only. They do not limit the version of the IP address. Figure 5If the length type parameter TLV carries a tunnel association parameter of type DSCP (Differentiated Service Code Point), then the data content part includes: DSCP parameter value. Figure 6 If the length type parameter TLV carries tunnel association parameters of type BFD detection, then the data content includes: BFD type, reserved word, detection period, and timeout multiple. Figures 4 to 6 These are just a few examples; other tunnel-related parameters can also be loaded into TLVs. The device unit 120 of the first device 100, as needed, carries one or more length-type parameter TLVs in the tunnel attribute information. The TLVs can have different types and are used to carry the corresponding tunnel-related parameters, which are then sent to the corresponding PCC so that the PCC can perform corresponding configuration or updates based on the tunnel-related parameters.

[0071] In this embodiment, the PCEP message includes at least one of a PCInit message and a PCUpd message. The device unit 120 of the first device 100 carries tunnel attribute information in the PCInit message and sends it to the target path calculation client PCC, so that the PCC detects the PCInit message, creates the corresponding tunnel, and configures the corresponding parameters according to the tunnel attribute information. The device unit 120 of the first device 100 carries tunnel attribute information in the PCUpd message and sends it to the target path calculation client PCC, so that the PCC detects the PCUpd message and updates the corresponding parameters according to the tunnel attribute information.

[0072] The first device 100 also includes a first receiving unit 210 (not shown), used to receive response information returned by the target path calculation client PCC.

[0073] Example 4

[0074] Based on the tunnel establishment method proposed in the foregoing embodiments, Embodiment 4 of the present invention proposes a second device for receiving and processing tunnel association parameters issued by the first device.

[0075] Reference Figure 10 The internal modules of the second device 200 in this embodiment include: a second receiving unit 210, a parsing unit 220, and a configuration unit 230. The second receiving unit 210 is used to receive PCEP messages sent by the first device. In this embodiment, the PCEP message includes at least one of a PCInit message and a PCUpd message. The parsing unit 220 is used to parse the tunnel association parameters carried in the PCEP message. The configuration unit 230 is used to configure or update corresponding attributes according to the tunnel association parameters.

[0076] The second receiving unit 210 of the second device 200 receives the PCInit message. If the parsing unit 220 detects that it carries tunnel attribute information, it creates a new tunnel and reads the tunnel attribute information. The structure of the tunnel attribute information is as follows: Figure 3 As shown, this includes object type, OT, object length, and variable-length type parameters. The object length corresponds to the first length information, including the header length of the tunnel attribute information and the length of the variable-length type parameters. The header of the tunnel attribute information is the portion of the tunnel attribute information excluding the variable-length type parameters, including: object type, OT, Res, P, I, and object length. The unit of object length is bytes. Figure 3 As shown, the header length of the tunnel attribute information is 32 bits, or 4 bytes. If the path calculation client PCC does not detect the tunnel attribute information, or if the length of the detected tunnel attribute information object is 4 bytes, it indicates that no tunnel-related parameters have been sent. The path calculation client PCC does not perform any operation, or returns the corresponding response code to inform the PCE that no tunnel-related parameters have been sent.

[0077] Specifically, if the parsing unit 220 of the path calculation client PCC detects tunnel attribute information, and the object length in the tunnel attribute information is greater than 4, then the data block containing the tunnel association parameters is obtained based on the object length (equivalent to the first length information). For example, if the object length in the tunnel attribute information is greater than 4, specifically N (N is an integer greater than 4), it indicates that the tunnel association parameters are located from the 5th byte to the Nth byte in the tunnel attribute information. This first length information is the total length of the tunnel attribute information, and based on this first length information, the length of the optional long type parameters (Optional TLVs) in the tunnel attribute information (i.e., the second length of the tunnel association parameters carried by the tunnel attribute information) can be determined.

[0078] The second length allows for the location of tunnel-related parameters within the tunnel attribute information, and the tunnel-related parameters are then parsed. Specifically, the starting position of the tunnel-related parameters is obtained, and the parameter type and length of the first long-type parameter TLV are read. The data content of the first long-type parameter is read based on the current parameter type, and the next long-type parameter TLV is located based on the current parameter length. The position of the current parameter length and the current long-type parameter TLV determines whether the data carrying area of ​​the tunnel attribute information has been completely read. If not, the next long-type parameter is read until the end of the data carrying area pointed to by the first length information is reached.

[0079] After the parsing unit 220 completes the parsing operation, the configuration unit 230 performs the corresponding configuration according to the type and data content of the tunnel-related parameters.

[0080] The second device 100 also includes a second receiving unit 220 (not shown), used to return response information to the first device 100.

[0081] Example 5

[0082] Based on the tunnel establishment method and the first device 100 and the second device 200 proposed in the foregoing embodiments, Embodiment 5 of the present invention proposes a communication system. This system includes a first device 100 and multiple second devices 200.

[0083] The first device 100 is operating as follows: Figure 2 In the communication system shown, the first device 100 is equivalent to Figure 2 In the PCE, the second device 200 is equivalent to Figure 2 Node A or Node B in the communication system. The first device 100, acting as a path calculation unit (PCE), dynamically plans and optimizes established or unestablished tunnels in the communication system based on the current communication status and load. Based on the dynamic planning or optimization results, it determines the associated parameters of a specific tunnel. The first device 100 obtains the tunnel associated parameters to be sent, carries the tunnel attribute information in a PCEP message, and sends the PCEP message carrying the tunnel associated parameters to the second device. Specifically, for example, the first device 100 obtains the tunnel associated parameters to be sent, carries the tunnel associated parameters in tunnel attribute information according to the type of tunnel associated parameters, and then carries the tunnel attribute information in a PCInit message or a PCUpd message, sending it to the second device 200 via the PCEP protocol.

[0084] The second device 200 receives a PCEP message, parses out the tunnel association parameters carried in the PCEP message, and configures the corresponding tunnel attributes according to the parsed tunnel association parameters. For example, the second device 200 receives a PCInit message or a PCUpd message, obtains tunnel attribute information, and parses out the tunnel association parameters from the tunnel attribute information. The specific parsing process is as follows: obtain the first length information in the tunnel attribute information; obtain the second length of the tunnel association parameters carried by the tunnel attribute information according to the first length information; obtain the data carrying area of ​​the tunnel attribute information according to the second length; traverse the data carrying area and parse out the tunnel association parameters according to the parameter type and parameter length. If a PCInit message is received, the corresponding attributes are configured according to the parsed tunnel association parameters; if a PCUpd message is received, the corresponding attributes are added / deleted / updated according to the parsed tunnel association parameters.

[0085] It will be understood by those skilled in the art that all or some of the steps, systems, or apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software may be distributed on a computer-readable medium, which may include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer. Furthermore, it is well known to those skilled in the art that communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

Claims

1. A tunnel establishment method, applied to a path calculation unit (PCE), comprising: Obtain the tunnel association parameters to be issued, wherein, when the parameter type of the tunnel association parameter is a static routing parameter, the data content of the tunnel association parameter includes the IP address and network mask; or, when the parameter type of the tunnel association parameter is a Differential Service Code Point (DSCP) parameter, the data content of the tunnel association parameter includes the DSCP parameter value; or, when the parameter type of the tunnel association parameter is a Bidirectional Forwarding Detection (BFD), the data content of the tunnel association parameter includes the BFD type, detection period, and timeout multiplier. The tunnel association parameters are carried in the PCEP (Plan Path Calculation Unit) communication protocol message. The PCEP message carrying the tunnel association parameters is sent to the target path calculation client PCC, so that the PCC configures tunnel attributes according to the tunnel association parameters.

2. The tunnel construction method according to claim 1, characterized in that, The tunnel association parameters are carried in the PCE message, including: Based on the type of the tunnel association parameters, the tunnel association parameters are carried in the tunnel attribute information; The tunnel attribute information is carried in the PCEP message.

3. The tunnel construction method according to claim 2, characterized in that, The tunnel attribute information carries a first length information, which is used to identify the sum of the header length of the tunnel attribute information and the second length of the tunnel association parameters carried thereon, or the first length information is used to identify the second length of the tunnel association parameters carried thereon.

4. The tunnel construction method according to claim 2, characterized in that, The tunnel attribute information can carry at least one of the tunnel association parameters. For each tunnel association parameter, the content carried includes: the parameter type of the tunnel association parameter, the parameter length of the tunnel association parameter, and the data content of the tunnel association parameter.

5. The tunnel construction method according to claim 1, characterized in that, The PCEP message includes at least one of the following: PCInit message and PCUpd message.

6. A tunnel establishment method, applied to a path calculation client (PCC), comprising: Receive PCEP messages sent by the path calculation unit (PCE); The tunnel association parameters carried in the PCEP message are parsed out. When the parsed tunnel association parameter is a static routing parameter, the corresponding data content includes the IP address and network mask; or, when the parsed tunnel association parameter is a Differential Service Code Point (DSCP) parameter, the corresponding data content includes the DSCP parameter value; when the parsed tunnel association parameter is a Bidirectional Forwarding Detection (BFD) parameter, the corresponding data content includes: BFD type, detection period, and timeout multiplier. Configure tunnel attributes based on the tunnel association parameters.

7. The tunnel construction method according to claim 6, characterized in that, The method for parsing tunnel association parameters from the PCEP message includes: Obtain the tunnel attribute information carried in the PCEP message; The tunnel association parameters are parsed from the tunnel attribute information.

8. The tunnel construction method according to claim 7, characterized in that, The method for parsing tunnel association parameters from the tunnel attribute information includes: Obtain the first length information from the tunnel attribute information; The second length of the tunnel association parameter carried by the tunnel attribute information is obtained based on the first length information; The tunnel association parameters are parsed based on the second length.

9. The tunnel construction method according to claim 8, characterized in that, The tunnel association parameters parsed based on the second length include: The data carrier area for obtaining the tunnel attribute information based on the second length; Traverse the data carrying area and parse out the tunnel association parameters according to the parameter type and parameter length.

10. The tunnel construction method according to claim 6, characterized in that, The PCEP message includes at least one of the following: PCInit message and PCUpd message.

11. A communication device, comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor, when executing the computer program, implements the tunnel establishment method as described in any one of claims 1 to 5.

12. A communication device, comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor, when executing the computer program, implements the tunnel establishment method as described in any one of claims 6 to 10.

13. A communication system comprising the device of claim 11 and the device of claim 12.

14. A computer-readable storage medium storing computer-executable instructions for performing the tunnel establishment method as described in any one of claims 1 to 5.

15. A computer-readable storage medium storing computer-executable instructions for performing the tunnel establishment method as described in any one of claims 6 to 10.

Images