Intra gateway protocol and traffic engineering sleep state for network

Abstract

Embodiments of the invention relate to an internal gateway protocol and traffic engineering sleep state for a network. The first network device may identify one or more components to transition to a sleep state, and may power down the one or more components to cause a link with the second network device to be in a sleep state. The first network device may provide a link sleep state message identifying the link to the second network device, and may provide an updated link sleep state message to the second network device while the sleep state of the link is maintained.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This patent application claims the benefit of Indian Provisional Patent Application No. 202341064503, filed on September 26, 2023, entitled “SYSTEMS AND METHODS FOR PROVIDING ENERGY EFFICIENT NETWORKS” and assigned to the assignee of the present application. The disclosure of the prior application is considered to be a part of the present patent application and is incorporated by reference into the present patent application. Technical Field

[0003] Embodiments of the present application relate to interior gateway protocol and traffic engineering sleep states for a network. Background Art

[0004] An Interior Gateway Protocol (IGP) is a type of routing protocol used to exchange routing table information between gateways (eg, network devices) within an autonomous system, such as a corporate Local Area Network (LAN) system. Summary of the invention

[0005] Some implementations described herein relate to a method. The method may include identifying one or more components of a first network device to transition to a sleep state, and powering off the one or more components so that a link with a second network device is in a sleep state. The method may include providing a link sleep state message identifying a link to the second network device, and providing an updated link sleep state message to the second network device while the sleep state of the link is maintained.

[0006] 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 identify one or more components to be transitioned to a sleep state, and to power off the one or more components so that a link with a second network device is in a sleep state. The one or more processors may be configured to provide a link sleep state message identifying a link to the second network device, and while the sleep state of the link is maintained, provide an updated link sleep state message to the second network device, wherein each of the updated link sleep state messages includes a sleep request bit set in a sleep type length value message.

[0007] 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, may cause the first network device to identify one or more components to be transitioned to a sleep state, and to power off one or more components so that a link with a second network device is in a sleep state. The instruction set, when executed by one or more processors of the first network device, may cause the first network device to provide a link sleep state message identifying a link to the second network device, and provide an updated link sleep state message to the second network device while the sleep state of the link is maintained. The instruction set, when executed by one or more processors of the first network device, may cause the first network device to maintain neighbor adjacency with the second network device based on the updated link sleep state message. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figures 1A to 1H is a diagram of an example associated with providing IGP and traffic engineering sleep states for a network;

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

[0010] Figure 3 and Figure 4 yes Figure 2 diagrams of example components of one or more devices; and

[0011] Figure 5 is a flow chart of an example process for providing IGP and traffic engineering sleep states for a network. DETAILED DESCRIPTION

[0012] 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.

[0013] Currently, the relationship between the IGP link state and the adjacent network device is a binary state (e.g., the link is up or down). The network device can transition one or more components to a sleep state by powering off one or more components or placing one or more components in some other wake-up state. However, the sleep state information associated with the network device is not maintained throughout the network of network devices. Therefore, the path calculation entity cannot wake up the sleeping network device. The network is designed to reach peak utilization in a very short period of time, while also taking into account various types of failures. During non-peak times, the network can generate significant resource savings and can reduce the carbon footprint of the network by placing unused traffic engineering (TE) paths or links in a sleep state. However, network devices are currently unable to put traffic engineering paths into a sleep state based on transitioning unused components of the network device to a low power or sleep state because the sleep state information is not maintained throughout the network.

[0014] Therefore, current technologies for managing networks consume computing resources (e.g., processing resources, memory resources, communication resources, etc.), network resources, etc., and these resource consumptions are related to the following: failure to maintain sleep state information associated with network devices throughout the network, failure to put unused links of the network into a sleep state during non-peak utilization times based on failure to maintain sleep state information, unnecessarily maintaining unused links during non-peak utilization times of the network, and the like.

[0015] Some implementations described herein relate to network devices that provide IGP and traffic engineering sleep states for a network. For example, a network device may identify one or more components to be transitioned to a sleep state, and may power off one or more components so that a link with another network device is in a sleep state. A network device may provide a link sleep state message identifying a link to another network device, and may provide an updated link sleep state message to another network device while the sleep state of the link is maintained. A network device may maintain neighbor adjacency with another network device based on an updated link sleep state message.

[0016] In this way, the network device provides IGP and traffic engineering sleep states for the network. For example, the network device can identify one or more components (e.g., processors, interfaces, memories, etc.) to enter a sleep state. Once one or more components are identified, the network device can transition the one or more components to a sleep state (e.g., by powering off one or more components). The network device can provide sleep state information (e.g., identifying one or more components that transition to a sleep state) to adjacent network devices so that the adjacent network devices can determine that the network device has transitioned to a sleep state, can determine that one or more traffic engineering links with the network device are in a sleep state and will be avoided, can determine that if the current state of the network cannot meet new requirements, then one or more traffic engineering links can be awakened from a sleep state, and so on. Therefore, the network device saves computing resources, network resources, and the like, which would otherwise be consumed due to the following: failure to maintain sleep state information associated with the network device throughout the network, failure to put unused links of the network into a sleep state based on failure to maintain sleep state information during non-peak utilization times, and unnecessary maintenance of unused links during non-peak utilization times of the network, and the like.

[0017] Figures 1A to 1H is a diagram of an example 100 associated with providing IGP and traffic engineering sleep states for a network. Figures 1A to 1H As shown, example 100 includes an endpoint device associated with a network, and a server device. The network may include multiple network devices, such as a first network device (e.g., network device 1), a second network device (e.g., network device 2), and a third network device (e.g., network device 3). A first link (e.g., link 1) may be provided between the first network device and the second network device, a second link (e.g., link 2) may be provided between the first network device and the third network device, and a third link (e.g., link 3) may be provided between the second network device and the third network device. More details of the endpoint devices, server devices, networks, network devices, and links are provided elsewhere herein.

[0018] like Figure 1AAs shown in the figure mark 105, the first network device can identify one or more components to be transitioned to a sleep state. For example, during non-peak network traffic time, the first network device can put one or more links (e.g., traffic engineering paths) into a sleep state. In order to put one or more links into a sleep state, the first network device can transition one or more unused components (e.g., interfaces, processors, memories, etc.) to a low-power state or a sleep state. The traffic engineering layout model of the first network device can move traffic flows away from unused components or to specific components to facilitate the transition to a sleep state. In some implementations, the first network device can identify unused components as one or more components to be transitioned to a sleep state.

[0019] like Figure 1A As further shown in the figure numeral 110, the first network device can power off one or more components so that one or more links (e.g., the first link and the second link) are in a sleep state. For example, once the first network device identifies one or more components to be transitioned to a sleep state, the first network device can power off one or more components so that one or more links (e.g., with adjacent network devices, such as the second network device and the third network device) are in a sleep state. Once the one or more components and the one or more links are transitioned to a sleep state, the adjacent network devices can determine that the first network device is not shut down but is transitioning to a sleep state, it can be determined that one or more links are in a sleep state and will be avoided, it can be determined that one or more links are in a sleep state and new business needs cannot be met without the one or more links, the one or more links can be awakened, and so on.

[0020] like Figure 1A As further shown in the figure mark 115, the first network device can provide a link sleep state message to the second network device and the third network device. For example, under normal circumstances, when a change occurs, the IGP network device in communication can cause the adjacent network device to transition to a closed state. However, since the first network device, the second network device, and the third network device are network devices with IGP sleep capabilities, the first network device can provide a link state message (e.g., a hello message) to the second network device and the third network device. The link state message may include a sleep request (SR) bit set in a sleep type length value (TLV) message. The link state message can indicate to adjacent network devices (e.g., the second network device and the third network device) that a normal power off is being performed at the first network device and that the IGP adjacency with the first network device is maintained.

[0021] like Figure 1AAs further shown in the figure numeral 120, each of the second network device and the third network device can power off one or more components associated with the link. For example, adjacent network devices (e.g., the second network device and the third network device) can implement a sleep process. In some implementations, to implement the sleep process, the second network device can identify one or more components associated with the link (e.g., the first link) and can power off the identified one or more components associated with the link. Alternatively or additionally, to implement the sleep process, the third network device can identify one or more components associated with the link (e.g., the second link) and can power off the identified one or more components associated with the link.

[0022] like Figure 1B As shown in FIG. 125, the first network device can provide an updated link sleep state message to each of the second network device and the third network device. For example, while the link remains in the sleep state, the first network device can continue to generate updated link sleep state messages and can provide the updated link sleep state messages to adjacent network devices (e.g., the second network device and the third network device). In some implementations, each of the updated link sleep state messages can include an SR bit set in the sleep TLV message. In some implementations, transitioning to the sleep state does not bifurcate the first network device (e.g., the IGP speaker) from the network because the first network device can maintain at least one interface in an active state.

[0023] like Figure 1B As further shown in the figure numeral 130, each of the second network device and the third network device can maintain neighbor adjacency with the first network device based on the updated link sleep state message. For example, the updated link sleep state message can enable the second network device and the third network device to maintain neighbor adjacency with the first network device. In some implementations, while one or more components of the first network device are in a sleep state, the first network device can flood the second network device and the third network device in accordance with a link state protocol data unit (PDU) (e.g., a link state packet (LSP) or a link state advertisement (LSA)) as a link sleep state message. This enables the second network device and the third network device to reestablish adjacency with the first network device without transitioning to a closed state, and enables the first network device to re-initiate smooth database synchronization.

[0024] like Figure 1BAs further shown in the figure numeral 135, the first network device can receive a link sleep state message from each of the second network device and the third network device. For example, in addition to maintaining adjacency with the first network device in a sleep state, adjacent network devices (e.g., the second network device and the third network device) can generate a link sleep state message and can provide the link sleep state message to the first network device. The first network device can receive a link sleep state message from the second network device and the third network device. In some implementations, each of the link sleep state messages can include an SR bit set in a sleep TLV message. The link sleep state message can include a full sequence number PDU (CSNP) in an intermediate system to intermediate system (IS-IS) environment and can include an LSA in an open shortest path first (OSPF) environment. The first network device can flood the entire database with the link sleep state message.

[0025] like Figure 1B As further shown in the figure numeral 140, the first network device can maintain neighbor adjacency with the second network device and the third network device based on the link sleep state message. For example, the link sleep state message can enable the first network device to maintain neighbor adjacency with the second network device and the third network device. This enables the first network device to reestablish adjacency with the second network device and the third network device without transitioning to the closed state, and enables the second network device and the third network device to re-initiate smooth database synchronization.

[0026] In some implementations, the Link Sleep State message, each Update Link State message, and each Link Sleep State message may include the following syntax (e.g., for IGP state):

[0027] regress@R1>show isis adjacency detail

[0028] R0

[0029] Interface:ge-0 / 1 / 1.0,Level:2,State:Sleep,Expires in 24secs

[0030] Priority:0,Up / Down transitions:1,Last transition:00:03:30

[0031] ago

[0032] Circuit type:2,Speaks:IP,IPv6

[0033] Topologies:Unicast

[0034] Restart capable:Yes,Adjacency advertisement:Advertise / Sleep

[0035] IP addresses:10.1.12.2

[0036] IPv6 addresses:fe80::5604:1bff:fe00:6199

[0037] IPv6 Global Interface Address:dead:beef:112::2

[0038] Level 2IPv4 Adj-SID:299808

[0039] Level 2IPv6 Adj-SID:299824

[0040] where the adjacent state is designated as sleeping instead of up or down.

[0041] In some implementations, the link sleep state message, each update link state message, and each link sleep state message may include the following syntax (e.g., for a traffic engineering database (TED) state):

[0042] regress@R2#run show ted database topology-type l3-unicast

[0043] extensive

[0044] TED database:5ISIS nodes 5 INET nodes 0 INET6 nodes

[0045] NodeID:R2.00(1.1.1.2)

[0046] Type:Rtr,Age:1500secs(sleep),LinkIn:8,LinkOut:8

[0047] Protocol:IS-IS(2)

[0048] 1.1.1.2,128.53.107.59

[0049] To:R5.00(1.1.1.5),Local:10.1.25.1,Remote:10.1.25.2

[0050] Local interface index:359,Remote interface index:358

[0051] Color:0x400 red

[0052] Metric: 10

[0053] IGP metric:200

[0054] Power metric:#

[0055] Minimum power(W):#

[0056] Maximum power(W):#

[0057] Current power(W):# ...

[0059] To facilitate traffic engineering path placement, power-specific metrics may also be advertised. This enables the path computation entity of the network device to place paths on the network in a power-aware manner. The power-specific metric may be a single composite metric derived by the local network device (e.g., Metric = % (max-power (W) min-power (W)) / current power (W)), may be a set of values ​​measured by the local network device (e.g., minimum, maximum, or current power utilization (W)), and so on. In some implementations, the power-specific metric may include the following syntax:

[0060] regress@R2#run show ted database topology-type l3-unicast

[0061] extensive

[0062] TED database:5ISIS nodes 5INET nodes 0INET6 nodes

[0063] NodeID:R2.00(1.1.1.2)

[0064] Type:Rtr,Age:15secs,LinkIn:8,LinkOut:8

[0065] Protocol:IS-IS(2)

[0066] 1.1.1.2,128.53.107.59

[0067] To:R5.00(1.1.1.5),Local:10.1.25.1,Remote:10.1.25.2

[0068] Local interface index:359,Remote interface index:358

[0069] Color:0x400 red

[0070] Metric: 10

[0071] IGP metric:200

[0072] Power metric:#

[0073] Minimum power(W):#

[0074] Maximum power(W):#

[0075] Current power(W):#.

[0076] In a tactical or uncoordinated configuration, the ingress network device can independently place the traffic engineering tunnel in a power-aware state. Network devices within the network can independently place components in a reset, sleep, or power-off state. Power-related attributes can be flooded throughout the network via IGP-TE extensions. In a strategic or coordinated configuration, power-related information can be exported to a centralized application that instructs the network device to explicitly place the component in a reset, sleep, or power-off state. In a sleep configuration, the sleep state can be used to represent any of several states in which an interface or component can be placed (e.g., a power-off state, a reset state, a low power state, a slowed clock rate state, a wake-up state on arrival, etc.). From a protocol perspective, the network protocol can remember that a port (e.g., in a sleep state) exists in the network and can be used when needed. The port may have been enabled and can be converted out of the sleep state as needed.

[0077] Figure 1CAn example IGP-TE sleep capability and flags associated with a first network device and a second network device are depicted. As shown, when the interface of the first network device is powered off, the first network device can signal the second network device that the first network device is entering a sleep state. A two-way agreement for a sleep state can be reached between the first network device and the second network device. It is not mandatory for the second network device to also be powered off, but the link between the first network device and the second network device can be flooded with a sleep flag set. The IGP adjacency can be remembered by the first network device and the second network device for the duration of the sleep. The link prefix can be maintained in a link state database (LSDB) of the second network device together with the associated sleep flag set. Links with a sleep flag set can be pruned for all shortest path trees (SPTs), and traffic engineering tunnels can be moved away from the sleep interface.

[0078] Figure 1D An example of powering off components of a network device is depicted. Figure 1D As shown on the right side of FIG, a network device can determine that a port associated with a packet forwarding engine (PFE) is not in use and can power down a wide area network (WAN) serializer / deserializer (SerDes) and physical layer (PHY) device associated with the PFE. Once the WAN SerDes and PHY devices are powered down, the PFE can be powered down, which can cause fabrics associated with the powered down PFE (e.g., fabric 0 to fabric N, as shown in FIG. 1 ). Figure 1D left) and the link is powered off.

[0079] Figure 1E Another example of powering off components of a network device is depicted. As shown, a PFE (e.g., PFE3) of a network device can be associated with a fabric (e.g., fabric 0 through fabric 5). There is a strong relationship between the load on the PFE and the ability to disable components of the network device. For example, a lightly loaded PFE may require fewer active fabrics, the remaining fabrics are powered off, and unused PFEs can be disabled. Figure 1E As shown, if the switching capacity of the PFE is 66%, the PFE may require four fabrics, and the network device may power down fabric 4 and fabric 5.

[0080] Figure 1F An example of coordinated powering on and off between network devices (e.g., a first network device and a second network device) is depicted. The network devices can use a power management protocol. The power management protocol can require coordination between adjacent network devices when components of the network devices are powered off. The power management protocol can gracefully move data planes associated with the network devices and can require the network devices to host applications using Link Aggregation Control Protocol (LACP) and / or Link Layer Discovery Protocol (LLDP) extensions. Figure 1FAs further shown, a power group can be established between network devices. A power group can include a group of links with a common PFE, a control channel for coordinating the powering on or off of sub-links, and a periodic exchange of the status of all links in the power group. Figure 1F As further shown, the network devices can utilize a three-way handshake of the power on / off state to ensure the reliability and mutual consistency of the transitions between the sleep states.As further shown, one of the network devices can perform a periodic health check of the link to ensure that the link maintains the sleep state (e.g., the sleep active state has not failed).

[0081] Figure 1G Another example of coordinated power on and off between network devices (e.g., a first network device and a second network device) is depicted. As shown, a power group can include a PFE associated with three interfaces (e.g., interface 0, interface 1, and interface 2). The PFEs and interfaces can be provided in the network devices. The network devices can utilize local policies to power on or off components within the power group, can utilize time of day activation constraints to power on or off components, can utilize minimum capacity thresholds (e.g., below which components of the power group can be evaluated for power on / off), can utilize evaluation intervals to evaluate utilization of the power group, and the like. As shown in FIG. Figure 1G As further shown, when the bandwidth only covers interface 0 and interface 1, the network device may shut down interface 2 due to unused bandwidth.

[0082] Figure 1H Depicts an example of power-aware path placement for network devices. Figure 1H As shown at the top of Figure 1, traffic engineering networks often utilize various techniques to group traffic engineering links (e.g., a common power group for port 0 to port 3). Network devices can utilize this group as an inclusion or exclusion constraint during path placement (e.g., calculating a secondary path that is different from the primary path). The same concept can be applied by introducing a group that represents the association of a link (e.g., a port) to a PFE (e.g., a power group). As Figure 1H As shown at the bottom of , when an ingress network device (e.g., network device 0) or PCE calculates a path, power groups can be used during path placement. This can be similar to the PFE routing approach, where power groups are considered along with any other traffic engineering attributes. The power group approach can follow a most-filled or least-filled placement model, where the most-filled model generates results associated with using the least number of PFEs (e.g., routing based on power groups and costs), and the least-filled model generates results associated with extending traffic engineering tunnels over the greatest number of PFEs (e.g., routing based on power groups only). This can enable the network device to make independent decisions to disable fabric cards or PFEs based on load.

[0083] In this way, the network device provides IGP and traffic engineering sleep state for the network. For example, the network device can identify one or more components to enter the sleep state. Once one or more components are identified, the network device can transition the one or more components to the sleep state. The network device can provide sleep state information (e.g., identify one or more components that are transitioned to the sleep state) to adjacent network devices so that the adjacent network devices can determine that the network device has transitioned to the sleep state, can determine that one or more traffic engineering links with the network device are in the sleep state and will be avoided, can determine that if the current state of the network cannot meet the new demand, then one or more traffic engineering links can be awakened from the sleep state, and so on. Therefore, the network device saves computing resources, network resources, etc., which would otherwise be consumed due to the following: failure to maintain sleep state information associated with the network device throughout the network, failure to put unused links of the network into a sleep state based on failure to maintain sleep state information during non-peak utilization time, unnecessary maintenance of unused links during non-peak utilization time of the network, and so on.

[0084] As mentioned above, Figures 1A to 1H Other examples can be found in the Figures 1A to 1H Described differently. Figures 1A to 1H The number and arrangement of devices shown are provided as examples. Figures 1A to 1H There may be more devices, fewer devices, different devices, or differently arranged devices than shown. Figures 1A to 1H Two or more of the devices shown may be implemented in a single device, or Figures 1A to 1H The single device shown may be implemented as multiple distributed devices. Additionally or alternatively, Figures 1A to 1H The illustrated set of devices (e.g., one or more devices) may perform the operations described as being performed by Figures 1A to 1H Another group of devices is shown performing one or more functions.

[0085] 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.

[0086] 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 wireless 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, a server device, a group of server devices, 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 (e.g., by using network device 220 as an intermediary to route packets) and / or may provide network traffic to them.

[0087] 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, a route reflector, a regional border router, or other types of routers. 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.

[0088] Server device 230 may include one or more devices capable of receiving, generating, storing, processing, providing, and / or routing information, as described elsewhere herein. Server device 230 may include a communication device and / or a computing device. For example, server device 230 may include a server, such as an application server, a client server, a network server, a database server, a host server, a proxy server, a virtual server (e.g., executed on computing hardware), or a server in a cloud computing system. In some implementations, server device 230 may include computing hardware used in a cloud computing environment.

[0089] 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, or 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-optic-based network, a cloud computing network, etc., and / or a combination of these or other types of networks.

[0090] 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.

[0091] Figure 3 yes Figure 2 300. The example components may be included in device 300, which may correspond to endpoint device 210, network device 220, and / or server device 230. In some implementations, endpoint device 210, network device 220, and / or server device 230 may include one or more devices 300 and / or one or more components of 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 ​​.

[0092] Bus 310 includes one or more components that enable wired and / or wireless communication between components of device 300. Bus 310 may include: Figure 3Two or more components of the computer system are coupled together, such as via operational coupling, communication coupling, electronic coupling, and / or electrical coupling. Processor 320 includes a central processing unit, a graphics processing unit, a microprocessor, a controller, a microcontroller, a digital signal processor, a field programmable gate array, an application specific integrated circuit, and / or another type of processing component. 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.

[0093] 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 being coupled to one or more processors (e.g., processor 320) via bus 310.

[0094] 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 assembly 360 enables device 300 to communicate with other devices via wired connection and / or wireless connection. For example, communication assembly 360 may include a receiver, a transmitter, a transceiver, a modem, a network interface card and / or an antenna.

[0095] 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) executed 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, hardwired circuitry can replace instructions or be used 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 specific combination of hardware circuitry and software.

[0096] Figure 3 The number and arrangement of components shown are provided as examples. Figure 3 Compared to the illustrated, the 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 the device 300 may perform one or more functions described as being performed by another set of components of the device 300.

[0097] 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 switch 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.

[0098] The input component 410 can be one or more attachment points of a physical link and can be one or more entry points for incoming traffic (such as packets). The input component 410 can process incoming traffic, such as by performing data link layer encapsulation or decapsulation. In some implementations, the input component 410 can 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.

[0099] The switch component 420 can interconnect the input component 410 with the output component 430. In some implementations, the switch component 420 can be implemented via one or more crossbar switches, via a bus, and / or through 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 transmission to the output component 430. In some implementations, the switch component 420 can enable the input component 410, the output component 430, and / or the controller 440 to communicate with each other.

[0100] The output component 430 can store packets and can schedule packets for transmission on an output physical link. The output component 430 can support data link layer encapsulation or decapsulation, and / or various higher-level protocols. In some implementations, the output component 430 can transmit packets and / or receive packets. In some implementations, the 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, the device 400 may include one or more output components 430. In some implementations, the input component 410 and the output component 430 can be implemented by the same set of components (e.g., the input component / output component can be a combination of the input component 410 and the output component 430).

[0101] The controller 440 includes a processor in the form of, for example, a CPU, a GPU, an 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.

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

[0103] 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 routing lookups for incoming and / or outgoing packets.

[0104] 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 a memory space within a single physical storage device or a memory space across multiple physical storage devices.

[0105] The software instructions may be read into a memory and / or storage component associated with the controller 440 from another computer-readable medium or from another device via a communication interface. 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.

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

[0107] Figure 5 is a flow chart of an example process 500 for providing IGP and traffic engineering sleep states for a network. In some implementations, Figure 5 One or more process blocks of may be performed by a network device (e.g., the first 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 an endpoint device (e.g., endpoint device 210) and / or 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 , switch component 420 , output component 430 , and / or controller 440 .

[0108] like Figure 5 As shown, process 500 may include identifying one or more components to transition to a sleep state (block 510). For example, a first network device may identify one or more components to transition to a sleep state, as described above.

[0109] like Figure 5 As further shown, process 500 may include powering off one or more components so that the link with the second network device is in a sleep state (block 520). For example, the first network device may power off one or more components so that the link with the second network device is in a sleep state, as described above. In some implementations, the sleep state associated with the one or more components includes one or more of: a power-off state, a reset state, a low power consumption state, a slowed clock rate state, or a wake-up-on-arrival state.

[0110] like Figure 5 As further shown, process 500 may include providing a link sleep state message identifying the link to the second network device (block 530). For example, the first network device may provide a link sleep state message identifying the link to the second network device, as described above. In some implementations, the second network device is configured to power off one or more components of the second network device associated with the link. In some implementations, the link sleep state message includes a sleep request bit set in the sleep type length value message.

[0111] like Figure 5As further shown, process 500 may include providing an updated link sleep state message to the second network device while the sleep state of the link is maintained (block 540). For example, the first network device may provide an updated link sleep state message to the second network device while the sleep state of the link is maintained, as described above. In some implementations, the updated link sleep state message causes the second network device to maintain neighbor adjacency with the first network device. In some implementations, each of the updated link sleep state messages includes a sleep request bit set in the sleep type length value message.

[0112] In some implementations, process 500 includes maintaining a neighbor adjacency with the second network device based on the updated link sleep state message.In some implementations, process 500 includes receiving a link sleep state message from the second network device, and maintaining a neighbor adjacency with the second network device based on the link sleep state message.

[0113] In some implementations, process 500 includes storing data identifying a link and a sleep state of the link in a link state database. In some implementations, process 500 includes pruning the link for shortest path tree calculation. In some implementations, process 500 includes moving a traffic engineering tunnel away from the link. In some implementations, process 500 includes transitioning one or more components and links from a sleep state to an active state based on business needs. In some implementations, process 500 includes performing a health check of the link to ensure that the link maintains a sleep state.

[0114] although Figure 5 Example blocks of process 500 are 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 of the blocks of process 500 may be performed in parallel.

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

[0116] As used herein, the term "component" is intended to be broadly interpreted as a combination of hardware, firmware, or hardware and software. Obviously, the system and / or method described herein can be implemented according to 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 system and / or method are described herein without reference to specific software codes-it should be understood that software and hardware can be used to implement the system and / or method based on the description herein.

[0117] Although particular combinations of features are set forth 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 may be combined in ways not specifically recited in the claims and / or disclosed in the specification. Although each dependent claim listed below may directly depend on only one claim, the disclosure of various implementations includes the combination of each dependent claim with every other claim in the claim set.

[0118] Unless explicitly stated, any element, action or instruction used in this article should not be interpreted as key or necessary. In addition, as used in this article, the article "a (a)" and "an (an)" are intended to include one or more projects, and can be used interchangeably with "one or more". In addition, as used in this article, the article "the (the)" is intended to include one or more projects combined with the article "the (the)" and quoted, and can be used interchangeably with "the one or more". In addition, as used in this article, the term "set" is intended to include one or more projects (for example, related projects, unrelated projects or related, unrelated project combinations, etc.), and can be used interchangeably with "one or more". If only one project is intended, phrase "only one project" or similar language is used. In addition, as used in this article, the term "has (has)", "have (have)", "having (having)" etc. are intended to be open terms. In addition, unless explicitly stated otherwise, the phrase "based on" is intended to represent "based at least in part". Furthermore, as used herein, the term "or" when used in tandem is inclusive and can be used interchangeably with "and / or" unless expressly stated otherwise (eg, if used in conjunction with "either" or "only one of").

[0119] 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: identifying, by the first network device, one or more components to transition to a sleep state; The first network device powers off the one or more components so that the link with the second network device is in a sleep state; Providing, by the first network device, a link sleep state message identifying the link to the second network device; as well as While the sleep state of the link is maintained, an updated link sleep state message is provided by the first network device to the second network device.

2. The method according to claim 1, further comprising: A neighbor adjacency is maintained with the second network device based on the updated link sleep state message.

3. The method according to claim 1, further comprising: receiving a link sleep state message from the second network device; as well as A neighbor adjacency is maintained with the second network device based on the link sleep state message. 4 . The method of claim 1 , wherein the second network device is configured to power off one or more components of the second network device associated with the link. 5 . The method of claim 1 , wherein the updated link sleep state message causes the second network device to maintain a neighbor adjacency with the first network device.

6. The method of claim 1, wherein the link sleep state message includes a sleep request bit set in a sleep type length value message.

7. The method of claim 1, wherein each of the updated link sleep state messages includes a sleep request bit set in a sleep type length value message.

8. A first network device, comprising: one or more memories; as well as One or more processors to: identifying one or more components to transition to a sleep state; powering off the one or more components so that the link with the second network device is in a sleep state; providing a link sleep state message identifying the link to the second network device; as well as providing an updated link sleep state message to the second network device while the sleep state of the link is maintained, Wherein each of the updated link sleep state messages includes a sleep request bit set in a sleep type length value message.

9. The first network device according to claim 8, wherein the one or more processors are further configured to: Data identifying the link and the sleep state of the link is stored in a link state database.

10. The first network device according to claim 8, wherein the one or more processors are further configured to: The links are pruned for shortest path tree calculation.

11. The first network device according to claim 8, wherein the one or more processors are further configured to: Move the traffic engineering tunnel away from the link.

12. The first network device of claim 8, wherein the sleep state associated with the one or more components comprises one or more of: a power-off state, a reset state, a low power state, a slowed clock rate state, or a wake-on-arrival state.

13. The first network device of claim 8, wherein the one or more processors are further configured to: The one or more components and the link are transitioned from the sleep state to an active state based on traffic demand.

14. The first network device of claim 8, wherein the one or more processors are further configured to: A health check of the link is performed to ensure that the link maintains the sleep state.

15. A non-transitory computer-readable medium storing a set of instructions, the set of instructions comprising: One or more instructions, which, when executed by one or more processors of a first network device, cause the first network device to: identifying one or more components to transition to a sleep state; powering off the one or more components so that the link with the second network device is in a sleep state; providing a link sleep state message identifying the link to the second network device; providing an updated link sleep state message to the second network device while the sleep state of the link is maintained; as well as A neighbor adjacency is maintained with the second network device based on the updated link sleep state message.

16. The non-transitory computer readable medium of claim 15, wherein the one or more instructions further cause the first network device to: receiving a link sleep state message from the second network device; and The neighbor adjacency with the second network device is maintained based on the link sleep state message.

17. The non-transitory computer readable medium of claim 15, wherein the one or more instructions further cause the first network device to: storing data identifying the link and the sleep state of the link in a link state database; and The links are pruned for shortest path tree calculation.

18. The non-transitory computer readable medium of claim 15, wherein the one or more instructions further cause the first network device to: Move the traffic engineering tunnel away from the link.

19. The non-transitory computer readable medium of claim 15, wherein the one or more instructions further cause the first network device to: The one or more components and the link are transitioned from the sleep state to an active state based on traffic demand.

20. The non-transitory computer readable medium of claim 15, wherein the one or more instructions further cause the first network device to: A health check of the link is performed to ensure that the link maintains the sleep state.

Images