Managing power states of aggregated links of network devices

Abstract

A first network device may generate a first protocol data unit (PDU) identifying a request for transitioning from a power-on state to a power-sleep state, and may provide the first PDU to a second network device. The first network device may receive a second PDU identifying a link of the second network device to transition from the power-on state to the power-sleep state, and may generate a third PDU identifying a link of the first network device to transition from the power-on state to the power-sleep state. The first network device may provide a third PDU to the second network device, and may transition a link of the first network device and a link of the second network device from a power on state to a power sleep state based on the second PDU and the third PDU.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This patent application claims the priority of Indian Patent Application No. 202341064503, filed on September 26, 2023, entitled “SYSTEMS AND METHODS FOR PROVIDING ENERGY EFFICIENT NETWORKS”. The disclosure of the prior application is considered as a part of this patent application and is incorporated by reference into this patent application. Background Art

[0003] The network planner designs the network for worst-case traffic conditions while also catering for various potential resilience scenarios. The capacity of the network may be underutilized due to traffic conditions, and actual traffic patterns may exhibit cyclicality with respect to overall network utilization. Summary of the invention

[0004] Some implementations described herein relate to a method. The method may include generating, by a first network device, a first protocol data unit (PDU) identifying a request to transition from a power-on state to a power-sleep state, and providing the first PDU to a second network device. Power sleep is a link state in which the power consumption of a link is less than that of a power-on state. The implementation may completely or partially disconnect the power supply of the link so that the link is in a power-sleep state. The method may include receiving, by a control channel link, a second PDU identifying a link of a second network device to be transitioned from a power-on state to a power-sleep state, and generating a third PDU identifying a link of a first network device to be transitioned from a power-on state to a power-sleep state. The method may include providing a third PDU to the second network device, and transitioning a link of the first network device and a link of the second network device from a power-on state to a power-sleep state based on the second PDU and the third PDU.

[0005] In some embodiments of the method according to the present disclosure, it further includes: exchanging one or more periodic link aggregation control protocol PDUs with the second network device.

[0006] In some embodiments of the method according to the present disclosure, each of the first PDU, the second PDU and the third PDU is a Link Aggregation Control Protocol PDU.

[0007] In some embodiments of the method according to the present disclosure, the method further includes: receiving a confirmation of the first PDU from the second network device.

[0008] In some embodiments of the method according to the present disclosure, the method further includes: providing a confirmation of the second PDU to the second network device.

[0009] In some embodiments of the method according to the present disclosure, transitioning the link of the first network device and the link of the second network device from a power-on state to a power-sleep state includes: powering off ports associated with the link of the first network device and the link of the second network device.

[0010] In some embodiments of the method according to the present disclosure, transitioning a link of a first network device and a link of a second network device from a power-on state to a power-sleep state includes: determining whether a sleep timer has expired; and based on determining that the sleep timer has expired, transitioning the link of the first network device and the link of the second network device from the power-on state to the power-sleep state.

[0011] Some implementations described herein relate to a first network device. The first network device may include one or more memories and one or more processors. The one or more processors may be configured to generate a first PDU identifying a request to transition from a power-on state to a power-sleep state, and provide the first PDU to a second network device. The one or more processors may be configured to receive a second PDU identifying a link of a second network device to be transitioned from a power-on state to a power-sleep state, and generate a third PDU identifying a link of a first network device to be transitioned from a power-on state to a power-sleep state. The one or more processors may be configured to provide a third PDU to the second network device, and determine whether a sleep timer has expired based on the second PDU and the third PDU. The one or more processors may be configured to transition a link of the first network device and a link of the second network device from a power-on state to a power-sleep state based on determining that the sleep timer has expired.

[0012] In some embodiments of the first network device according to the present disclosure, one or more processors are further used to: provide a fourth PDU to the second network device, identifying a re-transition of a link of the first network device from a power-sleep state to a power-on state; and in response to the fourth PDU, receive from the second network device a fifth PDU, identifying a re-transition of a link of the second network device from a power-sleep state to a power-on state.

[0013] In some embodiments of the first network device according to the present disclosure, one or more processors are further used to: verify that the link of the first network device and the link of the second network device are available based on the fourth PDU and the fifth PDU; and based on the verification that the link of the first network device and the link of the second network device are available, transition the link of the first network device and the link of the second network device from a power-sleep state to a power-on state.

[0014] In some embodiments of the first network device according to the present disclosure, one or more processors are further used to: determine that one of the links of the first network device or the links of the second network device is unavailable based on the fourth PDU and the fifth PDU; and generate an alarm based on the determination that one of the links of the first network device or the links of the second network device is unavailable.

[0015] In some embodiments of the first network device according to the present disclosure, the one or more processors are further configured to: receive actual business time period data; and determine predicted business time period data based on the actual business time period data.

[0016] In some embodiments of the first network device according to the present disclosure, one or more processors are further used to: utilize an action model to process predicted business time period data and actual business time period data to determine whether to transition the link of the first network device to a power sleep state, whether to transition the link of the first network device to a power-on state, or whether to perform no link action on the link of the first network device.

[0017] In some embodiments of the first network device according to the present disclosure, the one or more processors are further configured to: based on a determination that the link action is not to be performed on the link of the first network device, perform no link action on the link of the first network device.

[0018] Some implementations described herein relate to a non-transitory computer-readable medium storing an instruction set. The instruction set, when executed by one or more processors of a first network device, can cause the first network device to generate a first PDU identifying a request to transition from a power-on state to a power-sleep state, and provide the first PDU to a second network device. The instruction set, when executed by one or more processors of the first network device, can cause the first network device to receive an acknowledgment of the first PDU from the second network device, and receive a second PDU identifying a link of the second network device to be transitioned from the power-on state to the power-sleep state. The instruction set, when executed by one or more processors of the first network device, can cause the first network device to generate a third PDU identifying a link of the first network device to be transitioned from the power-on state to the power-sleep state, and provide the third PDU to the second network device. The instruction set, when executed by one or more processors of the first network device, can cause the first network device to transition a link of the first network device and a link of the second network device from the power-on state to the power-sleep state based on the second PDU and the third PDU.

[0019] In some embodiments of the non-transitory computer-readable medium according to the present disclosure, the one or more instructions further cause the first network device to: exchange one or more periodic Link Aggregation Control Protocol PDUs with the second network device.

[0020] In some embodiments of the non-transitory computer-readable medium according to the present disclosure, one or more instructions that cause a first network device to transition a link of the first network device and a link of a second network device from a power-on state to a power-sleep state cause the first network device to: cause ports associated with the link of the first network device and the link of the second network device to be powered off.

[0021] In some embodiments of the non-transitory computer-readable medium according to the present disclosure, one or more instructions further cause the first network device to: provide a fourth PDU to the second network device that identifies the re-transition of the link of the first network device from a power-sleep state to a power-on state; in response to the fourth PDU, receive from the second network device a fifth PDU that identifies the re-transition of the link of the second network device from a power-sleep state to a power-on state; verify based on the fourth PDU and the fifth PDU that the link of the first network device and the link of the second network device are available; and based on the verification that the link of the first network device and the link of the second network device are available, transition the link of the first network device and the link of the second network device from the power-sleep state to the power-on state.

[0022] In some embodiments of the non-transitory computer-readable medium according to the present disclosure, one or more instructions further cause the first network device to: receive actual business time period data; determine predicted business time period data based on the actual business time period data; and process the predicted business time period data and the actual business time period data using an action model to determine whether to transition the link of the first network device to a power sleep state, whether to transition the link of the first network device to a power-on state, or whether to perform no link action on the link of the first network device.

[0023] In some embodiments of the non-transitory computer-readable medium according to the present disclosure, the one or more instructions further cause the first network device to: based on the determination that the link action is not to be performed on the link of the first network device, perform no link action on the link of the first network device. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1A-1E is a diagram of an example associated with management of a power state of an aggregated link of a network device.

[0025] Figure 2 is a diagram of an example environment in which the systems and / or methods described herein may be implemented.

[0026] Figure 3 and Figure 4 yes Figure 2 A diagram of example components of one or more devices.

[0027] Figure 5is a flow chart of an example process for managing the power state of an aggregated link of a network device. DETAILED DESCRIPTION

[0028] The following detailed description of example implementations refers to the accompanying drawings.The same reference numbers in different drawings may identify the same or similar elements.

[0029] In many networks, there is a large difference between peak network utilization and non-peak network utilization, and the traffic pattern exhibits cyclical nature. Controlling the power life cycle of network links (e.g., disabling links during non-peak network utilization and re-enabling links during peak network utilization) can take advantage of power saving opportunities in the network. However, the sudden power-off and power-on of links may result in loss of traffic due to the removal of active links from a set of forwarding next-hop network devices. For example, links in a link aggregation group (LAG) must be gently added and removed from the LAG to minimize any traffic loss during link state changes. Current techniques for disabling links (e.g., for energy efficiency) are unable to completely power off the links, which prevents power off of various components in the network device hierarchy (e.g., optical transceivers, lasers, etc.). Therefore, current techniques for disabling links consume computing resources (e.g., processing resources, memory resources, communication resources, etc.), network resources, etc., which are associated with failure to completely power off the links, failure to power off components of network devices associated with partially powered off links, loss of traffic due to sudden disabling of links, and the like.

[0030] Some implementations described herein relate to a network device that manages a power state of an aggregated link of a network device. For example, a first network device may generate a first protocol data unit (PDU) that identifies a request to transition from a power-on state to a power-sleep state, and may provide the first PDU to a second network device. The first network device may receive a second PDU that identifies a link of a second network device to be transitioned from a power-on state to a power-sleep state, and may generate a third PDU that identifies a link of the first network device to be transitioned from a power-on state to a power-sleep state. The first network device may provide a third PDU to the second network device, and may transition the link of the first network device and the link of the second network device from the power-on state to the power-sleep state based on the second PDU and the third PDU.

[0031] In this manner, the network device manages the power state of the aggregated links of the network device. For example, the network device can utilize enhancements to the Link Aggregation Control Protocol (LACP) to implement a gentle transition of the power state of the links in the LAG. The network device can also utilize a model to process actual business (e.g., telemetry data within the system) and predicted business (e.g., predicted telemetry data) to determine the power state transition of the links in the LAG, manage the power state transition of the links in the LAG, and so on. Therefore, the network device saves computing resources, network resources, etc., which would otherwise be consumed due to failure to completely power off the link, failure to power off components of the network device associated with the partially powered off link, loss of business due to abrupt disabling of the link, and so on.

[0032] Figure 1A-1E 1 is a diagram of an example 100 associated with management of power states of aggregated links of a network device. Figure 1A-1E As shown, example 100 includes an endpoint device and a server device associated with a network of network devices. Additional details of the endpoint devices, server devices, networks, and network devices are provided elsewhere herein.

[0033] like Figure 1A As shown, the network may include a first network device (e.g., network device 1) and a second network device (e.g., network device 2). A LAG having multiple links may be provided between network device 1 and network device 2. Each link of the LAG may include a state, such as a power-on state, a power-sleep state, a power-off state, etc. In the power-on state, the link may have been discovered and may be participating in the reception and / or transmission of data frames. In the power-sleep state, the link may have been discovered and may be powered off (e.g., offline) by a protocol. In the power-off state, the link may be administratively powered off.

[0034] like Figure 1A As further shown by reference numeral 105, network device 1 and / or network device 2 may receive traffic destined for a destination. For example, network device 1 may receive traffic destined for other endpoint devices and / or a server device from an endpoint device. In another example, network device 2 may receive traffic destined for one or more of the endpoint devices from a server device. In some implementations, network device 1 and / or network device 2 may receive traffic from another network device of the network.

[0035] like Figure 1AAs further shown in the figure 110, the network device 1 and the network device 2 can exchange periodic LACP PDUs via one or more links of the LAG. For example, the format of each of the periodic LACP PDUs may include a new or customized type-length-value (TLV) parameter. The new TLV parameter may include a power management TLV (PM-TLV) parameter for managing the power state of an aggregated link (e.g., a link in a LAG). The network device 1 and the network device 2 can exchange periodic LACP PDUs based on a timer setting (e.g., a slow or fast timer setting). In some implementations, in addition to the periodic LACP PDUs, the network device 1 and / or the network device 2 may also transmit LACP PDUs when information needs to be transmitted to the opposite port. Each LACP PDU may include a link affinity that describes the state of the link between the local network device and the opposite network device. When the link is in a power-off state, the state of the link may not be exchanged between the local network device and the opposite network device.

[0036] In some implementations, various applications (such as routing protocols, telemetry settings, configuration settings, etc.) can interact with LACP to transition the link to the desired link state. LACP can interact with platform management software (e.g., of a network device) to power off and / or power on the link. In some implementations, two types of PM-TLVs can be encoded in the LACP PDU: PM-TLV type 1, which can be exchanged on links eligible for power state transitions, and PM-TLV control channel types. The PM-TLV control channel type can be associated with at least one member link (e.g., a control channel link) that will not participate in the power state transition. The current power state of all links in the LAG can be periodically exchanged by peer network devices via the control channel link of the LAG. The control channel link may not be powered off.

[0037] PM-TLV can enable the link to participate in dynamic power management. When PM-TLV is not present in the LACP PDU, the link may not participate in dynamic power management. Figure 1AAs further shown, the LACP PDU may include a TLV type element (such as a PM-TLV type 1 or a PM-TLV control channel type), a length element, and a data element (such as a state flag (e.g., for PM-TLV type 1) or control channel data). The state flag may be used to communicate, exchange, and control future state transitions of the link. The state flag may include a current state (CS) for describing the current state of the link, a desired state (DS) for describing a request for a change in the state of the link, an acknowledgment (Ack) of the state change request by a peer network device, and a control channel (CC) having a value (e.g., "1") indicating that the link is used to manage the states of other links in the LACP LAG. The control channel data may include an array that captures the power states of all links in the LACP LAG. The control channel data may be represented as a triple (e.g., local port link, local port current state, and desired peer state). For example, if there are N links in the LACP LAG, all current states may be encoded as an array value.

[0038] In some implementations, the LACP PDU may be associated with a power sleep action timer element. After negotiating with a peer network device to power off a link, each peer network device may wait for the power sleep action timer to expire before powering off one side of the link. The power sleep action timer may be derived based on various parameters, such as, for example, the time required to clear a queue. In some implementations, the power sleep action timer may be implementation-specific and not exchanged via LACP. In some implementations, information associated with the peer network device (e.g., discovered by LACP) may be stored in a local database of the network device. The network device may utilize such information to manage the power state of the link, and may retain the information even when the link enters a power sleep state. When the link is powered on again, the network device may re-verify the information.

[0039] Figure 1BA call flow diagram associated with transitioning a link of a LAG from a power-on state to a power-sleep state is depicted. In some implementations, state transitions associated with a link may occur asynchronously. An example link connects network device 1 and network device 2. A link is a physical link identified by a link identifier X (e.g., link X) at network device 1 and a link identifier Y (e.g., link Y) at network device 2. In some implementations, network device 1 and network device 2 may be associated with transitioning a link from a power-on state to a power-sleep state, and a wait timer may be utilized before transitioning the link. Network device 1 may be associated with a link (e.g., link X) to be transitioned from a power-on state to a power-sleep state, and network device 2 may be associated with a link (e.g., link Y) to be transitioned from a power-on state to a power-sleep state. Initially, both network devices may transmit periodic LACP PDUs with states {CS=Power_on, DS=Power_on, CC=false}. For example, at time T0, network device 1 may transmit a first periodic LACP PDU to network device 2, and at time T1, network device 2 may receive the first periodic LACP PDU. At time T2, network device 2 may transmit a second periodic LACP PDU to network device 1, and at time T3, network device 1 may receive the second periodic LACP PDU.

[0040] Network device 1 may initiate a transition from a power-on state to a power-sleep state. Thus, at time T4, network device 1 may transmit a first LACP PDU to network device 2 (e.g., where DS is set to power-sleep). At time T5, network device 2 may receive a first LACP PDU. At time T6, network device 2 may determine that network device 2 is ready to transition a link (e.g., link Y) from a power-on state to a power-sleep state, and may generate a second LACP PDU (e.g., where DS is set to power-sleep and Ack is set to equal 1). At time T6, network device 2 may transmit a second LACP PDU to network device 1. At time T7, network device 2 may generate a third LACP PDU that identifies the TLV type of the control channel, link Y, the desired power-sleep state of the opposite end, and the power-on state of the local end. At time T7, network device 2 may transmit a third LACP PDU to network device 1 via the control channel. At time T8 , network device 1 may receive the second LACP PDU, and at time T9 , network device 1 may receive a third LACP PDU via the control channel.

[0041] At time T10, network device 1 may generate a fourth LACP PDU (e.g., where DS is set to power sleep and Ack is set to equal 1). At time T10, network device 1 may transmit a fourth LACP PDU to network device 1, thereby completing a three-way handshake between network device 1 and network device 2. The three-way handshake may enable network device 1 and / or network device 2 to generate a link alarm to distinguish between normal link power sleep and physical link failure events when transitioning links, and so on. At time T11, network device 1 may generate a fifth LACP PDU, which identifies the TLV type of the control channel, link X, the expected power sleep state of the other end, and the power-on state of the local end. At time T11, network device 1 may transmit a fifth LACP PDU to network device 1 via the control channel. At time T12, network device 2 may receive the fourth LACP PDU, and at time T13, network device 2 may receive the fifth LACP PDU via the control channel. At times T10 and T12, network device 1 and network device 2 may empty link level queues and may stop transmitting traffic on links X and Y. Both network device 1 and network device 2 may continue to accept frames.

[0042] Network device 1 and network device 2 may wait for the expiration of the power sleep timer before transitioning links X and Y from the power-on state to the power sleep state. When the power sleep timer expires (e.g., at time T14), network device 1 may power off the port associated with link X. Network device 2 may detect the link disconnection, and may power off the port associated with link Y based on detecting the link disconnection. Once the link is powered off at both network devices, network device 1 and network device 2 may utilize the control channel to exchange LACP PDUs having a local state set to power sleep and a peer desired state.

[0043] In some implementations, since the two network devices independently determine whether the link state should be changed to the power-down state or the link state should be maintained in the power-on state, the network device 2 may not agree to the request to enter the power-down state. In such an implementation, the network device 2 may confirm the request by setting the confirmation bit to zero and setting the desired state to the power-on state. Upon receiving the confirmation set to zero, the network device 1 may not take any further action.

[0044] Figure 1CA call flow diagram associated with transitioning a link of a LAG from a power sleep state to a power on state is depicted. In some implementations, the state transition associated with the link may occur asynchronously. In some implementations, network device 1 and network device 2 may be associated with transitioning a link from a power sleep state to a power on state. Network device 1 may be associated with a link (e.g., link X) to be transitioned from a power sleep state to a power on state, and network device 2 may be associated with a link (e.g., link Y) to be transitioned from a power sleep state to a power on state. Initially, both network devices may transmit periodic LACP PDUs (e.g., via a control channel), wherein the TLV type of the control channel and the local port are set to a power sleep state. For example, at time T0, network device 1 may transmit a first periodic LACP PDU to network device 2, and at time T1, network device 2 may receive the first periodic LACP PDU. At time T2, network device 2 may transmit a second periodic LACP PDU to network device 1, and at time T3, network device 1 may receive a second periodic LACP PDU.

[0045] Network device 1 may initiate a transition from a power-sleep state to a power-on state. Thus, at time T4, network device 1 may transmit a first LACP PDU to network device 2 via a control channel (e.g., where the local port is associated with link X, the local port state is set to the power-on state, and the opposite port expected state is set to the power-on state). At time T5, network device 2 may receive the first LACP PDU. Based on the first LACP PDU, network device 1 may be powered on on link X, and network device 2 may be powered on on link Y. At time T6, network device 2 may transmit a second LACP PDU to network device 1 via a control channel (e.g., where the local port is associated with link Y, the local port state is set to the power-on state, and the opposite port expected state is set to the power-on state). At time T7, network device 1 may receive a second LACP PDU.

[0046] like Figure 1CAs shown, network device 1 and network device 2 can determine whether a link (e.g., link X and Y) transitions from a power-sleep state to a power-on state before the link-up timer expires. If the link transitions to the power-on state before the link-up timer expires, network devices 1 and 2 can verify that the link is available (e.g., at the media access control (MAC) layer and the physical (PHY) layer). If the link fails to transition to the power-on state before the link-up timer expires, network devices 1 and 2 can determine that the link is unavailable and a fault alarm can be generated. Network devices 1 and 2 can handle the reduction in LAG bandwidth by rerouting traffic. In some implementations, if a control channel link is unavailable (e.g., due to problems such as control channel link failure) and is detected, network devices 1 and 2 can automatically power on all power-sleep links and a new control channel can be selected.

[0047] Figure 1D and Figure 1E An example power saving method based on the telemetry data of the above-mentioned protocol enhancement is described. Figure 1D As shown in the figure 115, the network device 1 can receive actual business time period data. For example, the business pattern on the LAG (e.g., LAG telemetry data) can be calculated within a time period (e.g., a fifteen-minute time interval in a day, referred to as a "fifteen-minute interval"). The business pattern can correspond to the actual business time period data. In some implementations, the network device 1 can continuously receive the actual business time period data, can periodically receive the actual business time period data, and so on. The network device 1 can store the actual business time period data in a data structure (e.g., a database, a table, a list, etc.) associated with the network device 1.

[0048] like Figure 1D As further shown in the figure 120, the network device 1 can determine the predicted business time period data based on the actual business time period data. For example, the network device 1 may include a prediction model that determines the predicted business time period data based on the actual business time period data. The network device 1 can use the prediction model to process the actual business time period data to generate the predicted business time period data. In some implementations, during non-peak hours, when the actual business time period data matches the predicted business time period data, the model can disable some LAG member links by transitioning the link to a power sleep state. In response to an increase in the predicted business time period data or when the actual business time period data does not match the predicted business time period data, the model can cause the link to transition from a power sleep state to a power on state.

[0049] like Figure 1EAs shown in the accompanying drawings and reference numeral 125, the network device 1 can utilize an action model to process predicted service time period data and actual service time period data to determine whether to transition a link to a power sleep state, whether to transition a link to a power-on state, or whether not to perform a link action. For example, the network device 1 can include an action model that determines whether to transition a link to a power sleep state, whether to transition a link to a power-on state, or whether not to perform a link action based on the predicted service time period data and the actual service time period data. In some implementations, the action model can calculate variables at the beginning of each interval. The variables can include the maximum estimated LAG utilization (Pm) of the interval; the protection bandwidth (Pg), which provides a safety margin and is a user-configurable parameter that depends on internal queue settings, traffic bursts, hash efficiency, link-on time, etc.; a high threshold for the action model (e.g., Pt = Pm + 2Pg) (e.g., the maximum predicted value with protection for the interval); the instantaneous bandwidth utilization (Pc) (e.g., per second, per five seconds, etc.); the total LAG bandwidth (L bw ), which is calculated as the sum of all LAG links; and so on.

[0050] The action model can determine that the link should be transitioned to the power sleep state based on the following process. At the beginning of each interval, if (Pt < L bw ) and (Pc < Pt), the action model can determine whether any of the member links can be turned off while still ensuring that Pt < (L bw - member link bandwidth). If a member link can be turned off, the action model can transition the member link to the power sleep state. The action model can select eligible member links based on configured power priority settings or iterative logic across eligible links. The action model can update L bw (e.g., L bw = L bw - power sleep link bandwidth). When the LAG includes unequal member links, various combinations of the links can be put into power sleep. For example, link combinations can be selected such that the maximum power gain can be obtained while ensuring that the available LAG bandwidth is greater than the predicted value.

[0051] The action model can determine that the link should be transitioned to the power-on state based on the following process. The action model can continuously monitor the instantaneous traffic pattern (Pc). When the instantaneous traffic Pc ≥ Pm, additional links can be transitioned from the power sleep state to the power-on state. The action model can recalculate and / or update Pm (e.g., Pm = Pm + new link bandwidth), and can update L bw (e.g., L bw = L bw+ power-down link bandwidth). In some implementations, the suppression model can be used when the traffic is significantly less than Pt during the interval. The action model can keep the link in the power-on state until the next reactive interval (e.g., interval) to avoid further link transitions. In some implementations, at the beginning of the reactive interval, if Pt>L bw , then the action model can connect an additional minimum set of links so that L bw Greater than Pt.

[0052] Since a LAG may include multiple member links, the network device initiating the transition to the power sleep state may identify the link to be transitioned based on the link power priority of the eligible links. The link power priority may be matched for two peer network devices. In addition, in the absence of link power priority, the network device may reject the request or accept the request based on the estimated bandwidth. In some implementations, the interval interval may be similar at the two peer network devices.

[0053] In some implementations, if a link is in a power-down state for a long period of time (eg, multiple hours a day), the periodic power-up and power-down mechanism can be enhanced to check link health and generate an alert if necessary.

[0054] In this manner, the network device manages the power state of the aggregated links of the network device. For example, the network device can utilize enhancements to LACP to implement a gentle transition of the power state of the links in the LAG. The network device can also utilize a model to process actual business (e.g., telemetry data within the system) and predicted business (e.g., predicted telemetry data) to determine the power state transition of the links in the LAG, manage the power state transition of the links in the LAG, and so on. Therefore, the network device saves computing resources, network resources, etc., which would otherwise be consumed due to failure to completely power off the link, failure to power off components of the network device associated with the partially powered off link, loss of business due to abrupt disabling of the link, and so on.

[0055] As mentioned above, Figure 1A-1E Provided as an example. Other examples can be found with Figure 1A-1E Different from what is described in . Figure 1A-1E The number and arrangement of devices shown are provided as examples. Figure 1A-1E There may be more devices, fewer devices, different devices, or differently arranged devices than shown. Figure 1A-1E Two or more of the devices shown may be implemented in a single device, or Figure 1A-1E The single device shown may be implemented as multiple distributed devices. Additionally or alternatively, Figure 1A-1EThe illustrated set of devices (e.g., one or more devices) may perform the operations described as being performed by Figure 1A-1E Another group of devices is shown performing one or more functions.

[0056] Figure 2 2 is a diagram of an example environment 200 in which the systems and / or methods described herein may be implemented. Figure 2 As shown, environment 200 may include endpoint device 210, a set of network devices 220 (shown as network device 220-1 through network device 220-N), server device 230, and network 240. The devices of environment 200 may be interconnected via wired connections, wireless connections, or a combination of wired and wireless connections.

[0057] Endpoint device 210 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information, such as the information described herein. For example, endpoint device 210 may include a mobile phone (e.g., a smart phone or a radio phone), a laptop computer, a tablet computer, a desktop computer, a handheld computer, a gaming device, a wearable communication device (e.g., a smart watch, smart glasses, a heart rate monitor, a fitness tracker, smart clothing, smart jewelry, or a head-mounted display), a network device, or a similar type of device. In some implementations, endpoint device 210 may receive network traffic from other endpoint devices 210 and / or server device 230 via network 240 and / or may provide network traffic to other endpoint devices 210 and / or server device 230 (e.g., by routing packets using network device 220 as an intermediary).

[0058] The network device 220 includes one or more devices capable of receiving, processing, storing, routing and / or providing services (e.g., packets or other information or metadata) in a manner described herein. For example, the network device 220 may include a router, such as a label switching router (LSR), a label edge router (LER), an ingress router, an egress router, a provider router (e.g., a provider edge router or a provider core router), a virtual router, or another type of router. Additionally or alternatively, the network device 220 may include a gateway, a switch, a firewall, a hub, a bridge, a reverse proxy, a server (e.g., a proxy server, a cloud server, or a data center server), a load balancer, and / or similar devices. In some implementations, the network device 220 may be a physical device implemented in a housing such as a chassis. In some implementations, the network device 220 may be a virtual device implemented by one or more computer devices in a cloud computing environment or a data center. In some implementations, a group of network devices 220 may be a group of data center nodes for routing traffic flows through the network 240.

[0059] Server device 230 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information (such as the information described herein). For example, server device 230 may include a laptop computer, a tablet computer, a desktop computer, a group of server devices, or similar types of devices associated with a multicast service. In some implementations, server device 230 may receive information (e.g., a multicast service) from endpoint device 210 via network 240 and / or transmit information to endpoint device 210 (e.g., by routing packets using network device 220 as an intermediary).

[0060] The network 240 includes one or more wired and / or wireless networks. For example, the network 240 may include a packet-switched network, a cellular network (e.g., a fifth generation (5G) network, a fourth generation (4G) network such as a long-term evolution (LTE) network, a third generation (3G) network, a code division multiple access (CDMA) network, a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., a public switched telephone network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, a fiber-based network, a cloud computing network, etc., and / or a combination of these or other types of networks.

[0061] Figure 2 The number and arrangement of devices and networks shown are provided as examples. Figure 2 There may be more devices and / or networks, fewer devices and / or networks, different devices and / or networks, or differently arranged devices and / or networks than shown. Figure 2 Two or more of the devices shown may be implemented in a single device, or Figure 2 The single device shown may be implemented as multiple distributed devices. Additionally or alternatively, one set of devices (eg, one or more devices) of environment 200 may perform one or more functions described as being performed by another set of devices of environment 200.

[0062] Figure 3 yes Figure 2 300. The example components may be included in a device 300, which may correspond to an endpoint device 210, a network device 220, and / or a server device 230. In some implementations, the endpoint device 210, the network device 220, and / or the server device 230 may include one or more devices 300 and / or one or more components of the device 300. Figure 3 As shown, device 300 may include a bus 310 , a processor 320 , a memory 330 , an input component 340 , an output component 350 , and a communication interface 360 ​​.

[0063] Bus 310 includes one or more components that enable wired and / or wireless communication between components of device 300. Bus 310 may Figure 3 Two or more components of are coupled together, such as via operational coupling, communication coupling, electronic coupling, and / or electrical coupling. Processor 320 includes a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor, a controller, a microcontroller, a digital signal processor (DSP), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), and / or other types of processing components. Processor 320 is implemented in hardware, firmware, or a combination of hardware and software. In some implementations, processor 320 includes one or more processors that can be programmed to perform one or more operations or processes described elsewhere herein.

[0064] Memory 330 includes volatile and / or non-volatile memory. For example, memory 330 may include random access memory (RAM), read-only memory (ROM), a hard drive, and / or another type of memory (e.g., flash memory, magnetic memory, and / or optical memory). Memory 330 may include internal memory (e.g., RAM, ROM, or hard drive) and / or removable memory (e.g., removable via a universal serial bus connection). Memory 330 may be a non-transitory computer-readable medium. Memory 330 stores information, instructions, and / or software (e.g., one or more software applications) related to the operation of device 300. In some implementations, memory 330 includes one or more memories such as coupled to one or more processors (e.g., processor 320) via bus 310.

[0065] Input assembly 340 enables device 300 to receive input, such as user input and / or sensory input. For example, input assembly 340 may include a touch screen, keyboard, keypad, mouse, button, microphone, switch, sensor, global positioning system sensor, accelerometer, gyroscope and / or actuator. Output assembly 350 enables device 300 to provide output, such as via a display, speaker and / or light emitting diode. Communication interface 360 ​​enables device 300 to communicate with other devices via wired connection and / or wireless connection. For example, communication interface 360 ​​may include a receiver, a transmitter, a transceiver, a modem, a network interface card and / or an antenna.

[0066] Device 300 can perform one or more operations or processes described herein. For example, a non-transitory computer-readable medium (e.g., memory 330) can store an instruction set (e.g., one or more instructions or codes) for execution by processor 320. Processor 320 can execute the instruction set to perform one or more operations or processes described herein. In some implementations, the execution of the instruction set by one or more processors 320 causes one or more processors 320 and / or device 300 to perform one or more operations or processes described herein. In some implementations, hard-wired circuits can be used instead of instructions or in combination with instructions to perform one or more operations or processes described herein. Additionally or alternatively, processor 320 can be configured to perform one or more operations or processes described herein. Therefore, the implementation described herein is not limited to any particular combination of hardware circuits and software.

[0067] Figure 3 The number and arrangement of components shown are provided as examples. Figure 3 Compared to the illustrated embodiment, device 300 may include more components, fewer components, different components, or differently arranged components. Additionally or alternatively, a set of components (e.g., one or more components) of device 300 may perform one or more functions described as being performed by another set of components of device 300.

[0068] Figure 4 yes Figure 2 4. The example components may be included in device 400. Device 400 may correspond to network device 220. In some implementations, network device 220 may include one or more devices 400 and / or one or more components of device 400. Figure 4 As shown, the device 400 may include one or more input components 410-1 to 410-B (B≥1) (hereinafter collectively referred to as input component 410, and individually referred to as input component 410), a switching component 420, one or more output components 430-1 to 430-C (C≥1) (hereinafter collectively referred to as output component 430, and individually referred to as output component 430), and a controller 440.

[0069] The input component 410 may be one or more attachment points for a physical link and may be one or more entry points for incoming traffic (such as packets). The input component 410 may process incoming traffic, such as by performing data link layer encapsulation or decapsulation. In some implementations, the input component 410 may transmit and / or receive packets. In some implementations, the input component 410 may include an input line card that includes one or more packet processing components (e.g., in the form of an integrated circuit), such as one or more interface cards (IFCs), a packet forwarding component, a line card controller component, an input port, a processor, a memory, and / or an input queue. In some implementations, the device 400 may include one or more input components 410.

[0070] The switching component 420 can interconnect the input component 410 with the output component 430. In some implementations, the switching component 420 can be implemented via one or more crossbar switches, via a bus, and / or using a shared memory. The shared memory can act as a temporary buffer to store packets from the input component 410 before they are ultimately scheduled for delivery to the output component 430. In some implementations, the switching component 420 can enable the input component 410, the output component 430, and / or the controller 440 to communicate with each other.

[0071] Output component 430 can store packets and can schedule packets for transmission on an output physical link. Output component 430 can support data link layer encapsulation or decapsulation, and / or various higher-level protocols. In some implementations, output component 430 can transmit packets and / or receive packets. In some implementations, output component 430 may include an output line card, which includes one or more packet processing components (e.g., in the form of an integrated circuit), such as one or more IFCs, packet forwarding components, line card controller components, output ports, processors, memories, and / or output queues. In some implementations, device 400 may include one or more output components 430. In some implementations, input component 410 and output component 430 may be implemented by the same set of components (e.g., an input / output component may be a combination of input component 410 and output component 430).

[0072] The controller 440 includes a processor in the form of, for example, a CPU, a GPU, an accelerated processing unit (APU), a microprocessor, a microcontroller, a DSP, an FPGA, an ASIC, and / or other types of processors. The processor is implemented in hardware, firmware, or a combination of hardware and software. In some implementations, the controller 440 may include one or more processors that can be programmed to perform a function.

[0073] In some implementations, the controller 440 may include RAM, ROM, and / or another type of dynamic or static storage device (eg, flash memory, magnetic memory, optical memory, etc.) that stores information and / or instructions for use by the controller 440 .

[0074] In some implementations, the controller 440 can communicate with other devices, networks, and / or systems connected to the device 400 to exchange information about the network topology. The controller 440 can create a routing table based on the network topology information, can create a forwarding table based on the routing table, and can forward the forwarding table to the input component 410 and / or the output component 430. The input component 410 and / or the output component 430 can use the forwarding table to perform a route lookup for incoming and / or outgoing packets.

[0075] The controller 440 may perform one or more processes described herein. The controller 440 may perform these processes in response to executing software instructions stored by a non-transitory computer readable medium. A computer readable medium is defined herein as a non-transitory memory device. A memory device includes memory space within a single physical memory device or memory space distributed between multiple physical memory devices.

[0076] The software instructions may be read from another computer-readable medium or from another device via a communication interface into a memory and / or storage component associated with the controller 440. When executed, the software instructions stored in the memory and / or storage component associated with the controller 440 may cause the controller 440 to perform one or more processes described herein. Additionally or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to perform one or more processes described herein. Therefore, the implementations described herein are not limited to any specific combination of hardware circuitry and software.

[0077] Figure 4 The number and arrangement of components shown are provided as examples. Figure 4 Compared to the illustrated, device 400 may include more components, fewer components, different components, or differently arranged components. Additionally or alternatively, a set of components (e.g., one or more components) of device 400 may perform one or more functions described as being performed by another set of components of device 400.

[0078] Figure 5 is a flow chart of an example process 500 for managing the power state of an aggregated link of a network device. In some implementations, Figure 5 One or more process blocks of may be performed by a network device (e.g., network device 220). In some implementations, Figure 5One or more process blocks of may be performed by another device or group of devices separate from or including the network device, such as a server device (e.g., server device 230). Additionally or alternatively, Figure 5 One or more process blocks of may be performed by one or more components of device 300, such as processor 320, memory 330, input component 340, output component 350, and / or communication interface 360. Additionally or alternatively, Figure 5 One or more process blocks of may be performed by one or more components of device 400 , such as input component 410 , switching component 420 , output component 430 , and / or controller 440 .

[0079] like Figure 5 As shown, process 500 may include generating a first PDU identifying a request to transition from a power-on state to a power-sleep state (block 510). For example, a first network device may generate a first PDU identifying a request to transition from a power-on state to a power-sleep state, as described above.

[0080] like Figure 5 As further shown, process 500 may include providing the first PDU to the second network device (block 520). For example, the first network device may provide the first PDU to the second network device, as described above.

[0081] like Figure 5 As further shown, process 500 may include receiving a second PDU identifying a link of a second network device to be transitioned from a powered on state to a powered sleep state (block 530). For example, a first network device may receive a second PDU identifying a link of a second network device to be transitioned from a powered on state to a powered sleep state, as described above.

[0082] like Figure 5 As further shown, process 500 may include generating a third PDU identifying a link of the first network device to be transitioned from the powered on state to the powered sleep state (block 540). For example, the first network device may generate a third PDU identifying a link of the first network device to be transitioned from the powered on state to the powered sleep state, as described above.

[0083] like Figure 5 As further shown, process 500 may include providing a third PDU to the second network device (block 550). For example, the first network device may provide the third PDU to the second network device, as described above. In some implementations, each of the first PDU, the second PDU, and the third PDU is a LACP PDU.

[0084] like Figure 5As further shown, process 500 may include transitioning a link of the first network device and a link of the second network device from a power-on state to a power-sleep state based on the second PDU and the third PDU (box 560). For example, the first network device may transition a link of the first network device and a link of the second network device from a power-on state to a power-sleep state based on the second PDU and the third PDU, as described above. In some implementations, transitioning a link of the first network device and a link of the second network device from a power-on state to a power-sleep state includes causing ports associated with the link of the first network device and the link of the second network device to be powered off. In some implementations, transitioning a link of the first network device and a link of the second network device from a power-on state to a power-sleep state includes determining whether a sleep timer has expired, and based on determining that the sleep timer has expired, transitioning the link of the first network device and the link of the second network device from a power-on state to a power-sleep state.

[0085] In some implementations, process 500 includes exchanging one or more periodic link aggregation control protocol PDUs with a second network device. In some implementations, process 500 includes receiving an acknowledgment of the first PDU from the second network device. In some implementations, process 500 includes providing an acknowledgment of the second PDU to the second network device.

[0086] In some implementations, process 500 includes providing a fourth PDU to the second network device that identifies a re-transition of the link of the first network device from a power-sleep state to a power-on state, and receiving a fifth PDU from the second network device that identifies a re-transition of the link of the second network device from a power-sleep state to a power-on state in response to the fourth PDU. In some implementations, process 500 includes verifying that the link of the first network device and the link of the second network device are available based on the fourth PDU and the fifth PDU, and based on the verification that the link of the first network device and the link of the second network device are available, transitioning the link of the first network device and the link of the second network device from the power-sleep state to the power-on state. In some implementations, process 500 includes determining that one of the link of the first network device or the link of the second network device is unavailable based on the fourth PDU and the fifth PDU, and generating an alarm based on the determination that one of the link of the first network device or the link of the second network device is unavailable.

[0087] In some implementations, process 500 includes receiving actual business time period data, and determining predicted business time period data based on the actual business time period data. In some implementations, process 500 includes processing the predicted business time period data and the actual business time period data using an action model to determine whether to transition a link of the first network device to a power sleep state, whether to transition a link of the first network device to a power on state, or whether to perform no link action on the link of the first network device. In some implementations, process 500 includes not performing a link action on the link of the first network device based on a determination that the link action is not to be performed on the link of the first network device.

[0088] although Figure 5 An example block diagram of process 500 is shown, but in some implementations, Figure 5 Process 500 may include more blocks, fewer blocks, different blocks, or differently arranged blocks than shown. Additionally or alternatively, two or more blocks of process 500 may be performed in parallel.

[0089] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise forms disclosed. Modifications and variations may be made in light of the above disclosure, or may be acquired from practice of the implementations.

[0090] As used herein, the term "component" is intended to be broadly interpreted as hardware, firmware, or a combination of hardware and software. Obviously, the systems and / or methods described herein can be implemented in different forms of hardware, firmware, and / or a combination of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods does not limit the implementation. Therefore, the operation and behavior of the systems and / or methods are described herein without reference to specific software codes-it should be understood that software and hardware can be used to implement the systems and / or methods based on the description herein.

[0091] Although specific feature combinations are recited in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of various implementations. In fact, many of these features can be combined in ways not specifically recited in the claims and / or disclosed in the specification. Although each dependent claim listed below may be directly dependent on a claim, the disclosure of various implementations includes the combination of each dependent claim with every other claim in the claim set.

[0092] Any element, action or instruction used in this article should not be interpreted as key or necessary, unless clearly described as such. In addition, as used in this article, the article "a" and "an" are intended to include one or more items, and can be used interchangeably with "one or more". In addition, as used in this article, the article "the" is intended to include one or more items quoted in conjunction with the article "the", and can be used interchangeably with "one or more". In addition, as used in this article, the term "set" is intended to include one or more items (for example, related items, unrelated items, or a combination of related and unrelated items, etc.), and can be used interchangeably with "one or more". If only one item is intended to be used, the phrase "only one" or similar language is used. In addition, as used in this article, the term "has", "have", "having" etc. are intended to be open terms. In addition, unless otherwise expressly stated, the phrase "based on" is intended to represent "based at least in part". Furthermore, as used herein, the term "or" is intended to be inclusive when used in a serial form and may be used interchangeably with "and / or" unless expressly stated otherwise (e.g., if used in conjunction with "any one" or "only one of").

[0093] In the foregoing description, various exemplary embodiments have been described with reference to the accompanying drawings. However, it will be apparent that various modifications and changes may be made thereto, and that additional embodiments may be implemented, without departing from the broader scope of the invention as set forth in the appended claims. Accordingly, the description and drawings should be regarded as illustrative rather than restrictive.

Claims

1. A method comprising: generating, by the first network device, a first protocol data unit (PDU) identifying a request to transition from a power-on state to a power-sleep state; The first network device provides the first PDU to the second network device; receiving, by the control channel link of the first network device, a second PDU identifying a link of the second network device to be transitioned from the power-on state to the power-sleep state; generating, by the first network device, a third PDU identifying a link of the first network device to be transitioned from the powered-on state to the powered-down state; The first network device provides the third PDU to the second network device; as well as The link of the first network device and the link of the second network device are transitioned from the power-on state to the power-sleep state by the first network device based on the second PDU and the third PDU.

2. The method according to claim 1, further comprising: One or more periodic link aggregation control protocol (PDUs) are exchanged with the second network device. 3 . The method of claim 1 , wherein each of the first PDU, the second PDU, and the third PDU is a Link Aggregation Control Protocol PDU.

4. The method according to claim 1, further comprising: An acknowledgement for the first PDU is received from the second network device.

5. The method according to claim 1, further comprising: An acknowledgement of the second PDU is provided to the second network device.

6. The method of claim 1 , wherein transitioning the link of the first network device and the link of the second network device from the power-on state to the power-down state comprises: Ports associated with the link of the first network device and the link of the second network device are powered off.

7. The method of claim 1 , wherein transitioning the link of the first network device and the link of the second network device from the power-on state to the power-down state comprises: Determine whether the sleep timer has expired; as well as Based on determining that the sleep timer has expired, the link of the first network device and the link of the second network device are transitioned from the power-on state to the power-sleep state.

8. A first network device, comprising: one or more memories; as well as One or more processors for: generating a first protocol data unit (PDU) identifying a request to transition from a power-on state to a power-sleep state; Providing the first PDU to a second network device; receiving a second PDU identifying a link of the second network device to be transitioned from the powered-on state to the powered-down state; generating a third PDU identifying a link of the first network device to be transitioned from the powered-on state to the powered-down state; Providing the third PDU to the second network device; determining whether a sleep timer has expired based on the second PDU and the third PDU; as well as Based on determining that the sleep timer has expired, the link of the first network device and the link of the second network device are transitioned from the power-on state to the power-sleep state.

9. The first network device according to claim 8, wherein the one or more processors are further configured to: providing, to the second network device, a fourth PDU identifying a re-transition of the link of the first network device from the power-sleep state to the power-on state; and In response to the fourth PDU, a fifth PDU is received from the second network device identifying a re-transition of the link of the second network device from the power-sleep state to the power-on state.

10. The first network device according to claim 9, wherein the one or more processors are further configured to: verifying that the link of the first network device and the link of the second network device are available based on the fourth PDU and the fifth PDU; and Based on verification that the link of the first network device and the link of the second network device are available, the link of the first network device and the link of the second network device are transitioned from the power-sleep state to the power-on state.

11. The first network device of claim 9, wherein the one or more processors are further configured to: determining that one of the link of the first network device or the link of the second network device is unavailable based on the fourth PDU and the fifth PDU; and An alarm is generated based on a determination that one of the link of the first network device or the link of the second network device is unavailable.

12. The first network device of claim 8, wherein the one or more processors are further configured to: receiving actual business time period data; and The predicted business time period data is determined based on the actual business time period data.

13. The first network device of claim 12, wherein the one or more processors are further configured to: The predicted business time period data and the actual business time period data are processed using an action model to determine whether to transition the link of the first network device to a power sleep state, whether to transition the link of the first network device to a power on state, or whether to perform no link action on the link of the first network device.

14. The first network device of claim 13, wherein the one or more processors are further configured to: Based on a determination that a link action is not to be performed on the link of the first network device, no link action is performed on the link of the first network device.

15. A non-transitory computer-readable medium storing a set of instructions, the set of instructions comprising: One or more instructions that, when executed by one or more processors of a first network device, cause the first network device to: generating a first protocol data unit (PDU) identifying a request to transition from a power-on state to a power-sleep state; Providing the first PDU to a second network device; receiving an acknowledgement of the first PDU from the second network device; receiving a second PDU identifying a link of the second network device to be transitioned from the powered-on state to the powered-down state; generating a third PDU identifying a link of the first network device to be transitioned from the powered-on state to the powered-down state; Providing the third PDU to the second network device; as well as The link of the first network device and the link of the second network device are transitioned from the power-on state to the power-sleep state based on the second PDU and the third PDU.

16. The non-transitory computer readable medium of claim 15, wherein the one or more instructions further cause the first network device to: One or more periodic link aggregation control protocol (PDUs) are exchanged with the second network device.

17. The non-transitory computer-readable medium of claim 15, wherein the one or more instructions that cause the first network device to transition the link of the first network device and the link of the second network device from the power-on state to the power-down state cause the first network device to: Ports associated with the link of the first network device and the link of the second network device are powered off.

18. The non-transitory computer readable medium of claim 15, wherein the one or more instructions further cause the first network device to: providing, to the second network device, a fourth PDU identifying a re-transition of the link of the first network device from the power-sleep state to the power-on state; In response to the fourth PDU, receiving from the second network device a fifth PDU identifying a re-transition of the link of the second network device from the power-sleep state to the power-on state; verifying that the link of the first network device and the link of the second network device are available based on the fourth PDU and the fifth PDU; as well as Based on verification that the link of the first network device and the link of the second network device are available, the link of the first network device and the link of the second network device are transitioned from the power-sleep state to the power-on state.

19. The non-transitory computer readable medium of claim 15, wherein the one or more instructions further cause the first network device to: Receive actual business time period data; Determining predicted business time period data based on the actual business time period data; and The predicted business time period data and the actual business time period data are processed using an action model to determine whether to transition the link of the first network device to a power sleep state, whether to transition the link of the first network device to a power on state, or whether to perform no link action on the link of the first network device.

20. The non-transitory computer readable medium of claim 19, wherein the one or more instructions further cause the first network device to: Based on a determination that a link action is not to be performed on the link of the first network device, no link action is performed on the link of the first network device.

Images