Cisco Technology, Inc.

Jeff Apcar

Jean-Philippe Vasseur

Thomas Szigeti

David John Zacks

Jim Guichard

Robert H Thomas

Oliver Boehmer

Techniques for a TCP proxy to communicate over a LEO satellite network on behalf of a client device by selecting a TCP congestion-control algorithm that is optimal for the LEO satellite network based on the time of day and/or location of the TCP proxy. Based on the locations of satellites during the day as they traverse predefined and patterned orbital paths, different TCP congestion-control algorithms may be more optimized to communicate data through the LEO satellite network. However, client devices generally use a single TCP congestion-control algorithm to communicate over WAN networks. Accordingly, a TCP proxy may be inserted on, for example, a router to communicate with the client device using a TCP congestion-control algorithm that the client device is configured to use, but then communicate over the LEO satellite network using a different TCP congestion-control algorithm that is optimal based on the time of day and/or other factors.

Dynamically enabling a transport control protocol proxy for satellite networks

In one embodiment, an apparatus is disclosed that includes one or more device interfaces, a processor coupled to the one or more device interfaces and configured to execute a process, and a memory configured to store the process executable by the processor. The process when executed is operable to receive condition data regarding a measured condition of a zone of a data center. The process when executed is also operable to determine a visual effect for a portion of a light strip based on the condition data. The portion of the light strip is associated with the zone and is located in the zone. The process when executed is further operable to control the portion of the light strip to display the determined visual effect.

Visual indication of data center conditions

In one embodiment, a path for a sliced tunnel that extends from a head-end node to a tail-end node is computed. The sliced tunnel is furcated into a plurality of child tunnels at one or more fork nodes located downstream from the head-end node. Each child tunnel carries a portion of traffic for the sliced tunnel. The sliced tunnel is merged at one or more merge nodes located downstream from respective ones of the fork nodes. The portions of traffic on the child tunnels are aggregated at the merge nodes. The head-end node sends a signaling message to establish the sliced tunnel along the computed path. The signaling message includes an indication of the one or more fork nodes where the sliced tunnel is furcated into child tunnels and the one or more merge nodes where child tunnels are merged. The head-end node then forwards traffic onto the sliced tunnel.

Sliced tunnels in a computer network

In one embodiment, a sliced tunnel is signaled between a head-end node and a tail-end node. One or more fork nodes along the sliced tunnel are configured to furcate the sliced tunnel into a plurality of child tunnels of the sliced tunnel. Also, one or more merge nodes along the sliced tunnel are configured to merge a plurality of child tunnels of the sliced tunnel that intersect at the merge node.

In one embodiment, one or more tunnel mesh groups may be established in at least a portion of a computer network, where each tunnel mesh group corresponds to a differentiated routing profile. Traffic may then be received at the portion of the computer network, the traffic indicating a particular differentiated routing profile (e.g., based on a received label corresponding to the differentiated routing profile as advertised by the portion of the computer network). Accordingly, the traffic may be routed through the portion of the computer network along a tunnel of a particular tunnel mesh group corresponding to the particular differentiated routing profile traffic.

Differentiated routing using tunnels in a computer network

A technique dynamically splits Traffic Engineering (TE) Label Switched Paths (LSPs) in a computer network. According to the novel technique, a head-end node may determine that a TE-LSP to a destination needs to be sized to a larger bandwidth (a 'larger' TE-LSP) than currently available over a single path to the destination (e.g., a path that may also be required to meet other constraints, such as cost, delay, etc.). In response, the head-end node may dynamically 'split' the larger TE-LSP, and create a first split TE-LSP over a best (e.g., shortest) available path (e.g., that meets other constraints). The first split TE-LSP may reserve a maximum available bandwidth for that best available path. The head-end node may then continue recursively creating subsequent split TE-LSPs for any remaining bandwidth of the larger TE-LSP over available paths until the larger TE-LSP may no longer be split (e.g., all bandwidth has been placed, configurable maximum number of splits reached, etc.). Notably, the split TE-LSPs may be &#x201c;re-groomed&#x201d; at a later time to recombine and reorganize the split TE-LSPs.

Growing community of inventors

Willoughby, Australia

Jeff Apcar