# US 2014/0153577 A1 · Session-based forwarding

> Agents: this data is available as JSON from the patentgrep API and MCP server — see https://patentgrep.com/llms.txt

- Number: US 2014/0153577 A1
- Document ID: US20140153577A1
- Status: Published application
- Kind: A1
- Application number: 13/918,748
- Filed: 2013-06-14
- Published: 2014-06-05
- Earliest claimed: 2012-12-03
- Assignees: Aruba Networks, Inc.
- Applicants: Aruba Networks, Inc.
- Inventors: Ramsundar Janakiraman; Ravinder Verma; Bhanu S. Gopalasetty
- Web page: https://patentgrep.com/patent/US20140153577A1

## CPC

- H04L 47/28: in relation to timing considerations
- H04L 49/3009: {Header conversion, routing tables or routing tags}
- H04L 45/566: {Routing instructions carried by the data packet, e.g. active networks}
- H04L 47/122: by diverting traffic away from congested entities
- H04L 47/19: at layers above the network layer (network arrangements for networked applications for scheduling or organising the servicing of application requests H04L67/60)
- H04L 61/25: of the same type
- H04L 63/0272: {Virtual private networks}
- H04L 63/101: {Access control lists [ACL]}
- H04L: TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION (arrangements common to telegraphic and telephonic communication H04M)

## Abstract

The present disclosure discloses a method and network device for session based forwarding. Specifically, the disclosed system receives a first packet in a session, and performs a route lookup to determine a route for the first packet. Then, the system caches a reference to the route and a neighbor in the session, and also caches a reference to the session in a tunnel within which packets in the session are to be forwarded. Based on a comparison between the route version number cached in the session and the route version number in a route table corresponding to the route referenced by a route index in the session, the system determines whether the route is stale. If so, the system performs another route lookup to update the route. Moreover, the system uses cached reference to the session in the tunnel for forwarding subsequent packets in the session.

## Claims

### Claim 1

A method comprising:
receiving, by a network device, a first packet in a session;
performing, by the network device, a route lookup based on a header of the first packet to determine a route for the first packet; and
caching, by the network device, a reference to the route and a neighbor in the session such that subsequent packets in the session are routed based on the cached reference in lieu of subsequent route lookups.

### Claim 2 (depends on 1)

The method of claim 1, wherein the reference to the route comprises one or more of: a route index, a route version number, a neighbor index, and a neighbor index number.

### Claim 3 (depends on 1)

The method of claim 1, further comprising:
comparing, by the network device, a first route version number cached in the session and a second route version number in a route table corresponding to the route referenced by a route index in the session; and
determining, by the network device, that the route is stale in response to the first route version number being different from the second route version number.

### Claim 4 (depends on 3)

The method of claim 3, further comprising:
comparing, by the network device, a first neighbor index and version number cached in the session with a second neighbor index and version number in a neighbor table corresponding to the route referenced by the route index in the session; and
determining, by the network device, that the route is stale in response to the first neighbor index or version number being different from the second neighbor index or version number.

### Claim 5 (depends on 4)

The method of claim 4, further comprising:
in response to determining that the route is stale, performing another route lookup to update the route with one or more of an updated route index, an updated route version number, an updated neighbor index, and an updated neighbor version number.

### Claim 6 (depends on 4)

The method of claim 4, further comprising:
in response to determining that the route is stale and the session is inactive, delaying route lookup until at least one packet is received in the session.

### Claim 7 (depends on 3)

The method of claim 3, wherein at least two paths with identical cost corresponding to the route are stored in the route table, each path being identified by a unique Equal Cost Multiple Path (ECMP) index.

### Claim 8 (depends on 7)

The method of claim 7, wherein, when a new ECMP index is added to the route table, a subsequent session uses the path associated with the new ECMP index and an existing session continues to use an existing path associated with an existing ECMP index.

### Claim 9 (depends on 4)

The method of claim 4, wherein, when at least two next hop nodes use Virtual Router Redundancy Protocol (VRRP), the route is determined to be stale based on difference between the first neighbor version number cached in the session and the second neighbor version number corresponding to the route in the neighbor table.

### Claim 10 (depends on 3)

The method of claim 3, further comprising:
in response to the route determined to be stale, performing another route lookup to update the session with an updated route index and an updated route version number;
in response to the updated route index and the updated route version corresponding to a shorter alternative route than the route, forwarding subsequent packets in the session using the shorter alternative route.

### Claim 11 (depends on 10)

The method of claim 10, wherein the shorter alternative route is stored in a patricia trie as a child node of a parent node, wherein the parent node corresponds to the route, and wherein a route version number of the route corresponding to the parent node is increased in response to the child node being inserted in the patricia trie.

### Claim 12 (depends on 1)

The method of claim 1, further comprising:
caching, by the network device, a reference to the session in a tunnel within which packets in the session are to be forwarded, thereby allowing direct access to the route from the tunnel.

### Claim 13 (depends on 1)

The method of claim 1, further comprising:
encapsulating, by the network device, the first packet based on information returned from a bridge lookup prior to encrypting the first packet;
identifying, by the network device, a network interface that the first packet is to be transmitted on;
sending the first packet to a security engine of the network device to encrypt the first packet; and
instructing the security engine to forward encrypted first packet to the identified network interface in lieu of returning the encrypted first packet to a processor within the network device.

### Claim 14

A network device having a symmetric multiprocessing architecture, the network device comprising:
a plurality of CPU cores;
a network interface to receive one or more data packets; and
a memory whose access is shared by the dedicated CPU core and the plurality of CPU cores;
wherein the plurality of CPU cores are to:
receive a first packet in a session;
perform a route lookup based on a header of the first packet to determine a route for the first packet; and
cache a reference to the route and a neighbor in the session such that subsequent packets in the session are routed based on the cached reference in lieu of subsequent route lookups.

### Claim 15 (depends on 14)

The network device of claim 14, wherein the reference to the route comprises one or more of: a route index, a route version number, a neighbor index, and a neighbor index number.

### Claim 16 (depends on 14)

The network device of claim 14, wherein the plurality of CPU cores are further to:
compare a first route version number cached in the session and a second route version number in a route table corresponding to the route referenced by a route index in the session; and
determine that the route is stale in response to the first route version number being different from the second route version number.

### Claim 17 (depends on 16)

The method of claim 16, wherein the plurality of CPU cores are further to:
compare a first neighbor index and version number cached in the session with a second neighbor index and version number in a neighbor table corresponding to the route referenced by the route index in the session; and
determine that the route is stale in response to the first neighbor index or version number being different from the second neighbor index or version number.

### Claim 18 (depends on 17)

The network device of claim 17, wherein the plurality of CPU cores are further to:
perform another route lookup to update the route with one or more of an updated route index, an updated route version number, an updated neighbor index, and an updated neighbor version number in response to determining that the route is stale.

### Claim 19 (depends on 17)

The network device of claim 17, wherein the plurality of CPU cores are further to:
delay route lookup until at least one packet is received in the session in response to determining that the route is stale and the session is inactive.

### Claim 20 (depends on 16)

The network device of claim 16, wherein at least two paths with identical costs corresponding to the route are stored in the route table, each path being identified by a unique Equal Cost Multiple Path (ECMP) index.

### Claim 21 (depends on 20)

The network device of claim 20, wherein, when a new ECMP index is added to the route table, a subsequent session uses the path associated with the new ECMP index and an existing session continues to use an existing path associated with an existing ECMP index.

### Claim 22 (depends on 17)

The network device of claim 17, wherein, when at least two next hop nodes use Virtual Router Redundancy Protocol (VRRP), the route is determined to be stale based on difference between the first neighbor version number cached in the session and the second neighbor version number corresponding to the route in the neighbor table.

### Claim 23 (depends on 16)

The network device of claim 16, wherein the plurality of CPU cores further to:
perform another route lookup to update the session with an updated route index and an updated route version number in response to the route determined to be stale;
forward subsequent packets in the session using the shorter alternative route in response to the updated route index and the updated route version corresponding to a shorter alternative route than the route.

### Claim 24 (depends on 23)

The network device of claim 23, wherein the shorter alternative route is stored in a patricia trie as a child node of a parent node, wherein the parent node corresponds to the route, and wherein a route version number of the route corresponding to the parent node is increased in response to the child node being inserted in the patricia trie.

### Claim 25 (depends on 14)

The network device of claim 14, wherein the plurality of CPU cores are further to:
cache a reference to the session in a tunnel within which packets in the session are to be forwarded, thereby allowing direct access to the route from the tunnel.

### Claim 26 (depends on 14)

The network device of claim 14, wherein the plurality of the CPU cores are further to:
encapsulate the first packet based on information returned from a bridge lookup prior to encrypting the first packet;
identify a network interface that the first packet is to be transmitted on;
send the first packet to a security engine of the network device to encrypt the first packet; and
instruct the security engine to forward encrypted first packet to the identified network interface in lieu of returning the encrypted first packet to a processor within the network device.

### Claim 27

A non-transitory computer-readable storage medium storing embedded instructions for a plurality of operations that are executed by one or more mechanisms implemented within a network device having a symmetric multiprocessing architecture, the plurality of operations comprising:
receiving a first packet in a session;
performing a route lookup to determine a route for the first packet;
caching a reference to the route in the session;
caching a reference to the session and a neighbor in a tunnel within which packets in the session are forwarded;
comparing a first route version number cached in the session with a second route version number in a route table corresponding to the route referenced by a route index in the session;
determining whether the route is stale based on the first and second route version numbers;
performing another route lookup to update the route in response to determining that the route is stale; and
using cached reference to the session in the tunnel for forwarding subsequent packets in the session.