OSU lossless bandwidth adjustment method and system

Abstract

The invention discloses an OSU lossless bandwidth adjustment method and system, and belongs to the field of bandwidth adjustment, and the method comprises the steps: obtaining the software processing delay of each node on an optical transmission path; timer control instructions are added to REQ frames and CONFIRM frames sent from a source end to a sink end, the timer control instructions comprise timer update data, and the timer update data are the sum of the residual duration of a node timer and the processing delay of node software; and the intermediate node and the destination node start a timer when receiving the REQ frame for the first time, and update the residual duration of the timer of the node according to the timer update data when receiving the REQ frame and the CONFIRM frame each time. According to the invention, the sum of the residual duration of the timer of the upstream node and the software processing delay is used as the timer updating data to update the residual duration of the timer of the downstream node, so that the upstream node is ensured to be overtime before the downstream node, and the problem of false start caused by the fact that the downstream node receives the REQ frame sent by the upstream node when the downstream node is overtime is avoided; and an accurate timer refreshing strategy is provided.

Description

Technical Field

[0001] The present application relates to the field of bandwidth adjustment, and in particular to an OSU lossless bandwidth adjustment method and system. Background Art

[0002] The optical service unit (OSU) lossless bandwidth adjustment function transmits and receives bandwidth adjustment OAM (Operation Administration and Maintenance) frames between source and sink nodes, transmits bandwidth adjustment information, and performs control signaling. Each node completes the bandwidth adjustment action in turn, ultimately achieving zero customer traffic loss during the bandwidth adjustment process.

[0003] The bandwidth adjustment command is sent to the end node by the network management or control plane, and the transmitted OAM frame may contain the original bandwidth, target bandwidth and timer timeout information. In the bandwidth increase scenario, after each node confirms the bandwidth resources, it will increase the OSU service bandwidth in order from the sink to the source, and report the successful adjustment result to the network management or control plane, and then increase the customer's actual traffic; in the bandwidth reduction scenario, the customer's actual traffic will be reduced first, and each node will reduce the OSU service bandwidth in order from the source to the sink. Each node uses a timer to constrain the response time range of this bandwidth adjustment action. If the timer times out, the node will stop sending OAM frames, perform bandwidth rollback, and report the adjustment failure result.

[0004] When adjusting bandwidth, the network management or control plane will send a bandwidth adjustment command to the end nodes on the optical transmission path. For the convenience of description, any end node that receives the above command is defined as the source node, and the other end node is defined as the sink node.

[0005] In the bandwidth increase scenario, after receiving the above command, the source node continuously sends bandwidth resource query messages (INC_REQ) to the sink and simultaneously starts the source timer. After receiving the INC_REQ, each intermediate node and the sink node checks their own bandwidth resources. When their remaining bandwidth resources are sufficient, each intermediate node continues to transmit the INC_REQ downstream. After receiving the INC_REQ, the sink node adjusts the forward link bandwidth if its remaining bandwidth resources are sufficient. It then begins continuously sending bandwidth resource confirmation messages (INC_ACK) to the source and simultaneously starts the sink timer. After receiving the INC_ACK, each intermediate node adjusts the forward link bandwidth and simultaneously starts its own timer. The source node receives the INC_ACK and then adjusts the forward link bandwidth. If any node fails to adjust the link bandwidth, it reports the failure to the network management or control plane.

[0006] After all nodes along the entire optical transmission path up to the source node complete link bandwidth adjustment, the source node stops sending INC_REQ and begins continuously sending end query messages (hereinafter referred to as INC_CONFIRM) to the sink. After receiving INC_CONFIRM, the sink node stops sending INC_ACK to the source, simultaneously cancels the sink timer, and begins continuously sending end confirmation messages (hereinafter referred to as INC_CONFIRM_ACK) to the source. After receiving INC_CONFIRM_ACK, each intermediate node cancels its own site timer. After receiving INC_CONFIRM_ACK, the source node stops sending INC_CONFIRM, cancels the source timer, and reports the adjustment success to the network management or control plane. After the sink node no longer detects INC_CONFIRM, it stops sending INC_CONFIRM_ACK.

[0007] From the above steps, it can be seen that first, the source node starts the source timer first when receiving the bandwidth adjustment command. Then, the sink node starts the sink timer when receiving INC_REQ. Then, each intermediate node from the sink to the source starts the local timer in turn when receiving INC_ACK. Subsequently, the sink node cancels the local timer when receiving INC_CONFIRM. Finally, each intermediate node from the sink to the source and the source node cancel the local timer in turn after receiving INC_CONFIRM_ACK. That is, the closer the intermediate node is to the source, the later its timer starts, and the closer the intermediate node is to the destination, the earlier its timer starts. When the timer field value contained in the message is the same, it is easy for the downstream node close to the destination to exit the current bandwidth adjustment process due to timeout adjustment failure, but the upstream node close to the source continues to send INC_REQ to the downstream because it has not timed out. Since the bandwidth adjustment parameter information contained in INC_REQ is completely valid, it will cause the downstream nodes to mistakenly start a new round of bandwidth adjustment process again, and the adjustment result will inevitably be timer timeout and bandwidth adjustment failure. Obviously, as the number of nodes in the service topology increases, the system time loss caused by such errors will increase exponentially.

[0008] In a bandwidth reduction scenario, after receiving the above command, the source node starts its own timer and continuously sends DEC_REQs to the sink. Upon receiving the DEC_REQs, each intermediate node adjusts the forward link bandwidth and simultaneously starts its own timer. Upon receiving the DEC_REQs, the sink node also adjusts the forward link bandwidth. If any node fails to adjust the link bandwidth, it reports the failure to the network management or control plane.

[0009] After all nodes along the entire optical transmission path complete link bandwidth adjustment until the sink node, the sink node begins to continuously send adjustment completion messages (hereinafter referred to as DEC_ACK) to the source end. After receiving DEC_ACK, each intermediate node and the source node cancels the timer of the local site. Among them, after receiving DEC_ACK, the source node stops sending DEC_REQ.

[0010] From the above steps, we can see that, unlike the bandwidth increase scenario, in the bandwidth reduction scenario, the timers start in the order from source to sink and end in the order from sink to source. In other words, in theory, the upstream node will time out earlier than the downstream node. The problem of the downstream node timing out but the upstream node not timing out, and the upstream node continuing to send OAM frames to the downstream node, causing the downstream node to erroneously start a new round of bandwidth adjustment process, will not occur.

[0011] However, in actual technical applications, nodes in the service topology vary by manufacturer, device form factor, and software version. These differences lead to variations in software processing delays (i.e., the time difference between when the timer expires and when the REQ frame stop action actually takes effect) between nodes. Even if the upstream node is theoretically constrained to start the timer before the downstream node, there is no guarantee that the upstream REQ frame stop will have occurred by the time the timer expires and the current bandwidth adjustment process ends. Existing operator technical specifications still fail to address the system fluctuations and time losses caused by actual node differences in specific timer timeout scenarios. Summary of the Invention

[0012] The present application provides an OSU lossless bandwidth adjustment method and system, which can solve the problem of system fluctuation time loss caused by the downstream node timing out before the upstream node in the prior art.

[0013] In a first aspect, an embodiment of the present application provides an OSU lossless bandwidth adjustment method, the method comprising: Obtain the software processing delay of each node on the optical transmission path; A timer control instruction is added to each of the REQ and CONFIRM frames sent sequentially from the source to the sink. The timer control instruction contains timer update data, which is the sum of the remaining time of the local timer and the software processing delay of the local node. The intermediate node and the sink node start a timer when they first receive the REQ frame, and update the remaining duration of the timer of the local node according to the timer update data each time they receive the REQ frame and the CONFIRM frame.

[0014] In combination with the first aspect, in one implementation, the software processing delay is the sum of the task processing cycle and the code response time.

[0015] In combination with the first aspect, in one implementation, the task processing cycle is used as the software processing delay.

[0016] In combination with the first aspect, in one embodiment, the method further includes: By obtaining a sample set of task processing cycles in the history of each node, an upper limit value of the task processing cycle is obtained, and the upper limit value is used as the software processing delay for calculating timer update data.

[0017] In conjunction with the first aspect, in one embodiment, the upper limit value is obtained by using the following formula:

[0018] Wherein, Sm represents the upper limit value, n represents the number of samples in the task processing cycle sample set, Smax represents the maximum value in the task processing cycle sample set, and k1 and k2 are adjustment coefficients.

[0019] In combination with the first aspect, in one embodiment, the method further includes: The REQ frame and CONFIRM frame sent from the source to the sink are both configured with the Timer field and the Delay field. The Timer field is used to store the integer part of the timer update data in seconds, and the Delay field is used to store the fractional part of the timer update data in seconds.

[0020] In combination with the first aspect, in one embodiment, the method further includes: The Timer field and Delay field are not updated in the ACK frame and CONFIRM_ACK frame sent sequentially from the sink to the source.

[0021] In a second aspect, an embodiment of the present application provides an OSU lossless bandwidth adjustment system, the system comprising: A processing module, which is used to obtain the software processing delay of each node on the optical transmission path; A configuration module, configured to add a timer control instruction to each of the REQ and CONFIRM frames sent sequentially from the source to the sink, wherein the timer control instruction includes timer update data, which is the sum of the remaining time of the timer of the local node and the software processing delay of the local node; The control module is used to control the intermediate node and the sink node to start the timer when the REQ frame is received for the first time, and to update the remaining time of the timer of the node according to the timer update data each time the REQ frame and the CONFIRM frame are received.

[0022] In conjunction with the second aspect, in one implementation, the task processing cycle is used as the software processing delay.

[0023] In conjunction with the second aspect, in one embodiment, the configuration module is further configured to configure a Timer field and a Delay field in both a REQ frame and a CONFIRM frame sequentially sent from the source end to the sink end, where the Timer field is used to store an integer portion of the timer update data in seconds, and the Delay field is used to store a fractional portion of the timer update data in seconds. The configuration module is further configured to not update the Timer field and the Delay field in both the ACK frame and the CONFIRM_ACK frame sent in sequence from the sink end to the source end.

[0024] The beneficial effects of the technical solutions provided in the embodiments of the present application include: Based on the remaining duration of the timer of the source node, when updating the remaining duration of the timer of each node on the path, the sum of the remaining duration of the timer of the upstream node and the software processing delay is used as the timer update data to update the remaining duration of the timer of the downstream node. This ensures that the upstream node times out before the downstream node, avoiding the problem of false startup caused by receiving the REQ frame sent by the upstream node when the downstream node has timed out. It provides a precise timer refresh strategy, making the process action logic analysis process between nodes clearer when locating engineering problem faults. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 Schematic diagram of the OSU lossless bandwidth increase process in the prior art; Figure 2 Schematic diagram of the OSU lossless bandwidth reduction process in the prior art; Figure 3 This is a schematic diagram of an error logic caused by a downstream node timing out before an upstream node in the prior art; Figure 4 This is a flow chart of an embodiment of the OSU lossless bandwidth adjustment method of the present application; Figure 5 This is a flow chart of an embodiment of increasing the OSU lossless bandwidth of the present application; Figure 6 This is a diagram showing the relationship between software processing delay, task processing cycle, and code response time. Figure 7 Figure 1 is a schematic diagram showing the location of the Delay field in an OAM frame. Figure 8 Schematic diagram of the software processing flow when a source node sends a REQ frame or a CONFIRM frame; Figure 9 Schematic diagram of the software processing flow when an intermediate node receives an upstream REQ frame or CONFIRM frame and sends a REQ or CONFIRM frame to the downstream; Figure 10Schematic diagram of the software processing flow when the sink node receives an upstream REQ frame or CONFIRM frame; Figure 11 This is a functional module diagram of an embodiment of the OSU lossless bandwidth adjustment system of the present application. DETAILED DESCRIPTION

[0026] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0027] First, some technical terms in this application are explained to facilitate those skilled in the art to understand this application.

[0028] The OSU lossless bandwidth increase process is as follows Figure 1 The specific description is as follows: A) The network management system sends a bandwidth increase adjustment request (also known as a bandwidth adjustment command) to the source node. B) The source node continuously sends INC_REQs (also known as bandwidth resource query messages, a type of OAM frame) to the sink node, simultaneously starting the source node's timer. C) Upon receiving the INC_REQ, each intermediate node terminates the INC_REQ and verifies bandwidth resources. Once sufficient resources are confirmed, it continues to send INC_REQs downstream. If resources are insufficient, it ceases sending INC_REQs and, optionally, sends an INC_NACK to the source node, reporting the adjustment failure reason to the corresponding network management system. D) Upon receiving the INC_REQ, the sink node first adjusts the client-side interface bandwidth, then adjusts the forward link bandwidth. It then continuously sends INC_ACKs (also known as bandwidth resource confirmation messages, a type of OAM frame) to the source node, starting the sink node's timer. E) Upon receiving the INC_ACK in the reverse direction and confirming sufficient resources, each intermediate node terminates the INC_ACK, adjusts the forward link bandwidth, and then continues to send the INC_ACK back upstream, simultaneously starting its own timer. If the adjustment fails, it terminates the INC_ACK back and reports the adjustment failure reason to the corresponding network management system. F) After receiving the INC_ACK, the source node adjusts the forward link bandwidth, first adjusting the bandwidth of the OSU and then the bandwidth of the OTN (Optical Transport Network) client interface. If the adjustment fails, it stops sending INC_REQs and reports the failure reason to the corresponding network management system. G) After the adjustment is completed normally, the source node stops sending INC_REQs and continues sending INC_CONFIRM messages (a type of OAM frame) to the sink. After receiving the INC_CONFIRM message, the intermediate node continues sending INC_CONFIRM messages to the sink. H) After detecting the INC_CONFIRM, the sink node stops sending INC_ACKs, resets the sink timer, and then continuously sends INC_CONFIRM_ACKs (a type of OAM frame) to the source. I) After each intermediate node detects the INC_CONFIRM_ACK, it directly resets its own timer. J) After receiving the INC_CONFIRM_ACK, the source node stops sending INC_CONFIRM messages and resets the source timer. It then reports the adjustment completion confirmation message to the network management system. K) When the sink node cannot detect INC_CONFIRM, it stops sending INC_CONFIRM_ACK. L) After the adjustment is completed, each node should actively report the changes in OSU bandwidth and link resources to the network management.

[0029] The OSU lossless bandwidth reduction process is as follows Figure 2 The specific description is as follows: A) The network management system sends a bandwidth reduction adjustment request to the source node. B) The source node first adjusts the client-side interface bandwidth to the target bandwidth and performs forward bandwidth adjustment. It then continuously sends DEC_REQ messages (a type of OAM frame) to the sink node, simultaneously starting the source-side timer. C) Each intermediate node terminates after receiving the DEC_REQ and performs forward bandwidth adjustment. After completing its own adjustment, it successively sends DEC_REQ messages downstream and simultaneously starts its own timer. If the adjustment fails, it stops sending DEC_REQs and reports the failure reason to the corresponding network management system. D) After receiving the DEC_REQ, the sink node adjusts the forward link bandwidth, then adjusts the client-side interface bandwidth, and then continuously sends DEC_ACK messages (a type of OAM frame) to the source node. E) After receiving the DEC_ACK message, each intermediate node resets its own timer. F) After receiving the DEC_ACK message, the source node resets the source-side timer, stops sending DEC_REQ messages, and reports the adjustment completion confirmation message to the network management system. G) When the sink node detects no DEC_REQ, it stops sending DEC_ACK. H) After the adjustment is completed, the node should proactively report the changes in OSU bandwidth and link resources to the network management.

[0030] In the bandwidth adjustment scenario, the error logic caused by the downstream node timing out before the upstream node is as follows: Figure 3 As shown in the figure, Node O is the source node, Nodes A and B are intermediate nodes, and Node C is the sink node. If Node B reaches the set timer duration before Node A (i.e., Node B times out before Node A), Node B stops sending INC_REQ (i.e., inquiry messages) and ends this round of adjustment. Node B will then start detecting REQ frames again. If it receives another REQ frame, it triggers a second round of adjustment. This cycle repeats until Node A's timer also times out and stops sending INC_REQ. Node B stops receiving INC_REQ frames, and the cycle ends.

[0031] Because the timeout failure of the first round of user-triggered lossless bandwidth adjustment has already been reported to the network management or control plane, the user can directly issue the next round of lossless bandwidth adjustment commands. Once Node B enters the above-mentioned error logic, the system needs to consume a full timer timeout period to recover to the initial state where it can correctly process the user's new bandwidth adjustment command. This abnormal situation is not perceived by the user.

[0032] This error is also propagative. That is, if node B mistakenly initiates the second round of bandwidth adjustment, in the new process, if downstream node C times out before node B, node C will also mistakenly initiate the third round of bandwidth adjustment. Obviously, as the number of nodes in the service topology increases, the system time loss caused by this error will increase exponentially.

[0033] In order to make the objectives, technical solutions and advantages of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0034] In a first aspect, an embodiment of the present application provides an OSU lossless bandwidth adjustment method.

[0035] In one embodiment, referring to Figure 4 , Figure 4 This is a flow chart of an embodiment of the OSU lossless bandwidth adjustment method of the present application. Figure 4 As shown, the OSU lossless bandwidth adjustment method includes: Step S1: Obtain the software processing delay of each node on the optical transmission path.

[0036] Step S2: Add a timer control instruction to each of the REQ frame and the CONFIRM frame sent sequentially from the source end to the sink end. The timer control instruction includes timer update data, which is the sum of the remaining time of the timer of the local node and the software processing delay of the local node.

[0037] In step S3, the intermediate node and the sink node start a timer when receiving a REQ frame for the first time, and update the remaining duration of the timer of the node according to the timer update data each time a REQ frame and a CONFIRM frame are received.

[0038] In this embodiment, based on the remaining duration of the timer of the source node, when updating the remaining duration of the timer of each node on the path, the sum of the remaining duration of the timer of the upstream node and the software processing delay is used as the timer update data to update the remaining duration of the timer of the downstream node, thereby ensuring that the upstream node times out before the downstream node, avoiding the problem of false startup caused by receiving the REQ frame sent by the upstream node when the downstream node has timed out, and providing a precise timer refresh strategy, so that the process action logic analysis process between nodes is clearer when locating engineering problem faults.

[0039] In one embodiment, referring to Figure 5 , Figure 5 This is a flowchart of an embodiment of the present application for increasing the lossless bandwidth of an OSU. After receiving a bandwidth increase adjustment request from the network management, the source node continuously sends INC_REQs to the sink. The intermediate node directly starts its own timer upon receiving the INC_REQ. It does not need to start its own timer sequentially from sink to source upon receiving the INC_ACK from the sink node. This ensures that the timers are started sequentially from source to sink, preliminarily ensuring that the upstream node times out before the downstream node.

[0040] Furthermore, due to the periodic nature of node software processing, which involves a timeout check at regular intervals, INC_REQs are stopped if a timeout is detected, and INC_REQs continue to be sent if a timeout is detected. This creates a problem: there's a time lag between the timer expiration and the next timeout determination, and INC_REQs are continuously sent during this time. This means that even if a node has timed out, it will continue to send INC_REQs until the next timeout is detected. Therefore, even if an upstream node times out before a downstream node, the upstream node may still continue to send INC_REQs to the downstream node due to software processing delays, creating the risk that the downstream node will also receive INC_REQs after it times out.

[0041] Reference Figure 6 , Figure 6 The following diagram illustrates the relationship between software processing delay, task processing cycle, and code response time. Analyzing node software processing delay, we define the node's software processing delay as I, and the timer duration as Timer. Assuming the node starts the timer at time 0, the actual time when INC_REQ is terminated is Timer + I. Therefore, the downstream node's timer duration can be corrected to Timer + I. This ensures that after a downstream node times out, it will not receive an INC_REQ that has not yet been terminated from the upstream node, thus preventing the next round of bandwidth adjustment from being incorrectly initiated. Clearly, I varies between nodes, and the upstream node's I value needs to be communicated to the downstream node. Furthermore, as the number of nodes increases, the corrected value I accumulates.

[0042] Software processing delay (I) is random and related to the node's task processing cycle (S) and code response time (Y). Code response time is random and difficult to estimate during bandwidth adjustment, so it can be ignored. The node's software processing delay (I) can be equivalently replaced by the task processing cycle (S).

[0043] Furthermore, in one embodiment, the OSU lossless bandwidth adjustment method further includes: By obtaining a sample set of task processing cycles in the history of each node, an upper limit value of the task processing cycle is obtained, and the upper limit value is used as the software processing delay for calculating timer update data.

[0044] In this embodiment, the maximum software processing delay of a node is estimated based on the node task processing cycle sample space. Specific estimation methods include estimating the upper limit of the task processing cycle for the current time period based on the average of the task processing cycles for the same period in history, and determining the upper limit of the task processing cycle at the current time based on the upper limit of the task processing cycle over a period of time.

[0045] Furthermore, in one embodiment, the upper limit value is obtained by using the following formula (1): (1) Wherein, Sm represents the upper limit value, n represents the number of samples in the task processing cycle sample set, Smax represents the maximum value in the task processing cycle sample set, and k1 and k2 are adjustment coefficients.

[0046] In this embodiment, it is easy to deduce from formula (1) that as the number of samples n during the task processing cycle increases, the maximum observed sample value Smax approaches the potential upper limit Sm of the task processing cycle. As the value of k1 increases, more observed samples n are required to reach a reliable Sm value. k2 can be considered the protection interval between adjacent nodes. The larger the k2 value, the more reliable the protection effect achieved by Sm, but the higher the time cost of the strategy. Obviously, Sm varies between nodes. This difference can be transmitted to downstream nodes via REQ frames and CONFIRM frames, allowing each node to strictly follow the source-to-sink order to reach the timer timeout state.

[0047] It is foreseeable that no matter how the values ​​of k1 and k2 are optimized, the statistical calculation formula of Sm can only solve the problem of accurate timer timing in most cases. There will inevitably be a small probability that the sudden software processing delay is greater than the estimated value Sm, causing the downstream node timer to time out before the upstream node timer.

[0048] However, due to the timer real-time update strategy proposed in the present invention, even if the downstream node receives a REQ frame that the upstream has not yet stopped sending, the timer timeout duration indicated by the Timer field and Delay field will be very short, and the newly started bandwidth adjustment process of the downstream node will quickly fail due to timer timeout.

[0049] Furthermore, in one embodiment, referring to Figure 7 , Figure 7 Figure 1 is a schematic diagram of the position of the Delay field in the OAM frame. The OSU lossless bandwidth adjustment method also includes: The REQ frame and CONFIRM frame sent from the source to the sink are both configured with the Timer field and the Delay field. The Timer field is used to store the integer part of the timer update data in seconds, and the Delay field is used to store the fractional part of the timer update data in seconds.

[0050] The Timer field and Delay field are not processed in the ACK frame and CONFIRM_ACK frame sent from the sink to the source. Whether they are updated is controlled by the bandwidth adjustment process from the sink to the source.

[0051] In this embodiment, the Timer field and the 3*8-bit Delay field defined in the original OAM frame are used to accurately transmit and update the timer timeout control mechanism in real time during the sending and receiving of REQ and CONFIRM frames. This is used to solve the problem of long-term system fluctuations after bandwidth adjustment timeout in existing OSU lossless bandwidth modulation technology.

[0052] The Timer field carries the integer portion in seconds, and the Delay field carries the fractional portion, both defined in 5-millisecond units. Upon receiving REQ and CONFIRM frames from upstream, intermediate and sink nodes update the remaining time in their local timers based on the Timer and Delay fields. ACK and CONFIRM_ACK frames sent upstream by intermediate and sink nodes do not process the Timer and Delay fields; their updates are controlled by the bandwidth adjustment process from the sink to the source.

[0053] According to the above strategy, the timer time of the source node will become the timer baseline value of the remaining nodes in the entire system. The timer time of the downstream node will inherit the software processing delay of each upstream node based on the baseline value. The cumulative sum is the time cost consumed by this patent to solve the problem of long-term system fluctuations after bandwidth adjustment timeout.

[0054] The Timer field and Delay field are not processed in the ACK frame and CONFIRM_ACK frame sent from the sink to the source. Whether they are updated is controlled by the bandwidth adjustment process from the sink to the source.

[0055] Reference Figure 7 In the bandwidth adjustment process from source to sink, the ACK_IND field in the OAM frame sent from the sink to the source must be valid, indicating that the BW_ADJ_ACK field is valid. The Timer and Delay fields in this OAM frame are shared with the REQ and CONFIRM frames (valid as indicated by the REQ_IND field) sent from the sink to the source in the bandwidth adjustment process from sink to source.

[0056] Therefore, the Timer and Delay fields in the OAM frame sent from the sink to the source are updated along with the bandwidth adjustment process from the sink to the source and are not related to the bandwidth adjustment process from the source to the sink.

[0057] In a specific embodiment, referring to Figure 8 , Figure 8This figure illustrates the software processing flow when a source node sends REQ and CONFIRM frames in a bandwidth increase scenario. After the current bandwidth adjustment task begins, the source node determines whether the local timer has expired. If so, it handles the timer timeout action, completing the current task round. If not, it calculates the task processing period of the previous bandwidth adjustment task, estimates the maximum potential task period based on a formula, extracts the remaining time on the local timer, calculates the Timer and Delay fields, and sends a REQ or CONFIRM frame downstream with the Timer and Delay fields filled in, completing the current task round.

[0058] Reference Figure 9 , Figure 9 This diagram illustrates the software processing flow for an intermediate node receiving an upstream REQ or CONFIRM frame and sending a downstream REQ or CONFIRM frame in a bandwidth increase scenario. After the current bandwidth adjustment task begins, the intermediate node determines whether its local timer has expired. If so, it handles the timer timeout action, completing the current task. If not, it extracts the Timer and Delay fields from the upstream REQ or CONFIRM frame and updates its local timer. It then calculates the task processing period for the previous bandwidth adjustment task. After estimating the potential maximum task period using a formula, it extracts the remaining time on the local timer, calculates the Timer and Delay fields, and sends a REQ or CONFIRM frame with the Timer and Delay fields filled in to the downstream, completing the current task.

[0059] Reference Figure 10 , Figure 10 This figure illustrates the software processing flow when a sink node receives an upstream REQ or CONFIRM frame in a bandwidth increase scenario. After the current bandwidth adjustment task begins, the sink node determines whether its local timer has expired. If so, it handles the timer timeout action, completing the task. If not, it extracts the Timer and Delay fields from the upstream REQ or CONFIRM frame and updates the local timer, completing the task.

[0060] In summary, this invention solves the technical problem of system fluctuations far exceeding the timeout period configured by the network management due to actual differences between nodes in specific timer timeout scenarios. This problem is particularly prominent in interoperability scenarios between different manufacturers. Once the network management reports that the adjustment timeout failed, the user can determine that the entire system has returned to stability and can begin the next adjustment.

[0061] Providing accurate timer refresh strategies makes the process of logical analysis of inter-node flows and actions clearer when locating engineering faults.

[0062] In a second aspect, an embodiment of the present application further provides an OSU lossless bandwidth adjustment system.

[0063] In one embodiment, referring to Figure 11 , Figure 11 This is a functional module diagram of an embodiment of the OSU lossless bandwidth adjustment system of this application. Figure 11 As shown, the OSU lossless bandwidth adjustment system includes: The processing module 1 is used to obtain the software processing delay of each node on the optical transmission path.

[0064] Configuration module 2 is used to add a timer control instruction to the REQ frame and CONFIRM frame sent sequentially from the source end to the sink end. The timer control instruction includes timer update data, which is the sum of the remaining time of the timer of the node and the software processing delay of the node.

[0065] The control module 3 is used to control the intermediate node and the sink node to start the timer when the REQ frame is received for the first time, and to update the remaining time of the timer of the node according to the timer update data each time the REQ frame and CONFIRM frame are received.

[0066] In this embodiment, based on the remaining duration of the timer of the source node, when updating the remaining duration of the timer of each node on the path, the sum of the remaining duration of the timer of the upstream node and the software processing delay is used as the timer update data to update the remaining duration of the timer of the downstream node, thereby ensuring that the upstream node times out before the downstream node, avoiding the problem of false startup caused by receiving the REQ frame sent by the upstream node when the downstream node has timed out, and providing a precise timer refresh strategy, so that the process action logic analysis process between nodes is clearer when locating engineering problem faults.

[0067] Furthermore, in one embodiment, the configuration module 2 is also used to configure the Timer field and the Delay field in the REQ frame and the CONFIRM frame sent sequentially from the source end to the destination end, the Timer field is used to store the integer part of the timer update data in seconds, and the Delay field is used to store the decimal part of the timer update data in seconds.

[0068] The configuration module 2 is further configured to not process the Time field and the Delay field in the ACK frame and the CONFIRM_ACK frame sent sequentially from the sink to the source. Whether the Time field and the Delay field are updated is controlled by the bandwidth adjustment process from the sink to the source.

[0069] The functional implementation of each module in the above-mentioned OSU lossless bandwidth adjustment system corresponds to each step in the above-mentioned OSU lossless bandwidth adjustment method embodiment, and their functions and implementation processes are not repeated here one by one.

[0070] It should be noted that the serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0071] The terms "including" and "having" and any variations thereof in the specification and claims of this application and the above-mentioned drawings are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but optionally includes steps or units that are not listed, or optionally includes other steps or units inherent to these processes, methods, products or devices. The terms "first", "second" and "third" are used to distinguish different objects, etc., and do not represent a sequence, nor do they limit the "first", "second" and "third" to different types.

[0072] In the description of the embodiments of this application, the words "exemplary," "for example," or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary," "for example," or "for example" in the embodiments of this application should not be construed as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary," "for example," or "for example" is intended to present the relevant concepts in a concrete manner.

[0073] In the description of the embodiments of the present application, unless otherwise specified, " / " means or. For example, A / B can mean A or B. The "and / or" in the text is merely a description of the association relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of the present application, "plurality" means two or more than two.

[0074] In some processes described in the embodiments of the present application, multiple operations or steps are included that appear in a specific order. However, it should be understood that these operations or steps may not be performed in the order in which they appear in the embodiments of the present application or may be performed in parallel. The sequence numbers of the operations are only used to distinguish between different operations, and the sequence numbers themselves do not represent any order of execution. In addition, these processes may include more or fewer operations, and these operations or steps may be performed in sequence or in parallel, and these operations or steps may be combined.

[0075] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus the necessary general hardware platform. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product. The computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes a number of instructions for enabling a terminal device to execute the above-mentioned methods of each embodiment of the present application.

[0076] The above are only preferred embodiments of the present application and do not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A method for adjusting OSU lossless bandwidth, characterized in that: The method comprises: Obtain the software processing delay of each node on the optical transmission path; A timer control instruction is added to each of the REQ and CONFIRM frames sent sequentially from the source to the sink. The timer control instruction contains timer update data, which is the sum of the remaining time of the local timer and the software processing delay of the local node. The intermediate node and the sink node start a timer when they first receive the REQ frame, and update the remaining duration of the timer of the local node according to the timer update data each time they receive the REQ frame and the CONFIRM frame.

2. The OSU lossless bandwidth adjustment method according to claim 1, wherein: The software processing delay is the sum of the task processing cycle and the code response time.

3. The OSU lossless bandwidth adjustment method according to claim 2, wherein: The task processing cycle is used as the software processing delay.

4. The OSU lossless bandwidth adjustment method according to claim 2, wherein: The method further comprises: By obtaining a sample set of task processing cycles in the history of each node, an upper limit value of the task processing cycle is obtained, and the upper limit value is used as the software processing delay for calculating timer update data.

5. The OSU lossless bandwidth adjustment method according to claim 4, wherein: The upper limit value is obtained by using the following formula: Wherein, Sm represents the upper limit value, n represents the number of samples in the task processing cycle sample set, Smax represents the maximum value in the task processing cycle sample set, and k1 and k2 are adjustment coefficients.

6. The OSU lossless bandwidth adjustment method according to claim 1, wherein: The method further comprises: The REQ frame and CONFIRM frame sent from the source to the sink are both configured with the Timer field and the Delay field. The Timer field is used to store the integer part of the timer update data in seconds, and the Delay field is used to store the fractional part of the timer update data in seconds.

7. The OSU lossless bandwidth adjustment method according to claim 1, wherein: The method further comprises: The Timer field and Delay field are not updated in the ACK frame and CONFIRM_ACK frame sent sequentially from the sink to the source.

8. An OSU lossless bandwidth adjustment system, characterized in that: The system comprises: A processing module, which is used to obtain the software processing delay of each node on the optical transmission path; A configuration module, configured to add a timer control instruction to each of the REQ and CONFIRM frames sent sequentially from the source to the sink, wherein the timer control instruction includes timer update data, which is the sum of the remaining time of the timer of the local node and the software processing delay of the local node; The control module is used to control the intermediate node and the sink node to start the timer when the REQ frame is received for the first time, and to update the remaining time of the timer of the node according to the timer update data each time the REQ frame and the CONFIRM frame are received.

9. The OSU lossless bandwidth adjustment system according to claim 8, wherein: The task processing cycle is used as the software processing delay.

10. The OSU lossless bandwidth adjustment system according to claim 8, wherein: The configuration module is further configured to configure a Timer field and a Delay field in both a REQ frame and a CONFIRM frame sequentially sent from the source end to the sink end, wherein the Timer field is used to store the integer part of the timer update data in seconds, and the Delay field is used to store the fractional part of the timer update data in seconds; The configuration module is further configured to not update the Timer field and the Delay field in both the ACK frame and the CONFIRM_ACK frame sent in sequence from the sink end to the source end.

Images