Service path establishment method, device, and storage medium

Abstract

Provided in the embodiments of the present application are a service path establishment method, an electronic device, and a computer-readable storage medium. The method comprises: a first node receiving a first message sent by a second node, wherein the first message carries path information and a Metric object, and the Metric object carries a path delay Metric value; and the first node performing path configuration on the basis of the path information and the path delay Metric value.

Description

Service path establishment method, device and storage medium

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to the Chinese patent application filed with the China Patent Office on February 8, 2024, with application number 202410178120.4 and invention name “Business Path Establishment Method, Device and Storage Medium”. The entire contents of the Chinese patent application are incorporated herein by reference. Technical Field

[0003] The present application relates to the field of communication technology, and in particular to a service path establishment method, an electronic device, and a computer-readable storage medium. Background Art

[0004] Currently, some customer-layer service signals carried over the transmission network have clear requirements for transmission delay. For example, when power protection relay system signals are carried over the transmission network, to ensure the normal switching of the power protection relay system (such as the activation of differential protection), it is clearly required that the forward and reverse path delays of the transmitted signal, as well as the difference in the two-way path delay, cannot exceed the corresponding delay limits. Specifically, in some scenarios, the forward path delay is required to be no more than 15 milliseconds, the reverse path delay is also required to be no more than 15 milliseconds, and the two-way path delay difference is required to be no more than 200 microseconds.

[0005] How to support the transmission of delay parameters in messages to support the creation of such precise time control services is a technical problem that needs to be solved.

[0006] Summary of the Invention

[0007] In a first aspect, an embodiment of the present application provides a service path establishment method, which is applied to a first node. The method includes: receiving a first message sent by a second node, the first message carrying path information and a metric object, the metric object carrying a path delay metric value; and performing path configuration according to the path information and the path delay metric value.

[0008] In a second aspect, an embodiment of the present application provides a service path establishment method, which is applied to a second node. The method includes: sending a first message to a first node, the first message carrying path information and a metric object, the metric object carrying a path delay metric value, so that the first node performs path configuration according to the path information and the path delay metric value.

[0009] In a third aspect, an embodiment of the present application provides an electronic device, comprising: one or more processors; a memory on which one or more programs are stored, and when the one or more programs are executed by the one or more processors, the one or more processors implement the service path establishment method described in the first aspect above or the service path establishment method described in the second aspect above.

[0010] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the service path establishment method described in the first aspect or the service path establishment method described in the second aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The accompanying drawings are used to provide a further understanding of the technical solution of the present application and constitute a part of the specification. Together with the embodiments of the present application, they are used to explain the technical solution of the present application and do not constitute a limitation on the technical solution of the present application.

[0012] FIG1 is a schematic diagram of an SDN controller hierarchical architecture provided by an embodiment of the present application;

[0013] FIG2 is a schematic diagram of a PCEP network architecture provided in an embodiment of the present application;

[0014] FIG3 is a flow chart of a method for establishing a service path according to an embodiment of the present application;

[0015] FIG4 is a schematic diagram of the format of a Metric object provided in an embodiment of the present application;

[0016] FIG5a is a schematic diagram of the format of a Metric object provided in an embodiment of the present application;

[0017] FIG5 b is a schematic diagram of the format of a Metric object provided in an embodiment of the present application;

[0018] FIG5c is a schematic diagram of the format of a Metric object provided in an embodiment of the present application;

[0019] FIG6 is a flow chart of a method for establishing a service path according to an embodiment of the present application;

[0020] FIG7 is a flow chart of a method for establishing a service path according to an embodiment of the present application;

[0021] FIG8 is a flow chart of a method for establishing a service path according to an embodiment of the present application;

[0022] FIG9 is a schematic diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0023] In order to enable those skilled in the art to better understand the technical solution of the present application, the technical solution provided by the present application is described in detail below with reference to the accompanying drawings.

[0024] Example embodiments will be described more fully hereinafter with reference to the accompanying drawings, but the described example embodiments may be embodied in different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thorough and complete and will fully convey the scope of this application to those skilled in the art.

[0025] As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items.

[0026] The terms used herein are used only to describe specific embodiments and are not intended to limit this application. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms, unless the context clearly indicates otherwise. It will also be understood that when the terms "comprising" and / or "made of" are used in this specification, they specify the presence of features, wholes, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, wholes, steps, operations, elements, components, and / or groups thereof.

[0027] In the following description, reference is made to “some embodiments”, which describes a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0028] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by those of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and the present application, and will not be interpreted as having an idealized or overly formal meaning, unless clearly defined in the examples of the present application.

[0029] To facilitate a better understanding of the solutions of the embodiments of the present application, the following first introduces the terms involved in the present application.

[0030] Management and Control System: The Management Control Continuum (MCC) integrates essentially identical management and control functions to achieve unified management and control of transmission resources, providing integrated management and control services to upper-layer users. Software-defined Network (SDN) controllers, element management systems (EMS), network management systems (NMS), and control planes are all examples of a management and control system. Functional modules within a management and control system provide functional services through interfaces. Connection scheduling is a fundamental function of a management and control system.

[0031] Please refer to Figure 1, which is a schematic diagram of an SDN controller hierarchical architecture provided in an embodiment of the present application. In the SDN controller (Controller) hierarchical architecture, as shown in Figure 1, a client layer and service layer relationship is formed between the upper and lower layer Controllers; the client layer Controller and the service layer Controller interact through the service context (Server Context) and the client context (Client Context). Each Controller can create multiple Client Contexts, at least one Server Context and one Administrative Context (Administrative Context). The administrative context provides support information for the administrator to manage and control the controller, and exercises the administrator role within the controller, including maintaining the life cycle of the client context and service context.

[0032] The Path Computation Element Communication Protocol (PCEP) addresses these issues by centralizing path calculation within the network, allowing computational elements to independently calculate Multi-Protocol Label Switching (MPLS) and Segment Routing IPv6 (SRv6) paths based on the IPv6 forwarding plane. The core concept of PCEP's centralized computation is highly compatible with SDN technology. Therefore, PCEP is also being considered as a solution for migrating MPLS networks to SDN networks.

[0033] A typical PCEP network consists of the following parts:

[0034] Path Computation Element (PCE): A network entity that provides path computation services to network devices. It can perform path computation within an area and calculate complete LSP paths in complex network environments.

[0035] Path Computation Client (PCC): Requests the PCE to perform path calculation and establishes LSPs based on the path information returned by the PCE.

[0036] PCEP session: A session established between a PCC and a PCE, or between two PCEs. In a stateful PCEP session, the PCC reports all LSP information within the network to the PCE. In addition to providing path calculation services, the PCE can also create, delete, and optimize LSPs within the domain to maximize the allocation and use of network resources.

[0037] The PCC and PCE exchange PCEP messages to establish and maintain sessions, calculate and update paths, and more. A PCEP message consists of a PCEP header and a variable-length message body, which consists of one or more objects. The main content of a PCEP message is carried in different objects.

[0038] PCEP messages include the following types:

[0039] Open message: used to start a PCEP session.

[0040] Keepalive message: PCEP session keepalive message.

[0041] PCReq (Path Computation Request) message: a message sent by the PCC to the PCE requesting path computation.

[0042] PCRep (Path Computation Reply) message: a path computation reply message sent by the PCE to the PCC.

[0043] PCNtf (Path Computation Notification) message: an event notification message sent by the PCC to the PCE or by the PCE to the PCC.

[0044] PCErr (Path Computation Error) message: an error notification message sent by the PCC to the PCE or by the PCE to the PCC.

[0045] Close message: used to close a PCEP session.

[0046] PCRpt (Path Computation State Report) message: a message sent by the PCC to the PCE to report the current status of the LSP.

[0047] PCUpd (Path Computation Update Request) message: a PCEP message sent by the PCE to the PCC to update LSP information.

[0048] PCInitiate (Path Computation Initiate Request) message: a PCEP message sent by the PCE to the PCC to create an LSP.

[0049] Please refer to Figure 2, which is a schematic diagram of a PCEP network architecture provided in an embodiment of the present application. The PCEP network shown in Figure 2 includes network nodes R1, R2, R3, R4, and R5, and also includes a controller. Assuming that a service connection needs to be established between R1 and R4, the head node R1 sends a request path calculation message to the controller through a PCEP session; the controller calculates a path that meets the constraint conditions to reach the destination node R4 based on a constraint-based path priority algorithm, and after successfully calculating the path, returns a path calculation response message to R1 through the PCEP session; after receiving the path calculation response message, R1 establishes an LSP path based on the response message. For bidirectional services, the tail node R4 can also send a request path calculation message to the controller through a PCEP session; the controller calculates a path that meets the constraint conditions to reach the destination node R1 based on a constraint-based path priority algorithm, and after successfully calculating the path, returns a path calculation response message to R4 through the PCEP session; after receiving the path calculation response message, R4 establishes an LSP path based on the response message. Here, R1 and R4 can both be referred to as PCCs, and the controller can be referred to as PCEs. In addition, for the convenience of description, the path from R1 to R4 can be called the forward path, and the path from R4 to R1 can be called the reverse path. R1 can also be called the A end, and R4 can also be called the Z end.

[0050] The network nodes described in the embodiments of this application can be physical nodes or logical nodes. A physical node is a network device such as a switch or router. A logical node is a functional module within a network device, such as a virtual switch or virtual router deployed within the network device.

[0051] At present, some customer-layer service signals carried by the transmission network have clear requirements for transmission delay. For example, when the power protection relay system signal is carried by the transmission network, in order to ensure the normal switching of the power protection relay system (such as starting differential protection), it is clearly required that the forward and reverse path delays of the transmission signal and the two-way path delay difference cannot exceed the corresponding delay upper limit. Specifically, in some scenarios, the forward path delay is required to be no more than 15 milliseconds, the reverse path delay is also required to be no more than 15 milliseconds, and the two-way path delay difference is required to be no more than 200 microseconds. How to support the transmission of delay parameters in the message to support the creation of such precise time control services is a technical problem that needs to be solved.

[0052] In view of this, embodiments of the present application provide a service path establishment method, an electronic device, and a computer-readable storage medium, which enable messages to support the carrying of path delay information to configure the service path based on the path delay information.

[0053] Please refer to FIG3 , which is a flowchart of a service path establishment method provided in an embodiment of the present application. The method is applied to a first node. As shown in FIG3 , the method includes the following steps S101 and S102:

[0054] Step S101: Receive a first message sent by a second node, where the first message carries path information and a metric object, and the metric object carries a path delay metric value.

[0055] Step S102: Perform path configuration according to the path information and the path delay metric value.

[0056] Please refer to Figure 4, which is a schematic diagram of the format of a Metric object provided in an embodiment of the present application. As shown in Figure 4, the Metric object includes the following fields:

[0057] Reserved: Reserved field, currently undefined, filled with all 0s in the message;

[0058] Flags: flag bit;

[0059] C: C flag, indicating computed metric;

[0060] B: B flag, indicating the boundary (Bound);

[0061] T: T flag, indicating the measurement type through the value;

[0062] Metric Value: Metric value.

[0063] In the embodiment of the present application, the metric value in the metric object may include one or more path delay metric values.

[0064] Specifically, the path delay metric value carried by the Metric object includes at least one of the following:

[0065] The first metric value is used to indicate the forward path delay;

[0066] The second metric value is used to indicate the reverse path delay;

[0067] The third metric value is used to indicate the bidirectional path delay difference.

[0068] Please refer to Figure 5a, which is a format diagram of a Metric object provided in an embodiment of the present application. As shown in Figure 5a, the Metric object carries Metric Value 1 and Metric Value 2, where Metric Value 1 represents the forward path delay and Metric Value 2 represents the reverse path delay.

[0069] Please refer to Figure 5b, which is a format diagram of a Metric object provided in an embodiment of the present application. As shown in Figure 5b, the Metric object carries Metric Value 3, which represents the bidirectional path delay difference.

[0070] Please refer to Figure 5c, which is a format diagram of a Metric object provided in an embodiment of the present application. As shown in Figure 5c, the Metric object carries Metric Value 1, Metric Value 2 and Metric Value 3, where Metric Value 1 represents the forward path delay, Metric Value 2 represents the reverse path delay, and Metric Value 3 represents the bidirectional path delay difference.

[0071] In the embodiment of the present application, the Metric object includes a T flag, which can be used to indicate the type of the path delay Metric value carried by the Metric object.

[0072] The T flag in the currently defined Metric object can be used to indicate the following metric types: IGP metric, TE metric, hop count, path delay, variable path delay, path loss, etc. In this embodiment of the present application, in order to use the T flag to indicate the path delay metric value type carried by the Metric object, the definition of the T flag in the Metric object is further expanded so that the T flag can also be used to indicate the following metric types: forward path delay, reverse path delay, two-way path delay difference, forward path delay + reverse path delay, and forward path delay + reverse path delay + two-way path delay difference.

[0073] For example, in the metric object example shown in Figure 5a, the T flag value is X0, indicating that the metric object contains two path delay metric values, one for the forward path delay and one for the reverse path delay. In the metric object example shown in Figure 5b, the T flag value is X1, indicating that the metric object contains one path delay metric value, indicating the bidirectional path delay difference. In the metric object example shown in Figure 5c, the T flag value is X2, indicating that the metric object contains three path delay metric values, indicating the forward path delay, the reverse path delay, and the bidirectional path delay difference. Here, the values ​​of X0, X1, and X2 are not equal.

[0074] In this embodiment of the present application, the forward path delay represents the cumulative delay of all links traversed by the forward path. For example, if the current forward path traverses nodes R1, R2, R3, and R4, the forward path delay includes the cumulative delay of the link from R1 to R2, the link from R2 to R3, and the link from R3 to R4.

[0075] Forward path delay can also represent the cumulative delay of all links and nodes along the forward path. For example, if the forward path passes through nodes R1, R2, R3, and R4, the forward path delay includes the cumulative delay of the link from R1 to R2, the link from R2 to R3, and the link from R3 to R4. It also includes the cumulative delay of nodes R1, R2, R3, and R4.

[0076] In the embodiment of the present application, the reverse path delay represents the accumulated delay of all links through which the reverse path passes. For example, the nodes through which the current reverse path passes are R4, R5 and R1, and the reverse path delay includes the accumulated delay value of the link from R4 to R5 and the link from R5 to R1.

[0077] Reverse path delay can also represent the cumulative delay of all links and nodes along the reverse path. For example, if the reverse path passes through nodes R4, R5, and R1, the reverse path delay includes the cumulative delay of the link from R4 to R5, the link from R5 to R1, and the cumulative delay of nodes R4, R5, and R1.

[0078] In the embodiment of the present application, the bidirectional path delay difference represents the difference between the forward path delay and the reverse path delay, or represents the absolute difference between the forward path delay and the reverse path delay.

[0079] In the embodiment of the present application, the Metric object carried by the first message may include an intent attribute Metric object for carrying the expected path delay Metric value.

[0080] Exemplarily, the first message includes an intent attribute object, the intent attribute object includes one or more sub-objects, one of which is an intent attribute Metric object, and the intent attribute Metric object includes a metric list<Metric list> The metric list contains metric values ​​used to represent the expected path delay. Specifically, the metric list of the intent attribute Metric object can include at least one of the following path delay metric values:

[0081] The first expected metric value is used to indicate the expected forward path delay;

[0082] The second expected metric value is used to indicate the expected reverse path delay;

[0083] The third expected metric value is used to indicate the expected bidirectional path delay difference.

[0084] In one possible embodiment of the present application, the first node is a PCC, the second node is a PCE, and the first message is a PCInitiate message. Exemplarily, the PCE, knowing the desired latency metric value for an LSP, sends a PCInitiate message carrying an intent attribute Metric object to the PCC. After receiving the PCInitiate message from the PCE, the PCC performs path configuration and creates an LSP that meets the path latency metric value in the intent attribute Metric object.

[0085] In one possible embodiment of the present application, the first node is a PCC, the second node is a PCE, and the first message is a PCUpd message. For example, a network topology change, for example, causes the PCE to recalculate a path. The PCE sends the recalculated path information to the PCC via a PCUpd message. The PCUpd message also carries the expected path delay information (i.e., the intent attribute Metric object) for the LSP to be created. After receiving the PCUpd message from the PCE, the PCC performs path configuration and creates an LSP that meets the path delay metric value in the intent attribute Metric object.

[0086] In the embodiment of the present application, after the first node receives the first message sent by the second node, the path configuration can be completed through RSVP-TE distributed signaling, or the path configuration can be completed through SRv6.

[0087] In the embodiment of the present application, path configuration is performed based on path information and path delay metric values, which may specifically include the following steps:

[0088] Step S201: Send a third message to the downstream according to the path information, where the third message is a path message;

[0089] Step S202: Receive a fourth message sent by the downstream according to the third message, so as to complete the path configuration according to the fourth message, where the fourth message is a resource reservation Resv message.

[0090] Exemplarily, after the head node in the network receives the first message sent by the PCE, it generates a Path message carrying label request information, and the Path message is sent to the downstream node hop by hop along the path calculated by the PCE; after the tail node in the path receives the Path message, it generates a Resv message carrying reservation information and labels, and returns to the head node hop by hop along the opposite path sent by the Path message. At the same time, the Resv message reserves resources on the nodes along the way; when the head node receives the Resv message, the LSP path is successfully established.

[0091] In an embodiment of the present application, after receiving the fourth message sent by the downstream according to the third message, the following steps may also be included: sending a fifth message carrying a Metric object to the second node, where the fifth message is a path status report PCRpt message.

[0092] Exemplarily, after the LSP path is successfully created, the head node returns a PCRpt message to the PCE to report the status of the created LSP. The PCRpt message may carry a Metric object.

[0093] In an embodiment of the present application, the Metric object carried by the fifth message includes an intended attribute Metric object and an actual attribute Metric object. The intended attribute Metric object is used to carry the expected path delay Metric value, and the actual attribute Metric object is used to carry the actual path delay Metric value.

[0094] Exemplarily, the fifth message includes an intent attribute object and an actual attribute object.

[0095] Exemplarily, the intent attribute object in the fifth message includes one or more sub-objects, one of which is an intent attribute Metric object, which contains a Metric list.<Metric list> The metric values ​​in the metric list are used to represent the expected path delay metric values. Specifically, the metric list of the intent attribute Metric object can include at least one of the following path delay metric values:

[0096] The first expected metric value is used to indicate the expected forward path delay;

[0097] The second expected metric value is used to indicate the expected reverse path delay;

[0098] The third expected metric value is used to indicate the expected bidirectional path delay difference.

[0099] Exemplarily, the actual attribute object in the fifth message includes one or more sub-objects, one of which is an actual attribute Metric object, which includes a Metric list.<Metric list> The metric values ​​in the metric list are used to represent the actual path delay metric values. Specifically, the metric list of the actual attribute metric object can include at least one of the following path delay metric values:

[0100] The first actual metric value is used to indicate the actual forward path delay;

[0101] The second actual metric value is used to indicate the actual reverse path delay;

[0102] The third actual metric value is used to indicate the actual bidirectional path delay difference.

[0103] Please refer to FIG6 , which is a flowchart of a service path establishment method provided in an embodiment of the present application. The method is applied to a first node. As shown in FIG6 , the method includes the following steps S301 to S303:

[0104] Step S301: Send a second message carrying path computation constraint information to a second node, so that the second node determines path information according to the path computation constraint information, where the path computation constraint information includes a Metric object.

[0105] Step S302: Receive a first message sent by the second node, where the first message carries path information and a metric object, and the metric object carries a path delay metric value.

[0106] Step S303: Perform path configuration according to the path information and the path delay metric value.

[0107] In one possible embodiment of the present application, the first node is a PCC, the second node is a PCE, the second message is a path computation request (PCReq) message, and the first message is a path computation reply (PCRep) message. The PCC sends the PCReq message to the PCE requesting path computation, the PCReq message carrying constraint information. The PCE receives the PCReq message from the PCC, calculates a path that meets the constraints, and sends the calculated path information to the PCC via a PCRep message, in response to the PCC's path computation request.

[0108] In this embodiment of the present application, the PCReq message carries a Metric object. The PCE determines the path latency requirement based on the metric value in the Metric object and then calculates a path that meets the latency requirement. For example, if the PCReq message carries two metric values ​​representing the forward path latency and the reverse path latency, respectively, the PCE must calculate the forward and reverse paths that meet the respective forward and reverse path latency requirements. For another example, if the PCReq message also carries a metric value representing the bidirectional path delay difference, the forward and reverse paths calculated by the PCE must also meet the aforementioned bidirectional path delay difference.

[0109] In this embodiment of the present application, the path calculation constraint information further includes at least one of the following:

[0110] Request parameter RP object, the RP object carries the first B flag, which is used to indicate whether the path to be calculated is bidirectional;

[0111] Endpoint END-POINTS object, which carries the source and destination addresses of the path to be calculated;

[0112] Bandwidth object, which carries the bandwidth of the path to be calculated.

[0113] Exemplarily, the PCReq message sent by the PCC to the PCE carries an RP object, an END-POINTS object, a bandwidth object, and a Metric object. The value of the B flag in the RP object is 1, indicating that the path to be calculated is a bidirectional path; the END-POINTS object carries the source address and destination address of the path to be calculated, that is, the address information of the two end nodes in the bidirectional path (hereinafter referred to as end A and end Z); the bandwidth object indicates the bandwidth requirement of the path to be calculated, for example, indicating the bandwidth of OTN ODUk, MTNP 5G, fgMTNP 10Mbps, and fgOTN 10Mbps granularity; the Metric object indicates the delay requirement of the path to be calculated. Based on the constraints carried by the PCReq message, the PCE calculates a bidirectional path that meets the requirements of the source node, destination node, bandwidth, delay, etc.

[0114] In this embodiment of the present application, the Metric object also carries a second B flag and a C flag, where the second B flag indicates a boundary flag and the C flag indicates a calculated metric flag. The second B flag and the C flag in the Metric object carried by the second message are both set to 1, so that the first message sent by the second node carries the Metric object.

[0115] Exemplarily, the PCReq message sent by the PCC to the PCE carries a Metric object, and both the B flag and the C flag of the Metric object are set to 1. Therefore, the PCRep message returned by the PCE to the PCC also carries a Metric object.

[0116] In a possible embodiment of the present application, the first node is a PCC, and the second node is a Path Computation Element Central Controller (PCECC). The PCC initiates a path computation request carrying a path delay metric value to the PCECC via a second message. The PCECC returns a message carrying path information and a path delay metric value to the PCC via a first message. The path indicated by the path information meets the requirements of the path delay metric value, i.e., does not exceed the upper limit indicated by the path delay metric value.

[0117] In a possible embodiment of the present application, the first node is a network node, the second node is a software-defined network SDN controller, the network node sends a path calculation request carrying a path delay metric value to the SDN controller through a second message, and the SDN controller returns a message carrying path information and a path delay metric value to the network node through a first message. The path indicated by the path information meets the requirements of the path delay metric value, that is, it does not exceed the upper limit indicated by the path delay metric value.

[0118] In a possible embodiment of the present application, the first node is a first SDN controller, the second node is a second SDN controller, and the first SDN controller (also referred to as an upper-layer controller) sends a path calculation request carrying a path delay metric value to the second SDN controller (also referred to as a lower-layer controller) through a second message; after receiving the path calculation request, the second SDN controller uses a locally deployed routing controller (Routing Controller, RC) to perform path calculation and returns the calculated path information to the first SDN controller through a first message, where the first message also carries the path delay metric value.

[0119] In other possible embodiments of the present application, the first node may be a PCE and the second node may be a PCC; or the first node may be a PCECC and the second node may be a PCC.

[0120] In an embodiment of the present application, a first node initiates a path calculation request to a second node through a second message, where the first message carries forward path delay information, reverse path delay information, and bidirectional path delay difference information; the second node performs path calculation based on the constraints given in the second message, and returns the path calculation result (i.e., path information) to the first unit through the first message.

[0121] Among them, the first node and the second node can correspond to a network node and an SDN controller, or to an SDN controller and an SDN controller, or to a PCC and a PCE, or to a PCE and a PCC, or to a PCC and a PCECC, or to a PCECC and a PCC.

[0122] It is worth noting that in the embodiments of the present application, the forward delay, reverse delay and forward and reverse delay difference of the path can be manually configured or measured by network equipment, such as the link delay measured based on the Precise Time Protocol (PTP). PTP can achieve sub-microsecond to nanosecond time synchronization accuracy between devices. PTP is a master-slave synchronization system that uses a master-slave clock method to encode time information and uses the symmetry and delay measurement technology of the network to achieve master-slave time synchronization. The delay of the path can be calculated from several timestamps obtained from the clock through the interaction of messages: Delay = [(t2-t1) + (t4-t3)] / 2. Among them, t1, t2, t3 and t4 represent the start timestamp and end timestamp of the forward link, the start timestamp of the reverse link and the end timestamp of the reverse link, respectively.

[0123] Exemplarily, the delay in each link and each node that the LSP passes through can be accumulated to obtain the forward / reverse path delay value. When the delay value does not exceed the upper limit of the constraint in the forward / reverse path delay metric value, and the difference between the forward path delay and the reverse delay does not exceed the upper limit of the constraint in the bidirectional path delay difference metric value, it means that the route meets the forward and reverse delay constraints.

[0124] Illustratively, the delay within a node may include an egress queue and a time slot interleaving configuration delay.

[0125] It is worth noting that in the embodiments of the present application, the forward delay, reverse delay, and the difference between the forward and reverse delays of a node can be manually configured or measured by network equipment. For example, in Metropolitan Transport Network (MTN) equipment, optimizing time slot configuration can achieve a smaller node delay.

[0126] When the PCE responds to the PCC, if the path calculation is successful, the PCRep message carries the calculated path delay metric value. The B flag in the metric object must be set to 1, and the C flag is meaningless. The format of the path delay metric object returned by the PCRep message can be any of the formats shown in Figures 5a-5c. However, the metric format used in PCReq and PCRep must be the same.

[0127] When the PCE calculates forward and reverse path delays that fail to meet the expected forward delay, reverse delay, or bidirectional path delay differential, it attempts to compensate for some of the delay using the cache of the head node and / or tail node. Specifically, if the forward delay is small and the reverse delay is large, the forward path delay is increased by increasing the cache capacity of the forward path's tail node (end Z) in the egress direction, thereby reducing the bidirectional path delay differential. If the forward delay is large and the reverse delay is small, the reverse path delay is increased by increasing the cache capacity of the forward path's head node (end A) in the reverse path egress direction, thereby reducing the bidirectional path delay differential.

[0128] By using the above method, the forward and reverse delays and delay differences are carried in the PCC-initiated request, and a path that meets the delay constraints can be calculated, providing a guarantee for services that require precise control of LSP delay.

[0129] The embodiment of the present application further provides a flow diagram of a service path establishment method, which is applied to a second node and includes the following steps:

[0130] Step S401: Send a first message to a first node. The first message carries path information and a metric object. The metric object carries a path delay metric value, so that the first node performs path configuration according to the path information and the path delay metric value.

[0131] The path delay metric value carried in the Metric object includes at least one of the following:

[0132] The first metric value is used to indicate the forward path delay;

[0133] The second metric value is used to indicate the reverse path delay;

[0134] The third metric value is used to indicate the bidirectional path delay difference.

[0135] In the embodiment of the present application, the forward path delay represents the accumulated delay of all links that the forward path passes through, or represents the accumulated delay of all links and all nodes that the forward path passes through.

[0136] The reverse path delay represents the cumulative delay of all links that the reverse path passes through, or represents the cumulative delay of all links and all nodes that the reverse path passes through.

[0137] In the embodiment of the present application, the bidirectional path delay difference (also referred to as the forward and reverse path delay difference) represents the difference or absolute difference between the forward path delay and the reverse path delay.

[0138] In the embodiment of the present application, the Metric object further includes a T flag, which is used to indicate the type of the path delay Metric value carried by the Metric object.

[0139] The embodiment of the present application further provides a flow diagram of a service path establishment method, which is applied to a second node and includes the following steps:

[0140] Step S501: Receive a second message sent by a first node that carries path calculation constraint information, where the path calculation constraint information includes a path delay metric value carried by a metric object.

[0141] Step S502: Determine path information according to the path calculation constraint information in the second message;

[0142] Step S503: Send a first message to the first node. The first message carries path information and a metric object. The metric object carries a path delay metric value, so that the first node performs path configuration according to the path information and the path delay metric value.

[0143] In the embodiment of the present application, the first message is a path computation response PCRep message, and the second message is a path computation request PCReq message.

[0144] In this embodiment of the present application, the path calculation constraint information further includes at least one of the following:

[0145] Request parameter RP object, the RP object carries the first B flag, which is used to indicate whether the path to be calculated is bidirectional;

[0146] Endpoint END-POINTS object, which carries the source and destination addresses of the path to be calculated;

[0147] Bandwidth object, which is used to carry the bandwidth of the path that needs to be calculated.

[0148] In the embodiment of the present application, the Metric object also carries a second B flag and a C flag, wherein the second B flag indicates a boundary flag and the C flag indicates a calculation metric flag;

[0149] The B flag and the C flag in the Metric object carried by the second message are both set to 1, indicating that the first message needs to carry the Metric object.

[0150] In an embodiment of the present application, the first message is a path initialization request PCInitiate message, or the first message is a path update request PCUpd message.

[0151] In the embodiment of the present application, after sending the first message to the first node, the method further includes: receiving a fifth message carrying a Metric object sent by the first node.

[0152] Exemplarily, the fifth message may be a path status report PCRpt message.

[0153] In an embodiment of the present application, the Metric object carried by the fifth message includes an intended attribute Metric object and an actual attribute Metric object. The intended attribute Metric object is used to carry the expected path delay Metric value, and the actual attribute Metric object is used to carry the actual path delay Metric value.

[0154] In the embodiment of the present application, the Metric object carried by the first message includes an intent attribute Metric object for carrying the expected path delay Metric value.

[0155] The following describes the service path establishment method provided in the embodiment of the present application through specific examples.

[0156] In a possible embodiment of the present application, the first node includes a head node and a tail node; the second node receives a second message carrying path calculation constraint information sent by the first node, including: the second node receives the second message carrying path calculation constraint information sent by the head node, and receives the second message carrying path calculation constraint information sent by the tail node.

[0157] The second messages sent by the head node and the tail node both carry a first metric value indicating the forward path delay and a third metric value indicating the bidirectional path delay difference.

[0158] It is worth noting that in the embodiment of the present application, the path from the head node (end A) to the tail node (end Z) is called the forward path; and the path from the tail node (end Z) to the head node (end A) is called the reverse path.

[0159] The first metric value carried in the second message sent by the head node (end A) indicates the delay of the forward path; since the tail node (end Z) in the forward path is the head node in the reverse path, the first metric value carried in the second message sent by the tail node can be considered as the delay of the reverse path.

[0160] Here, the third metric value carried in the second message sent by the head node and the tail node should be equal.

[0161] In the embodiment of the present application, determining the path information according to the path computation constraint information in the second message may include the following steps:

[0162] Determine at least one candidate forward path based on the first metric value carried in the second message sent by the head node, that is, the calculated path delay of each candidate forward path must be lower than the delay indicated by the first metric value carried in the second message sent by the head node;

[0163] Determine at least one candidate reverse path based on the first metric value carried in the second message sent by the egress node, that is, the calculated path delay of each candidate reverse path must be lower than the delay indicated by the first metric value carried in the second message sent by the egress node;

[0164] Determine a forward path and a reverse path that meet the third metric value according to the path delay difference between the candidate forward path and the candidate reverse path.

[0165] Specifically, the path delay of each candidate forward path and the path delay of each candidate reverse path can be obtained, a path is selected from the candidate forward path, and a path is selected from the candidate reverse path. If the path delay difference between the selected candidate forward path and the candidate reverse path meets the constraint of the third metric value, the selected candidate forward path and candidate reverse path can be used as the final forward path and reverse path, respectively.

[0166] Example 1:

[0167] The first node is a PCC, the second node is a PCE, a PCEP session is established between the PCC and the PCE, and Keepalive messages are maintained.

[0168] When the PCC initiates a small-granularity service creation request to the PCE, for example, a 10 Mbps bidirectional fgMTNP small-granularity service, requiring a maximum forward path delay of 15 ms, a maximum reverse path delay of 15 ms, and a maximum forward and reverse delay difference of 200 μs, the PCC initiates a path calculation request to the PCE, namely, sending a PCReq message to the PCE. The PCReq message carries the following objects: RP object, END-POINTS object, LSPA object, Bandwidth object, Metric object, RRO object, IRO object, and LOAD-BALANCING object.

[0169] The B flag in the RP object is set to 1, indicating that the LSP to be created is a bidirectional LSP.

[0170] The value of the Bandwidth object indicates that the bandwidth of the LSP to be created is 10 Mbps and the LSP type to be created is fgMTNP (including the settings of the LSP encoding type and switching type).

[0171] Two Metric objects can be set. The first Metric object has the T flag set to X1 and includes Metric Value 1, which indicates the upper limit of the forward path delay, and Metric Value 2, which indicates the upper limit of the reverse path delay. The second Metric object has the T flag set to X2 and includes Metric Value 3, which indicates the upper limit of the bidirectional path delay difference. Alternatively, only one Metric object can be set. The T flag in this Metric object has the value X3 and includes Metric Value 1, which indicates the upper limit of the forward path delay, Metric Value 2, which indicates the upper limit of the reverse path delay, and Metric Value 3, which indicates the upper limit of the bidirectional path delay difference.

[0172] After receiving the path calculation request, the PCE uses the forward path delay limit, reverse path delay limit, and bidirectional path delay difference limit in the metric object as route calculation constraints for path calculation. The route calculation method can use OSPF or OSPF-TE protocols.

[0173] In one possible example, the process of the PCE determining the path information includes: calculating the introduced delay on each link that the path passes through, accumulating the forward delay, reverse delay, and the difference between the forward delay and the reverse delay of each link, and when the accumulated forward delay does not exceed the forward delay upper limit, the reverse delay does not exceed the reverse delay upper limit, and the difference between the forward delay and the reverse delay does not exceed the two-way delay difference upper limit, then the path meets the given delay constraint.

[0174] In one possible example, the process of the PCE determining the path information includes: calculating the introduced delay on each link and each node that the path passes through, accumulating the forward delay, reverse delay, and the difference between the forward delay and the reverse delay of each link and each node; when the accumulated forward delay does not exceed the forward delay upper limit, the reverse delay does not exceed the reverse delay upper limit, and the difference between the forward delay and the reverse delay does not exceed the two-way delay difference upper limit, the path meets the given delay constraint.

[0175] For example, intra-node latency can include egress queue and time slot crossover configuration delays. A node's forward delay, reverse delay, and the difference between forward and reverse delays can be configured manually or measured by the network node. Optimizing time slot configuration within a network node can reduce node latency.

[0176] When the PCE responds to the PCC, if path calculation is successful, the PCRep message carries the calculated path delay metric value, and the B flag in the metric object is set to 1, and the C flag is meaningless. The format of the metric object in the PCRep message can refer to the three formats described above, but the requirement is that the metric value types carried in the PCReq and PCRep are the same. The three returned metric values ​​represent the calculated forward delay, reverse delay, and forward and reverse delay difference corresponding to the path.

[0177] When the PCE calculates forward and reverse path delays that fail to meet the expected forward delay, reverse delay, or forward and reverse delay differential, it can attempt to compensate for some of the delay by adjusting the cache at the head node and / or tail node. Specifically, if the forward delay is small and the reverse delay is large, the forward path delay can be increased by increasing the egress cache capacity at the tail node (end Z) of the forward path, thereby reducing the forward and reverse delay differential. If the forward delay is large and the reverse delay is small, the reverse path delay can be increased by increasing the egress cache capacity at the head node (end A) of the forward path, thereby reducing the forward and reverse delay differential.

[0178] By using the above method, the forward and reverse delays and delay differences are carried in the PCC-initiated request, and a route that meets the delay constraints can be calculated, providing a guarantee for services that require precise control of LSP delay.

[0179] Example 2

[0180] The PCE wants to create a bidirectional fgMTNP small-granularity service with a bandwidth of 10 Mbps. The maximum forward path latency is 15 ms, the maximum reverse path latency is 15 ms, and the maximum difference in forward and reverse path latency is 200 μs. The headend is R1 and the tailend is R3. The PCE has established a PCEP session with R1, which serves as the PCC.

[0181] The PCE first uses the service requirements, such as the head and tail node addresses, bidirectional links, bandwidth, and protection attributes, as constraints and, in conjunction with the TE database, calculates the path R1-R2-R3. The PCE then populates the LSP creation message (PCInitiate) with the Stateful PCE Request Parameter (SRP), LSP object, END-POINTS object, ERO object, bidirectional flag, and various constraint attribute objects. These constraint attribute objects may include an intent attribute object, which carries a Metric object indicating the expected maximum forward delay of 15ms, the expected maximum reverse delay of 15ms, and the expected maximum difference between forward and reverse delays of 200µs. The PCE sends the bidirectional LSP creation message to the PCC (i.e., R1) and records the LSP-related information.

[0182] After receiving the LSP creation request, R1 can complete the LSP creation through RSVP-TE distributed signaling or SRv6.

[0183] After creating the LSP, R1 returns a PCRpt message to the PCE, which contains the SRP object, LSP object, RRO object, intended attribute object, and actual attribute object. The intended attribute object may include a metric object representing the expected delay, and the actual attribute may include a metric object representing the actual delay of the currently created LSP.

[0184] After receiving the Bidirectional LSP Report (PCRpt) message, the PCE matches the SRP object and LSP object in the message with local records, finds the corresponding bidirectional LSP instance, and updates the path, state, authorization, metric, and other information records. The PCE has now completed the establishment of the bidirectional LSP.

[0185] If the business later expects to modify the expected path delay metric value in the intent attribute object of the bidirectional LSP, it can be achieved by sending an LSP update request message (PCUpdate message) to R1. Specifically, the updated expected path delay metric value can be carried through the Metric object under the intent attribute object.

[0186] Example 3

[0187] The PCECC, as a centralized path calculation unit, interacts with multiple PCCs. After determining the service configuration, the PCECC can directly configure the service to the PCC, thereby establishing a service connection.

[0188] Please refer to Figure 7, which is a flowchart of a service path establishment method provided in an embodiment of the present application. The PCECC negotiates with the PCC corresponding to the LSP head node through the PCInitiate message to obtain authorization, and sends the PCC with PLSP-ID=0 through the PCInitiate message to trigger the PCC to return the allocated PLSP-ID (LSP identifier).

[0189] The PCC sends a PCRpt message to report the LSP status and indicate that the LSP is going up. It returns a specific PLSP-ID so that the PCECC can obtain the corresponding LSP trusteeship authorization (i.e., set the D (Delegate) flag and C flag in the PCRpt to 1).

[0190] When the PCECC knows the expected path delay metric value for an LSP, it can carry this value in the creation request, that is, in the PCInitiate message sent to the PCC corresponding to the LSP head node. The delay metric value can be located in a sub-Metric object under the intent attribute object. In this sub-Metric object, to support forward and reverse path delay constraints, the embodiments of the present application expand the Metric object definition to include metric value types such as the forward path delay upper limit, the reverse path delay upper limit, and the forward and reverse (bidirectional) path delay difference.

[0191] If the PCECC does not know the expected path delay metric value of the LSP, it is not necessary to carry the path delay metric object in the creation request.

[0192] The PCInitiate message sent by the PCECC to the PCCs corresponding to the intermediate and egress nodes of the LSP does not need to carry the delay metric value.

[0193] The PCRpt message sent by the LSP head node to the PCECC can carry the intent attribute object ( <intended-attribute-list>), actual property object ( <actual-attribute-list>).

[0194] The PCRpt message sent by the LSP intermediate node and the tail node does not need to carry the intended attribute object and the actual attribute object.

[0195] The solution of the embodiment of the present application extends the intent attribute object <metric-list>The Metric object under is used to represent the expected path delay metric value of the entire LSP; in addition, the actual attribute object ( <actual-attribute-list>The delay metric value filled in the Metric object under ) is the actual measured path delay metric value of the entire LSP.

[0196] If the service later wishes to modify the expected path delay metric value in the intent attribute object of the bidirectional LSP, the PCECC can send an LSP update request message (PCUpdate message) to the PCC corresponding to the LSP head node, and the PCUpdate message is filled with the intent attribute ( <intended-attribute-list>),exist <intended-attribute-list>The metric value of the expected path delay is carried in the packet, such as the expected forward path delay, reverse path delay, and forward and reverse path delay difference.

[0197] The PCUpdate message sent by the PCECC to the intermediate node and the tail node does not need to carry the expected path delay metric value.

[0198] Example 4

[0199] Please refer to Figure 8, which is a flow chart of a service path establishment method provided by an embodiment of the present application. PCC initiates a connection creation interaction to PCECC via a PCRpt message to implement LSP creation. Specifically, the PCC corresponding to the LSP head node sends a PCRpt message to PCECC to authorize PCECC to host the LSP. The PCRpt message sent by PCC carries an intent attribute object ( <intended-attribute-list>) and the actual property object ( <actual-attribute-list>). Intent attribute object <metric-list>The Metric object under the metric represents the expected path delay metric value of the entire LSP; the actual attribute object ( <actual-attribute-list>) represents the actual measured path delay metric value of the entire LSP.

[0200] Example 5

[0201] Under the SDN controller architecture, the n-th level controller can directly control the transmission network equipment, control the resources provided by the lower-level controller (n-1-th level controller) through the CPI interface, and provide connection services for the upper-level controller (n+1-th level controller) through the CPI interface.

[0202] The network device detects a latency-constrained connection request from a client (e.g., via UNI signaling) and passes it to the controller via the CPI interface. The controller then calculates the connection route based on the received request and sends the network configuration to the network device. This connection request can be for OTN ODUk granularity, MTNP 5G granularity, fgMTNP 10Mbps granularity, or fgOTN 10Mbps granularity services.

[0203] In addition to basic information such as bandwidth, the connection request uploaded by the network device through the CPI interface also carries forward and reverse path delay limits, as well as bidirectional path delay difference information, to the controller. The forward path delay limit represents the upper limit of the cumulative end-to-end delay from the starting point to the end point, the reverse path delay limit represents the upper limit of the cumulative end-to-end delay from the end point to the starting point, and the bidirectional path delay difference information represents the difference between the forward and reverse path delays.

[0204] When the controller receives the request, a path calculation based on the bidirectional path delay is performed in the Routing Controller (RC).

[0205] The delay introduced on each link along the path is calculated. The forward delay, reverse delay, and the difference between the forward and reverse delays of each link are accumulated. If the accumulated forward delay does not exceed the forward delay upper limit, the reverse delay does not exceed the reverse delay upper limit, and the difference between the forward and reverse delays does not exceed the two-way delay difference upper limit, the path meets the given delay constraint.

[0206] The introduced delay is calculated on each link and each node that the path passes through. The forward delay, reverse delay, and the difference between the forward and reverse delays of each link and each node are accumulated. If the accumulated forward delay does not exceed the forward delay upper limit, the reverse delay does not exceed the reverse delay upper limit, and the difference between the forward and reverse delays does not exceed the two-way delay difference upper limit, the path meets the given delay constraint.

[0207] After the controller calculates a path that meets the constraints, it configures the configuration information on each node that the path passes through to establish a service connection.

[0208] Example 6

[0209] The upper-layer controller decomposes the two-way delay constraints of the end-to-end connection to one or more lower-layer controllers through which multiple end-to-end connections pass, and determines the specific two-way delay constraints within the lower-layer controllers. The connection request here can be a connection request for OTN ODUk granularity, MTNP 5G granularity, fgMTNP 10Mbps granularity, or fgOTN 10Mbps granularity services.

[0210] The upper-layer controller transmits forward and reverse delay caps and two-way delay difference information to the lower-layer controller via the CPI interface. The forward delay cap indicates the upper limit of the cumulative end-to-end delay from the start point to the end point of the path, the reverse delay cap indicates the upper limit of the cumulative end-to-end delay from the end point to the start point of the path, and the two-way delay difference information indicates the difference between the forward and reverse delays of the path.

[0211] When the lower-layer controller receives the request, a path calculation based on two-way delay is performed in a routing controller (RC).

[0212] The delay introduced on each link along the path is calculated. The forward delay, reverse delay, and the difference between the forward and reverse delays of each link are accumulated. If the accumulated forward delay does not exceed the forward delay upper limit, the reverse delay does not exceed the reverse delay upper limit, and the difference between the forward and reverse delays does not exceed the two-way delay difference upper limit, the path meets the given delay constraint.

[0213] The introduced delay is calculated on each link and each node that the path passes through. The forward delay, reverse delay, and the difference between the forward and reverse delays of each link and each node are accumulated. If the accumulated forward delay does not exceed the forward delay upper limit, the reverse delay does not exceed the reverse delay upper limit, and the difference between the forward and reverse delays does not exceed the two-way delay difference upper limit, the path meets the given delay constraint.

[0214] When the lower-level controller calculates a connection path that meets the constraints, it returns the connection information to the upper-level controller. The upper-level controller splices the connections from one or more lower-level controllers to complete the end-to-end connection creation.

[0215] Example 7

[0216] The nodes at the head and tail end calculate the coordination of the forward and reverse paths and determine the two-way delay constraints. Node A represents the head node, and node Z represents the tail node. A->Z is the forward direction, and Z->A is the reverse direction.

[0217] The PCE can receive path calculation requests from the PCCs corresponding to the bidirectional head node A and tail node Z. The request from the PCC corresponding to head node A carries the forward delay upper limit and the two-way delay difference information; the request from the PCC corresponding to tail node Z carries the reverse delay upper limit and the two-way delay difference information. Note that the reverse delay upper limit should be entered in the forward metric value 1 of the metric object. Alternatively, the forward delay upper limit can be entered in the reverse metric value 2 of the metric object.

[0218] The PCE calculates the forward and reverse paths based on the head and tail nodes of the forward and reverse connections. The forward path is the path from the head node to the tail node of the bidirectional connection (i.e., A->Z), and the reverse path is the path from the tail node to the head node (i.e., Z->A). For the reverse path itself, its head node is the tail node Z of the forward and reverse connections, and its tail node is the head node A of the forward and reverse connections.

[0219] The PCE calculates one or more forward paths from the source node A to the tail node Z, calculates the delay introduced on each link and / or each node along the path, and accumulates the forward delay of each link and / or each node. If the accumulated forward delay does not exceed the forward delay upper limit, the path meets the given forward delay constraint.

[0220] The PCE calculates one or more reverse paths, that is, from the tail node Z to the head node A of the bidirectional connection, calculates the delay introduced on each link and / or each node along the path, and accumulates the reverse delay of each link and / or each node. If the accumulated reverse delay does not exceed the reverse delay upper limit, the reverse path meets the given reverse delay constraint.

[0221] In the calculated one or more forward paths and reverse paths, the forward delay of the forward path is compared with the reverse delay of the reverse path. If the difference between the forward delay of the forward path and the reverse delay of the reverse path is within the upper limit of the two-way delay difference, the forward path and the reverse path meet the delay constraint.

[0222] After calculating a path that meets the forward and reverse delay constraints, the PCE can return the calculated path and bidirectional path delays to the PCCs corresponding to the headend and tailend nodes. The message returned by the PCE to the PCC can include the calculated path and bidirectional path delays.

[0223] In the dual-path delay metric object sent to the PCC corresponding to head node A, the forward path delay metric value 1 is filled with the path delay from the head node to the egress node calculated by the PCE, and the reverse path delay metric value 2 is filled with the path delay from the egress node Z to the head node A calculated by the PCE.

[0224] In the dual-path delay metric object sent to the PCC corresponding to the egress node Z, the forward path delay metric value 1 is filled with the path delay from the egress node Z to the ingress node A calculated by the PCE, and the reverse path delay metric value 2 is filled with the path delay from the ingress node A to the egress node Z calculated by the PCE.

[0225] Furthermore, the head node and tail node can perform more accurate delay compensation for path delay based on the received bidirectional path delay. For example, tail node Z can increase the forward path delay by increasing the cache capacity in the egress direction, or head node A can increase the reverse path delay by increasing the cache capacity in the reverse path egress direction, thereby compensating for the two-way delay difference through caching.

[0226] The PCE-PCC interaction method and transmitted information in this embodiment are also applicable to use between an upper-layer controller and a lower-layer controller.

[0227] In the solution of the embodiment of the present application, the first message sent by the second node to the first node carries path information and a Metric object, wherein the Metric object carries a path delay Metric value. This enables the first node to obtain the service delay information from the Metric object of the first message and configure the service path based on the service delay information to ensure that the created service path can meet the service delay requirements.

[0228] The embodiment of the present application further provides an electronic device, as shown in FIG9 , the electronic device 1400 includes:

[0229] one or more processors 1410;

[0230] The memory 1420 stores one or more programs. When the one or more programs are executed by the one or more processors 1410, the one or more processors 1410 implement the following:

[0231] A service path establishment method applied to a first node;

[0232] or,

[0233] A service path establishment method applied to the second node.

[0234] The memory 1420 is a non-transient network system that can be used to store non-transient software programs and non-transient computer executable programs. In addition, the memory 1420 may include a high-speed random access memory and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory 1420 may optionally include a memory 1420 remotely located relative to the processor 1410, and these remote memories 1420 may be connected to the processor 1410 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0235] The memory 1420 can be implemented in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 1420 can store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1420 and is called by the processor 1410 to execute the methods of the embodiments of this application.

[0236] The processor 1410 can be implemented using a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of the present application.

[0237] In some embodiments, the electronic device further comprises:

[0238] Input / output interface, used to realize information input and output;

[0239] Communication interface, used to realize communication interaction between this device and other devices, which can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, Wi-Fi, Bluetooth, etc.);

[0240] A bus that transmits information between various components of the device (e.g., the processor 1410, memory 1420, input / output interfaces, and communication interfaces);

[0241] The processor 1410 , the memory 1420 , the input / output interface, and the communication interface can be communicatively connected to each other within the device via a bus.

[0242] An embodiment of the present application further provides a computer-readable storage medium storing computer-executable instructions for executing:

[0243] A service path establishment method applied to a first node;

[0244] or,

[0245] A service path establishment method applied to the second node.

[0246] An embodiment of the present application further provides a computer program product, including a computer program or computer instructions, wherein the computer program or computer instructions are stored in a computer-readable storage medium. A processor of a computer device reads the computer program or computer instructions from the computer-readable storage medium, and the processor executes the computer program or computer instructions, so that the computer device performs the following operations:

[0247] A service path establishment method applied to a first node;

[0248] or,

[0249] For example, the service path establishment method is applied to the second node.

[0250] The system architecture and application scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Those skilled in the art will appreciate that with the evolution of the system architecture and the emergence of new application scenarios, the technical solutions provided in the embodiments of the present application are equally applicable to similar technical problems.

[0251] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0252] Those skilled in the art will appreciate that all or some of the steps and systems in the method disclosed above can be implemented as software, firmware, hardware, and appropriate combinations thereof. Some physical components or all physical components can be implemented as software executed by a processor, such as a central processing unit, a digital signal processor, or a microprocessor, or implemented as hardware, or implemented as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on a computer-readable medium, and the computer-readable medium can include computer storage media (or non-transitory media) and communication media (or temporary media). As known to those skilled in the art, the term computer storage media is included in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data) and is volatile and non-volatile, removable, and non-removable. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory, or other memory technology, CD-ROM, digital versatile disks (DVD), or other optical disk storage, magnetic cassettes, magnetic tapes, 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, as is well known to those skilled in the art, communication media typically embodies computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.

[0253] The above description of some embodiments of the present application with reference to the accompanying drawings does not limit the scope of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and essence of the present application shall be within the scope of the present application.

Claims

1. A service path establishment method, applied to a first node, comprising: Receive a first message sent by the second node, where the first message carries path information and a metric object, and the metric object carries a path delay metric value; Path configuration is performed according to the path information and the path delay metric value.

2. The method according to claim 1, wherein The path delay metric value carried by the metric object includes at least one of the following: The first metric value is used to indicate the forward path delay; The second metric value is used to indicate the reverse path delay; The third metric value is used to indicate the bidirectional path delay difference.

3. The method according to claim 2, wherein: The forward path delay represents the accumulated delay of all links that the forward path passes through, or represents the accumulated delay of all links and all nodes that the forward path passes through; The reverse path delay represents the accumulated delay of all links that the reverse path passes through, or represents the accumulated delay of all links and all nodes that the reverse path passes through; The bidirectional path delay difference represents the difference or absolute difference between the forward path delay and the reverse path delay.

4. The method according to claim 2, wherein: The Metric object further includes a T flag, which is used to indicate the type of the path delay Metric value carried by the Metric object.

5. The method according to claim 1, wherein Before receiving the first message sent by the second node, the method further includes: Sending a second message carrying path computation constraint information to the second node, so that the second node determines the path information according to the path computation constraint information, where the path computation constraint information includes the Metric object; The second message is a path computation request PCReq message, and the first message is a path computation response PCRep message.

6. The method according to claim 5, wherein: The path calculation constraint information also includes at least one of the following: A request parameter RP object, where the RP object is used to carry a first B flag, where the first B flag is used to indicate whether the path to be calculated is bidirectional; Endpoint END-POINTS object, which is used to carry the source address and destination address of the path to be calculated; A bandwidth object is used to carry the bandwidth of the path that needs to be calculated.

7. The method according to claim 5, wherein: The Metric object also carries a second B flag and a C flag, wherein the second B flag indicates a boundary flag and the C flag indicates a calculation metric flag; The second B flag and the C flag in the Metric object carried in the second message are both set to 1, so that the first message sent by the second node carries the Metric object.

8. The method according to claim 1, wherein The first message is a path initialization request PCInitiate message, or the first message is a path update request PCUpd message.

9. The method according to claim 5 or 8, wherein: The performing path configuration according to the path information and the path delay metric value includes: Sending a third message to the downstream according to the path information, where the third message is a path message; A fourth message sent by the downstream according to the third message is received, so as to complete the path configuration according to the fourth message, where the fourth message is a resource reservation Resv message.

10. The method according to claim 9, wherein: After receiving a fourth message sent downstream according to the third message, the method further includes: A fifth message carrying the Metric object is sent to the second node, where the fifth message is a path status report PCRpt message.

11. The method according to claim 10, wherein: The Metric object carried by the fifth message includes an intended attribute Metric object and an actual attribute Metric object. The intended attribute Metric object is used to carry the expected path delay Metric value, and the actual attribute Metric object is used to carry the actual path delay Metric value.

12. The method according to claim 9, wherein The Metric object carried by the first message includes an intent attribute Metric object for carrying an expected path delay Metric value.

13. The method according to claim 1, wherein The first node is a path computation client PCC, and the second node is a path computation element PCE; Alternatively, the first node is a PCC, and the second node is a path computation unit central controller PCECC; Alternatively, the first node is a network node, and the second node is a software defined network SDN controller; Alternatively, the first node is a first SDN controller, and the second node is a second SDN controller; Alternatively, the first node is a PCE, and the second node is a PCC; Alternatively, the first node is a PCECC and the second node is a PCC.

14. A service path establishment method, applied to a second node, the method comprising: A first message is sent to a first node, where the first message carries path information and a metric object, where the metric object carries a path delay metric value, so that the first node performs path configuration according to the path information and the path delay metric value.

15. The method according to claim 14, wherein The path delay metric value carried by the metric object includes at least one of the following: The first metric value is used to indicate the forward path delay; The second metric value is used to indicate the reverse path delay; The third metric value is used to indicate the bidirectional path delay difference.

16. The method according to claim 15, wherein The forward path delay represents the accumulated delay of all links that the forward path passes through, or represents the accumulated delay of all links and all nodes that the forward path passes through; The reverse path delay represents the accumulated delay of all links that the reverse path passes through, or represents the accumulated delay of all links and all nodes that the reverse path passes through; The bidirectional path delay difference represents the difference or absolute difference between the forward path delay and the reverse path delay.

17. The method according to claim 15, wherein: The Metric object further includes a T flag, which is used to indicate the type of the path delay Metric value carried by the Metric object.

18. The method according to claim 14, wherein Before sending the first message to the first node, the method further includes: receiving a second message sent by the first node and carrying path calculation constraint information, where the path calculation constraint information includes a path delay metric value carried by the metric object; The path information is determined according to the path calculation constraint information in the second message.

19. The method according to claim 18, wherein The first message is a path computation response PCRep message, and the second message is a path computation request PCReq message.

20. The method according to claim 18, wherein The path calculation constraint information also includes at least one of the following: A request parameter RP object, where the RP object carries a first B flag, where the first B flag is used to indicate whether the path to be calculated is bidirectional; Endpoint END-POINTS object, which carries the source address and destination address of the path to be calculated; A bandwidth object, which carries the bandwidth of the path that needs to be calculated.

21. The method according to claim 18, wherein The Metric object also carries a second B flag and a C flag, wherein the second B flag indicates a boundary flag and the C flag indicates a calculation metric flag; The B flag and the C flag in the Metric object carried by the second message are both set to 1, indicating that the first message needs to carry the Metric object.

22. The method according to claim 14, wherein The first message is a path initialization request PCInitiate message, or the first message is a path update request PCUpd message.

23. The method according to claim 22, wherein After sending the first message to the first node, the method further includes: A fifth message carrying the Metric object and sent by the first node is received, where the fifth message is a path status report (PCRpt) message.

24. The method according to claim 23, wherein The Metric object carried by the fifth message includes an intended attribute Metric object and an actual attribute Metric object. The intended attribute Metric object is used to carry the expected path delay Metric value, and the actual attribute Metric object is used to carry the actual path delay Metric value.

25. The method according to claim 14, wherein The Metric object carried by the first message includes an intent attribute Metric object for carrying an expected path delay Metric value.

26. The method according to claim 18, wherein The first node includes a head node and a tail node, and the second message sent by the head node and the tail node both carries a first metric value indicating a forward path delay and a third metric value indicating a bidirectional path delay difference; The determining the path information according to the path calculation constraint information in the second message includes: Determine at least one candidate forward path according to the first metric value carried in the second message sent by the head node; Determine at least one candidate reverse path according to the first metric value carried in the second message sent by the egress node; Determine a forward path and a reverse path that meet the third metric value according to the path delay difference between the candidate forward path and the candidate reverse path.

27. The method according to claim 14, wherein The first node is a path computation client PCC, and the second node is a path computation element PCE; Alternatively, the first node is a PCC, and the second node is a path computation unit central controller PCECC; Alternatively, the first node is a network node, and the second node is a software defined network SDN controller; Alternatively, the first node is a first SDN controller, and the second node is a second SDN controller; Alternatively, the first node is a PCE, and the second node is a PCC; Alternatively, the first node is a PCECC and the second node is a PCC.

28. An electronic device comprising: one or more processors; A memory having one or more programs stored thereon, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the following: The service path establishment method according to any one of claims 1 to 13; or, The service path establishment method according to any one of claims 14 to 27.

29. A computer-readable storage medium having a computer program stored thereon, wherein when the program is executed by a processor, the computer program performs the following steps: The service path establishment method according to any one of claims 1 to 13; or, The service path establishment method according to any one of claims 14 to 27.

Images