U.S. patent application number 17/685986 was filed with the patent office on 2022-06-16 for malleable routing for data packets.
This patent application is currently assigned to Cisco Technology, Inc.. The applicant listed for this patent is Cisco Technology, Inc.. Invention is credited to Francois Clad, Clarence Filsfils, Jose Antonio Liste, Peter Psenak.
Application Number | 20220191134 17/685986 |
Document ID | / |
Family ID | |
Filed Date | 2022-06-16 |
United States Patent
Application |
20220191134 |
Kind Code |
A1 |
Filsfils; Clarence ; et
al. |
June 16, 2022 |
MALLEABLE ROUTING FOR DATA PACKETS
Abstract
Various implementations disclosed herein enable malleable
routing for data packets. For example, in various implementations,
a method of routing a type of data packets is performed by a
device. In some implementations, the device includes a
non-transitory memory and one or more processors coupled with the
non-transitory memory. In some implementations, the method includes
determining a routing criterion to transmit a set of data packets
across a network. In some implementations, the method includes
identifying network nodes and communication links in the network
that satisfy the routing criterion. In some implementations, the
method includes determining a route for the set of data packets
through the network nodes and the communication links that satisfy
the routing criterion. In some implementations, the method includes
configuring the network nodes that are on the route with
configuration information that allows the set of data packets to
propagate along the route.
Inventors: |
Filsfils; Clarence;
(Brussels, BE) ; Psenak; Peter; (Bratislava,
SK) ; Clad; Francois; (Strasbourg, FR) ;
Liste; Jose Antonio; (Sunnyvale, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Cisco Technology, Inc. |
San Jose |
CA |
US |
|
|
Assignee: |
Cisco Technology, Inc.
San Jose
CA
|
Appl. No.: |
17/685986 |
Filed: |
March 3, 2022 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
17360283 |
Jun 28, 2021 |
|
|
|
17685986 |
|
|
|
|
15986174 |
May 22, 2018 |
11050662 |
|
|
17360283 |
|
|
|
|
62527611 |
Jun 30, 2017 |
|
|
|
International
Class: |
H04L 45/30 20060101
H04L045/30; H04L 45/50 20060101 H04L045/50; H04L 41/0813 20060101
H04L041/0813; H04L 45/12 20060101 H04L045/12; H04L 45/44 20060101
H04L045/44; H04L 45/42 20060101 H04L045/42 |
Claims
1. A method comprising: at each of plurality of network nodes,
wherein each network node supports routing packets according to a
uniform routing criterion, indicating over the network one or more
routing capabilities supported by the network node, each routing
capability being associated with one or more alternative routing
criteria to the uniform routing criterion; receiving, by a first
node, the indications regarding the routing capabilities supported
by each of the plurality of network nodes; determining, at the
first node, one or more alternative routing criteria to use to
transmit a first set of data packets across a network, the one or
more alternative routing criteria chosen to control the latency of
the data packets as they traverse the network; identifying, based
at least in part on the received indications, one or more nodes
from the plurality of nodes that support the routing capability
associated with the determined one or more alternative routing
criteria; determining a route for the first set of data packets
through the network nodes and the communication links that support
the routing capability and controls the latency; and propagating
the first set of data packets along the determined route.
2. The method of claim 1 wherein the path taken by the first set of
packets traversing the system is different than a route taken by a
second set of packets traversing the system using a route
calculated using the uniform criterion.
3. The method of claim 1, wherein determining the route that
controls the latency includes minimizing the latency of the set of
data packets traversing the network.
4. The method of claim 1, wherein determining the route that
controls the latency includes reducing the latency of the set of
data packets traversing the network relative to the uniform routing
criterion.
5. The method of claim 3, wherein determining a route for the set
of data packets through the network nodes and the communication
links that controls the latency includes computing the route
according to Dijkstra's algorithm.
6. The method of claim 1, wherein two or more network nodes from
the plurality of nodes each receive the indications from other
nodes regarding the routing capabilities supported by other network
nodes; and wherein each network node from the two or more network
nodes determines a forwarding entry for each alternative routing
capability based in part upon the indications received from other
network nodes.
7. A system for configurable traffic routing comprising: a
plurality of network nodes, each network node including a network
interface, a non-transitory memory and one or more processors
coupled with the non-transitory memory, wherein each network node
supports routing packets according to a uniform routing criterion,
and is further configured to support routing capabilities, each
routing capability being associated with one or more
operator-defined criteria, and wherein each network node transmits
an indication of the supported routing capabilities on the network
interface; a communications network with links interconnecting the
plurality of network nodes in a physical topology; the system
further including a criterion determination module, a node/link
determination module, and a route determination module; wherein the
criterion determination module is configured to determine one or
more operator-defined routing criteria to transmit a set of data
packets across a network, wherein the one or more operator-defined
routing criteria are associated with a routing capability, and
wherein the one or more operator-defined routing criteria are
associated with control of a network performance metric; wherein
the node/link determination module is configured to identify
network nodes and communication links in the network that satisfy
the routing capability; and wherein the route determination module
is configured to use the one or more operator-defined routing
criteria to identify a route for data packets through the network
nodes and the communication links that support the routing
capability and control the network performance metric; wherein the
system is operable to configure the set of network nodes and links
corresponding to the route identified by the route determination
module to exchange a first set of packets traversing the system
using the identified route.
8. The system of claim 7 wherein the path taken by the first set of
packets traversing the system is different than a route taken by a
second set of packets traversing the system using a route
calculated using the uniform criterion.
9. The system of claim 8 wherein the uniform criterion is a
shortest route criterion.
10. The system of claim 7, wherein the network performance metric
is a latency measurement.
11. The system of claim 10, wherein the path taken by the first set
of packets minimizes the latency associated with traversing the
network.
12. The system of claim 10, wherein the path taken by the first set
of packets reduces the latency associated with traversing the
network relative to the uniform routing criterion.
13. The system of claim 7, wherein the route determination module
uses the network performance metric as an input to Dijkstra's
algorithm to identify the route for data packets through the
network nodes.
14. The system of claim 7 wherein more than one node includes a
node/link determination module and a route determination
module.
15. A non-transitory computer-readable medium containing logic
which, when executed by one or more processors: at each of a
plurality of network nodes, each network node supporting routing
packets according to a uniform routing criterion, indicate one or
more routing capabilities supported by the network node, each
routing capability being associated with a one or more
operator-defined alternative routing criteria; receive, by a first
network node, the indications regarding the routing capabilities
supported by each of the plurality of network nodes; determine, at
the first network node, one or more operator-defined alternative
criteria to use to route a first set of data packets across a
network, the one or more operator-defined alternative criteria
chosen to control the latency of the first set data packets as they
traverse the network; identify, based at least in part on the
received indications, one or more network nodes from the plurality
of network nodes that support the routing capability associated
with the determined one or more operator-defined alternative
criteria; determine a route for the first set of data packets
through the network nodes and the communication links that supports
the routing capability and controls the latency using at least one
operator-defined criterion; and propagate the first set of data
packets along the determined route.
16. The logic of claim 15, wherein the path taken by the first set
of packets traversing the system is different than a route taken by
a second set of packets traversing the system using a route
calculated using a shortest route criterion.
17. The logic of claim 15, wherein determining the route that
controls the latency of the first set of data packets as they
traverse the network includes minimizing the latency of the first
set of data packets traversing the network.
18. The logic of claim 15, wherein determining the route that
controls the latency of the first set of data packets as they
traverse the network includes reducing the latency of the first set
of data packets traversing the network relative to the latency of a
second set of data packets traversing the network via a route
computed using the uniform routing criterion.
19. The logic of claim 20, wherein determining a route for the set
of data packets through the network nodes and the communication
links that support the routing capability and controls the latency
includes computing the route according to Dijkstra's algorithm
using the latency as an input.
20. The logic of claim 16, wherein two or more network nodes from
the plurality of network nodes each include logic to: receive the
indications from other network nodes regarding the routing
capabilities supported by the other network nodes; and determine a
forwarding entry for each routing capability supported based in
part upon the indications received from other network nodes.
Description
PRIORITY CLAIM
[0001] This application is a continuation of and claims priority to
U.S. patent application Ser. No. 17/360,283 filed Jun. 28, 2021,
which claims priority to U.S. patent application Ser. No.
15/986,174 filed May 22, 2018, which issued as U.S. Pat. No.
11,050,662, on Jun. 29, 2021, and claims priority to U.S.
Provisional Patent Application No. 62/527,611 filed on Jun. 30,
2017, the disclosure of each application, in its entirety is hereby
incorporated herein by reference.
TECHNICAL FIELD
[0002] The present disclosure relates generally to routing, and in
particular, to malleable routing for data packets.
BACKGROUND
[0003] In some previously available networks, data packets are
routed based on a fixed rule that aims to optimize a specific
metric. For example, in some previously available networks, data
packets are routed based on a shortest path algorithm. However,
fixed rules are sometimes unsuitable for certain types of data
packets. For example, not all data packets need to be routed based
on the shortest path algorithm. As an example, some data packets
may need to be routed via network nodes that support a heightened
level of encryption even if such network nodes are not on the
shortest path.
BRIEF DESCRIPTION OF THE DRAWINGS
[0004] So that the present disclosure can be understood by those of
ordinary skill in the art, a more detailed description may be had
by reference to aspects of some illustrative implementations, some
of which are shown in the accompanying drawings.
[0005] FIGS. 1A-1F are schematic diagrams of a network environment
that allows malleable routing for data packets in accordance with
some implementations.
[0006] FIG. 2A is a flowchart representation of a method of
configuring network nodes in a network in accordance with some
implementations.
[0007] FIG. 2B is a flowchart representation of a method of
propagating data packets in accordance with some
implementations.
[0008] FIG. 3 is a block diagram of a device enabled with various
modules that are provided to configure network nodes and propagate
data packets in accordance with some implementations.
[0009] In accordance with common practice the various features
illustrated in the drawings may not be drawn to scale. Accordingly,
the dimensions of the various features may be arbitrarily expanded
or reduced for clarity. In addition, some of the drawings may not
depict all of the components of a given system, method or device.
Finally, like reference numerals may be used to denote like
features throughout the specification and figures.
DESCRIPTION OF EXAMPLE EMBODIMENTS
[0010] Numerous details are described herein in order to provide a
thorough understanding of the illustrative implementations shown in
the accompanying drawings. However, the accompanying drawings
merely show some example aspects of the present disclosure and are
therefore not to be considered limiting. Those of ordinary skill in
the art will appreciate from the present disclosure that other
effective aspects and/or variants do not include all of the
specific details of the example implementations described herein.
While pertinent features are shown and described, those of ordinary
skill in the art will appreciate from the present disclosure that
various other features, including well-known systems, methods,
components, devices, and circuits, have not been illustrated or
described in exhaustive detail for the sake of brevity and so as
not to obscure more pertinent aspects of the example
implementations disclosed herein.
OVERVIEW
[0011] Various implementations disclosed herein enable malleable
routing for data packets. For example, in various implementations,
a method of routing a type of data packets is performed by a
device. In some implementations, the device includes a
non-transitory memory and one or more processors coupled with the
non-transitory memory. In some implementations, the method includes
determining a routing criterion to transmit a set of data packets
across a network. In some implementations, the method includes
identifying network nodes and communication links in the network
that satisfy the routing criterion. In some implementations, the
method includes determining a route for the set of data packets
through the network nodes and the communication links that satisfy
the routing criterion. In some implementations, the method includes
configuring the network nodes that are on the route with
configuration information that allows the set of data packets to
propagate along the route.
EXAMPLE EMBODIMENTS
[0012] Some networks treat various types of data packets equally.
For example, some networks route different types of data packets
according to the same routing criterion (e.g., routing algorithm).
Many networks primarily utilize a shortest route criterion (e.g.,
the shortest path algorithm) to route data packets. In such
networks, data packets corresponding to a video download are routed
according to the same criterion as data packets corresponding to a
phone call. This rigid approach of routing data packets according
to a fixed criterion is sometimes unsuitable for certain types of
data packets. For example, while the shortest route criterion may
be suitable for data packets corresponding to a phone call, the
shortest route criterion may be unsuitable for data packets
corresponding to an encrypted file transfer.
[0013] The present disclosure provides methods, systems and/or
devices that enable malleable routing for data packets. In some
implementations, different routing criteria are utilized to
transport different types of data packets. In some implementations,
different routing criteria include different routing algorithms or
different routing schemes. This flexible approach of utilizing
different routing criteria for different types of data packets
tends to result in routes that are more suitable for the type of
data packets. For example, in some implementations, the shortest
route criterion is utilized to route data packets corresponding to
a phone call but a different routing criterion is utilized to route
data packets corresponding to an encrypted file transfer. The
present disclosure provides more configuration options to network
operators by allowing the network operators to support different
routing criteria. For example, the present disclosure enables a
network operator to support an existing routing criterion, support
a modified version of an existing routing criterion, and/or create
a new routing criterion. The present disclosure also provides more
configuration options for individual network nodes. For example,
the present disclosure enables a network node to install
configuration information for an existing routing criterion, a
modified version of an existing routing criterion, and/or a new
routing criterion.
[0014] FIGS. 1A-1F are schematic diagrams of a network environment
10 that allows malleable routing for data packets in accordance
with some implementations. While certain specific features are
illustrated, those of ordinary skill in the art will appreciate
from the present disclosure that various other features have not
been illustrated for the sake of brevity and so as not to obscure
more pertinent aspects of the example implementations disclosed
herein. To that end, the network environment 10 includes client
devices A and B, various network nodes N1, N2 . . . N9, various
communication links L1, L2 . . . L19, and a network controller 20.
Although the network controller 20 is shown as being separate from
the network nodes N1, N2 . . . N9, in some implementations, the
network controller 20 is implemented by one or more of the network
nodes N1, N2 . . . N9. In other words, in some implementations, the
network controller 20 is distributed across one or more of the
network nodes N1, N2 . . . N9.
[0015] Referring to FIG. 1B, in various implementations, the
network nodes N1 . . . N9 support one or more routing criteria. For
example, in some implementations, the network nodes N1 . . . N9
support one or more routing algorithms. In the example of FIG. 1B,
the network node N1 supports algorithm (Alg) x, the network node N2
supports Alg.s x and y, the network node N3 supports Alg.s x and z,
the network node N4 supports Alg.s x and y, the network node N5
supports Alg.s x, y and z, the network node N6 supports Alg.s y and
z, the network node N7 supports Alg z, the network node N8 support
Alg.s x and z, the network node N9 supports Alg.s x and z. In some
implementations, the network nodes N1 . . . N9 are configured to
route data packets in accordance with the routing criteria (e.g.,
the routing algorithm) that the network nodes N1 . . . N9 support.
For example, the network node N1 is configured to route data
packets in accordance with Alg x.
[0016] In some implementations, data packets that are to be routed
in accordance with a particular routing criterion are propagated
along a route that includes network nodes that support that
particular routing criterion. In the example of FIG. 1B, data
packets that are to be routed in accordance with Alg x may be
transmitted along a route that includes network node N1 or network
node N4. However, data packets that are to be routed in accordance
with Alg y are transmitted along a route that includes network node
N4, and not network node N1.
[0017] Referring to FIG. 1C, in some implementations, some network
nodes indicate (e.g., advertise, broadcast and/or publish) the
routing criteria that the network nodes support. In some
implementations, the network nodes indicate their support for a
particular routing criterion via a router capability (RC). In some
implementations, the network nodes are associated with a respective
set of router capabilities. In some implementations, a network node
utilizes a first router capability to indicate the definition of a
routing criterion, a second router capability to indicate whether
or not the network node supports the routing criterion, and a third
router capability to indicate a segment identifier (SID) that is
associated with the routing criterion. In the example of FIG. 1C, a
router capability of network node N1 indicates that the SID for Alg
x is 16,001. In the example of FIG. 1C, a router capability of
network node N2 indicates that the SID for Alg x is 16,002 and the
SID for Alg y is 16,102. In the example of FIG. 1C, a router
capability of network node N5 indicates that the SID for Alg x is
16,005, the SID for Alg y is 16,105 and the SID for Alg z is
16,205. In the example of FIG. 1C, a router capability of network
node N9 indicates that the SID for Alg x is 16,009 and the SID for
Alg z is 16,209. In some implementations, some network nodes do not
advertise the routing criteria that the network nodes support. In
some implementations, some network nodes are not associated with
SIDs. For example, in FIG. 1C, network nodes N3, N4, N7 and N8 are
associated with any SIDs. In some implementations, some network
nodes have SIDs for some routing criteria while not for other
routing criteria. For example, in FIG. 1C, the network node N6 has
an SID for Alg y but the network node N6 does not have an SID for
Alg z.
[0018] Referring to FIG. 1D, in various implementations, the
network nodes N1 . . . N9 install configuration information that
allows the network nodes N1 . . . N9 to direct (e.g., propagate or
transmit) data packets in accordance with different routing
criteria. In some implementations, the configuration information
includes forwarding entries that indicate downstream network nodes
that support the routing criterion being used to transmit data
packets. In some implementations, the forwarding entries include a
mapping of SIDs to downstream network nodes that are associated
with the SIDs. In the example of FIG. 1D, the network node N1
includes forwarding entries that map SIDs 16,002, 16,005 and 16,009
to the network node N2. As such, the network node N1 transmits any
data packets that are labeled with SID 16,002, 16,005 or 16,009 to
the network node N2. In the example of FIG. 1D, the network node N2
includes forwarding entries that map SID 16,009 to network node N3,
and SID 16,106 to network node N6. As such, the network node N2
transmits any data packets that are labeled with SID 16,009 to
network node N3, and any data packets that are labeled with SID
16,106 to network node N6. In the example of FIG. 1D, the network
node N5 includes forwarding entries that map SID 16,009 to network
node N9. As such, the network node N5 transmits any data packets
that are labeled with SID 16,009 to network node N9.
[0019] In some implementations, the forwarding entries (e.g., the
configuration information) are installed at the network nodes in
response to the network nodes being on a route that is being used
to transport data packets. In some implementations, the forwarding
entries are installed at the network nodes by a controller (e.g.,
the network controller 20 shown in FIG. 1A). For example, in some
implementations, the controller pushes the forwarding entries to
the network nodes after determining that the network nodes are on a
selected route for transporting data packets. In some
implementations, the forwarding entries are installed on the
network nodes that are on the route, and not on the network nodes
that are not on the route. More generally, in various
implementations, network nodes that are on a route for transporting
a set of data packets are configured with configuration
information.
[0020] In various implementations, the configuration information is
updated when data packets are transmitted using a different routing
criterion. For example, in some implementations, different
forwarding entries are installed when data packets are transmitted
using different routing algorithms. More generally, in various
implementations, the configuration information (e.g., the
forwarding entries) are based on the routing criterion (e.g., the
routing algorithm) that is being used to transport the data
packets. Updating the configuration information (e.g., updating the
forwarding entries) allows more flexibility in transporting data
packets using different routing criteria (e.g., different routing
algorithms). For example, with reference to FIG. 1D, updating the
forwarding entries enables transporting a first set of data packets
in accordance with Alg x, a second set of data packets in
accordance with Alg y, and a third set of data packets in
accordance with Alg z.
[0021] Referring to FIG. 1E, the network obtains a request to
transmit a set of data packets 100 from client device A to client
device B. In the example of FIG. 1E, the set of data packets are
labeled with a MPLS (multiprotocol label switching) label of
16,009. The MPLS label of 16,009 indicates that the set of data
packets are to be transmitted in accordance with Alg x because
16,009 is the SID for Alg x at network node N9. More generally, in
various implementations, the set of data packets 100 indicates a
routing criterion that is to be used to transport the set of data
packets 100. In some implementations, the MPLS label is applied to
the set of data packets 100 by the network node N1, the network
controller 20 shown in FIG. 1A and/or the client device A.
[0022] FIG. 1E illustrates a route which includes network nodes
that support Alg x--the routing criterion that is to be used to
transport the set of data packets 100. As illustrated in FIG. 1E,
the route includes network nodes N1, N2, N5 and N9, and
communication links L1, L2, L6, L14 and L19. In operation, the
network node N1 receives the set of data packets 100. Since the set
of data packets 100 are labeled with 16,009, in accordance with the
forwarding entries installed at network node N1, network node N1
forwards the set of data packets 100 to network node N2. Network
node N2 receives the set of data packets 100 from network node N1
over the communication link L2. Since the set of data packets 100
are labeled with 16,009, in accordance with the forwarding entries
installed at network node N2, network node N2 forwards the set of
data packets 100 to network node N5. Network node N5 receives the
set of data packets 100 from network node N2 over the communication
link L6. Since the set of data packets 100 are labeled with 16,009,
in accordance with the forwarding entries installed at network node
N5, network node N5 forwards the set of data packets 100 to network
node N9. Network node N9 receives the set of data packets 100 from
network node N5 over the communication link L14. Network node N9
forwards the set of data packets 100 to the client device B over
the communication link L19.
[0023] In the example of FIG. 1E, the network nodes N1, N2, N5 and
N9 on the route satisfy the routing criterion associated with the
set of data packets 100. For example, the network nodes N1, N2, N5
and N9 support Alg x. Network nodes that do not support the routing
criterion associated with the set of data packets 100 are not
included in the route. For example, network nodes N7 and N6 are not
included in the route. In some implementations, a controller (e.g.,
the network controller 20 shown in FIG. 1A) identifies all network
nodes that support the routing criterion associated with the set of
data packets 100. For example, the controller identifies that
network nodes N1, N2, N3, N4, N5, N8 and N9 support Alg x. In some
implementations, the controller determines the shortest/fastest
route through the network nodes that support the routing criterion
associated with the set of data packets 100. In the example of FIG.
1E, the shortest/fastest route includes network nodes N1, N2, N5
and N9.
[0024] Referring to FIG. 1F, in various implementations, the
routing criterion indicates one or more restrictions (e.g.,
exclusionary constraints). In some implementations, the
exclusionary constraints indicate characteristics of network nodes
and/or communication links that are to be avoided. In such
implementations, the determined route does not include network
nodes and/or communication links with characteristics that match
the exclusionary constraints. In the example of FIG. 1F, the
communication link L6 is associated with affinity red. Moreover, in
the example of FIG. 1F, one of the exclusionary constraints
associated with the routing criterion (e.g., with Alg x) is to
avoid communication links with affinity red. As such, in the
example of FIG. 1F, the route does not include communication link
L6. Instead of communication link L6, the route in the example of
FIG. 1F includes communication links L3 and L7.
[0025] In various implementations, the routing criterion for the
set of data packets 100 is determined based on a type of the data
packets 100. For example, in some implementations, if the set of
data packets 100 correspond to streaming video, then the routing
criterion for the set of data packets 100 is set to Alg x. In some
implementations, if the set of data packets 100 correspond to
messaging, then the routing criterion for the set of data packets
100 is set to Alg y. In some implementations, if the set of data
packets 100 correspond to encrypted traffic, then the routing
criterion for the set of data packets 100 is set to Alg z. In some
implementations, the routing criterion for the set of data packets
100 is set by the client device A. In some implementations, the
routing criterion for the set of data packets 100 is set by network
node N1. In some implementations, the routing criterion for the set
of data packets 100 is set by a controller (e.g., by the network
controller 20 shown in FIG. 1A).
[0026] In the example of FIG. 1A, the network controller 20 is
shown as being separate from the network nodes N1 . . . N9.
However, in some implementations, the network controller 20 resides
at one or more of the network nodes N1 . . . N9. In some
implementations, the network controller 20 is distributed across
various computing devices. For example, in some implementations,
the network controller 20 is implemented by a cloud computing
system. In the example of FIG. 1A, a single instance of the network
controller 20 is shown. However, in some implementations, there are
multiple instances of the network controller 20. For example, in
some implementations, different network controllers control
different parts of the network. In some implementations, the
network nodes N1 . . . N9 are controlled by different network
operating entities. In such implementations, each network operating
entity utilizes a network controller to control its network
nodes.
[0027] FIG. 2A is a flowchart representation of a method 200 of
configuring network nodes (e.g., the network nodes N1 . . . N9
shown in FIGS. 1A-1F) in a network in accordance with some
implementations. In various implementations, the method 200 is
implemented as a set of computer readable instructions that are
executed at a device (e.g., the network controller 20 shown in FIG.
1A, one or more of the network nodes N1 . . . N9 shown in FIGS.
1A-1F and/or the device 300 shown in FIG. 3). Briefly, the method
200 includes determining a routing criterion to transmit a set of
data packets (210), identifying network nodes and communication
links that satisfy the routing criterion (220), determining a route
for the set of data packets through the network nodes and the
communication links that satisfy the routing criterion (230), and
configuring the network nodes that are on the route with
configuration information that allows the set of data packets to
propagate along the route (240).
[0028] As represented by block 210, in various implementations, the
method 200 includes determining a routing criterion to transmit a
set of data packets across a network. For example, in some
implementations, the method 200 includes determining a routing
algorithm to transmit the set of data packets across a set of
interconnected network nodes. As represented by block 210a, in some
implementations, the method 200 includes determining the routing
criterion based on the set of data packets. In some
implementations, the method 200 includes determining the routing
criterion based on a type of the set of data packets. For example,
in some implementations, the type indicates whether the set of data
packets carry messaging data (e.g., messages from an instant
messaging application), media data (e.g., videos, music,
etc.),voice data, file transfer data, streaming data (e.g., video
streaming data, audio streaming data, etc.), and/or encrypted data.
In some implementations, the method 200 includes selecting a first
routing criterion for data packets that correspond to video
streaming, selecting a second routing criterion for data packets
that correspond to messaging, and selecting a third routing
criterion for data packets that correspond to all other types of
traffic. As represented by block 210b, income implementations, the
method 200 includes selecting the routing criterion from a
plurality of routing criteria. In some implementations, the method
200 includes determining the routing criterion by selecting an
existing routing criterion. In some implementations, the method 200
includes determining the routing criterion by modifying an existing
routing criterion. In some implementations, the method 200 includes
determining the routing criterion by creating a new routing
criterion.
[0029] In some implementations, the set of data packets are
associated with a transmission priority value (e.g., `1` for high
priority, `0` for medium priority and `-1` for low priority). In
such implementations, the method 200 includes determining the
routing criterion for the set of data packets based on the
transmission priority value. For example, in such implementations,
the method 200 includes selecting a first routing criterion (e.g.,
Alg x shown in FIG. 1B) for data packets with a transmission
priority value of `1`, a second routing criterion (e.g., Alg y
shown in FIG. 1B) for data packets with a transmission priority
value of `0`, and a third routing criterion (e.g., Alg z shown in
FIG. 1B) for data packets with a transmission priority value of
`-1`.
[0030] In some implementations, the method 200 includes determining
the routing criterion based on a target metric associated with the
set of data packets. In some implementations, the target metric
includes an Interior Gateway Protocol (IGP) metric. In some
implementations, the network nodes and/or the communication links
are configured to control (e.g., maintain, reduce or increase) the
IGP metric. In some implementations, the target metric relates to
affinity values. For example, in some implementations, the target
metric is to exclude predefined affinity values (e.g., exclude
Traffic Engineering (TE) affinity 2, exclude TE affinity 1, etc.).
In some implementations, the target metric relates to color values.
For example, in some implementations, the target metric specifies
specific color values (e.g., Color 1, Color 2, etc.).
[0031] As represented by block 220, in various implementations, the
method 200 includes identifying network nodes and communication
links in the network that satisfy the routing criterion. As
represented by block 220a, in some implementations, the method 200
includes selecting nodes that support and/or advertise support for
the routing criterion for the set of data packets. In some
implementations, the method 200 includes selecting network nodes
that support the routing criterion regardless of whether the
network nodes advertise support for the routing criterion. In some
implementations, the method 200 includes selecting network nodes
that support the routing criterion and advertise support for the
routing criterion (e.g., the network nodes indicate that they
support the routing criterion).
[0032] As represented by block 220b, in some implementations, the
method 200 includes selecting network nodes and/or communication
links that are not associated with exclusionary constraints
corresponding to the routing criterion. In some implementations,
the routing criterion indicates one or more exclusionary
constraints (e.g., characteristics of network nodes and/or
communication links that are to be avoided). In such
implementations, the method 200 includes forgoing selecting network
nodes and/or communication links with characteristics that are
among the exclusionary constraints.
[0033] As represented by block 230, in some implementations, the
method 200 includes determining a route through the network nodes
and the communication links that satisfy the routing criterion. In
some implementations, the method 200 includes determining the
shortest route through the network nodes and the communication
links that satisfy the routing criterion. In some implementations,
the method 200 includes determining the fastest route through the
network nodes and the communication links that satisfy the routing
criterion.
[0034] In some implementations, the method 200 includes determining
the route based on a target metric associated with the set of data
packets. In various implementations, the network nodes are
associated with respective target metrics. For example, in some
implementations, the network nodes are configured to control (e.g.,
maintain, reduce or increase) their respective target metrics. In
such implementations, the method 200 includes determining the route
by selecting network nodes that are configured to control the
target metric associated with the set of data packets. In some
implementations, the target metric includes one or more of an
Interior Gateway Protocol (IGP) metric, a Traffic Engineering (TE)
metric, etc.
[0035] As represented by block 240, in various implementations, the
method 200 includes configuring the network nodes that are on the
route with configuration information that allows the set of data
packets to propagate along the route. As represented by block 240a,
in some implementations, the method 400 includes installing
forwarding entries at the network nodes that are on the route. In
some implementations, the method 200 includes pushing, by a
controller (e.g., the network controller 20 shown in FIG. 1A) the
forwarding entries to the network nodes that are on the route. In
some implementations, the method 200 includes fetching, by the
network nodes that are on the route, the forwarding entries. As
represented by block 240b, in some implementations, the forwarding
entries identify downstream nodes that satisfy the routing
criterion. For example, in some implementations, the forwarding
entries map SIDs to corresponding network nodes (e.g., Internet
Protocol (IP) addresses of corresponding network nodes).
[0036] FIG. 2B is a flowchart representation of a method 250 of
propagating data packets in accordance with some implementations.
In various implementations, the method 250 is implemented as a set
of computer readable instructions that are executed at a device
(e.g., the network controller 20 shown in FIG. 1A, one or more of
the network nodes N1 . . . N9 shown in FIGS. 1A-1F and/or the
device 300 shown in FIG. 3). Briefly, the method 250 includes
obtaining a request to transmit a set of data packets (260),
applying a label to the set of data packets (270), and propagating
the data packets in accordance with forwarding entries and the
label (280).
[0037] As represented by block 260, in various implementations, the
method 250 includes obtaining a request to transmit the set of data
packets (e.g., the set of data packets 100 shown in FIG. 1E). In
some implementations, the method 250 includes receiving the request
from a client device (e.g., the client device A shown in FIGS.
1A-1F). In some implementations, the method 250 includes receiving
the request at a network node that is at an edge of the network
(e.g., at an edge node, for example, at network node N1 shown in
FIGS. 1A-1F). In some implementations, the method 250 includes
receiving the request at a controller (e.g., the network controller
20 shown in FIG. 1A).
[0038] As represented by block 270, in various implementations, the
method 250 includes applying a label to the set of data packets. As
represented by block 270a, in some implementations, the label
indicates a routing criterion for transmitting the data packets. To
that end, in some implementations, the method 250 includes
determining the routing criterion for transmitting the data
packets. For example, in some implementations, the method 250
includes determining the routing criterion based on the set of data
packets. In some implementations, the method 250 includes selecting
an existing routing criterion, modifying an existing routing
criterion or creating a new routing criterion based on a type of
the set of data packets. In some implementations, the method 250
includes determining the routing criterion based on the request
(e.g., by retrieving the routing criterion from the request). As
represented by block 270b, in some implementations, the method 250
includes applying a MPLS label tithe set of data packets. For
example, in some implementations, the method 250 includes inserting
the label in respective header fields of the data packets.
[0039] As represented by block 280, in various implementations, the
method 250 includes propagating the data packets in accordance with
configuration information of the network nodes and the label. In
some implementations, the method 250 includes forwarding the data
packets in accordance with forwarding entries and the label affixed
to the set of data packets. For example, in some implementations,
the method 250 includes forwarding the data packets to the network
node that is mapped to the label.
[0040] In various implementations, the method 200 and/or the method
250 allow routing of data packets even though the network nodes and
the communication links have different routing capabilities. In
some implementations, the method 200 allows the network nodes and
the communication links to support different routing criteria
thereby providing more flexibility. For example, in some
implementations, the method 200 allows the network nodes and/or the
communication links to support different routing algorithms.
Advantageously, the method 200 enables malleable routing for data
packets by allowing the network nodes and/or the communication
links to change their respective routing capabilities (e.g., by
supporting different routing criteria).
[0041] FIG. 3 is a block diagram of a device 300 enabled with one
or more components of a device (e.g., the network controller 20
shown in FIG. 1A, and/or one or more of the network nodes N1 . . .
N9 shown in FIGS. 1A-1F) in accordance with some implementations.
While certain specific features are illustrated, those of ordinary
skill in the art will appreciate from the present disclosure that
various other features have not been illustrated for the sake of
brevity, and so as not to obscure more pertinent aspects of the
implementations disclosed herein. To that end, as a non-limiting
example, in some implementations the device 300 includes one or
more processing units (CPUs) 302, a network interface 303, a
programming interface 305, a memory 306, and one or more
communication buses 304 for interconnecting these and various other
components.
[0042] In some implementations, the network interface 303 is
provided to, among other uses, establish and maintain a metadata
tunnel between a cloud hosted network management system and at
least one private network including one or more compliant devices.
In some implementations, the communication buses 304 include
circuitry that interconnects and controls communications between
system components. The memory 306 includes high-speed random access
memory, such as DRAM, SRAM, DDR RAM or other random access solid
state memory devices, and may include non-volatile memory, such as
one or more magnetic disk storage devices, optical disk storage
devices, flash memory devices, or other non-volatile solid state
storage devices. The memory 306 optionally includes one or more
storage devices remotely located from the CPU(s) 302. The memory
306 comprises a non-transitory computer readable storage
medium.
[0043] In some implementations, the memory 306 or the
non-transitory computer readable storage medium of the memory 306
stores the following programs, modules and data structures, or a
subset thereof including an optional operating system 308, a
routing criterion determination module 310, a node/link
identification module 320, a route determination module 330, and a
configuration module 340. In various implementations, the routing
criterion determination module 310 determines a routing criterion
that is to be used to transmit a set of data packets across a
network. To that end, the routing criterion determination module
310 includes instructions 310a, and heuristics and metadata 310b.
In various implementations, the node/link identification module 320
identifies network nodes and communication links in the network
that satisfy the routing criterion. To that end, the node/link
identification module 320 includes instructions 320a, and
heuristics and metadata 320b. In various implementations, the route
determination module 330 determines a route for the set of data
packets through the network nodes and the communication links that
satisfy the routing criterion. To that end, the route determination
module 330 includes instructions 330a, and heuristics and metadata
330b. In various implementations, the configuration module 340
configures the network nodes that are on the route with
configuration information that allows the set of data packets to
propagate along the route. To that end, the configuration module
340 includes instructions 340a, and heuristics and metadata
340b.
[0044] In some implementations, the method 200, the method 250
and/or the device 300 enable a routing criterion (e.g., a routing
algorithm, for example, an IGP prefix SID algorithm) to be defined
on a per-deployment basis. For example, in some implementations, a
flexible algorithm K is defined as controlling (e.g., reducing, for
example, minimizing) a particular target metric (e.g., an IGP
metric, a TE metric, or other network performance metrics such as
latency). In some implementations, the flexible algorithm K further
defines a set of one or more restrictions (e.g., exclusionary
constraints or excluded resources). In some implementations, the
set of restrictions are identified by their Shared Risk Link Groups
(SRLG), TE affinity and/or Internet Protocol (IP) address.
[0045] In various implementations, the method 200, the method 250
and/or the device 300 allow different operators to define different
routing criterion (e.g., different routing algorithms). For
example, in some implementations, an operator K that controls one
or more network nodes defines a first routing criterion as
controlling an IGP metric (e.g., reducing the IGP metric, for
example, minimizing the IGP metric) and avoiding a particular SRLG
(e.g., avoiding SRLG1). In some implementations, an operator J that
controls one or more network nodes defines a second routing
criterion as controlling a TE metric (e.g., reducing the TE metric,
for example, minimizing the TE metric) and avoiding TE affinity
1.
[0046] In various implementations, the method 200, the method 250
and/or the device 300 enable support for different routing
criteria. For example, in some implementations, the method 200, the
method 250 and/or the device 300 enable support for a routing
criterion (e.g., ALG 11) that controls an IGP metric (e.g., reduces
the IGP metric, for example, minimizes the IGP metric) and excludes
TE affinity 2. In some implementations, the method 200, the method
250 and/or the device 300 enable support for another routing
criterion (e.g., ALG 12) that controls the IGP metric and excludes
TE affinity 1. In some implementations, a set of Table, Length and
Value (TLVs) are utilized to encode the defining characteristics of
a routing criterion. In various implementations, the method 200,
the method 250 and/or the device 300 allow network-wide automation
of the assignment/modification of the routing criteria.
[0047] In various implementations, the method 200, the method 250
and/or the device 300 allow network nodes to indicate (e.g.,
advertise, for example, broadcast) the definition of their
respective routing criterion. For example, in some implementations,
the device 300 advertises the example routing criteria ALG11 and
ALG 12 as: [0048] ALG11=control (e.g., reduce, for example,
minimize) IGP metric, exclude TE affinity 2, Color 1 [0049]
ALG12=control (e.g., reduce, for example, minimize) IGP metric,
exclude TE affinity 1, Color 2
[0050] In some implementations, the device 300 (e.g., the node/link
identification module 320 and/or the route determination module
330) detects inconsistencies between network nodes that support the
same routing criterion.
[0051] In some implementations, the router capability (RC) of
network nodes indicates the definition of the routing criteria
supported by the network nodes. For example, in some
implementations, the router capability of network nodes M and N
indicates that the network nodes M and N support ALG11: [0052] RC
of network node M indicates ALG 11=control IGP metric, exclude TE
affinity 2 [0053] RC of network node N indicates ALG 11=control IGP
metric, exclude TE affinity 2
[0054] Since network nodes M and N indicate the same definition for
ALG 11, the device 300 (e.g., the node/link identification module
320 and/or the route determination module 330) determines that the
definition of the routing criterion supported by the network nodes
M and N is consistent. In some implementations, the network nodes
utilize a new RC TLV to indicate the definition of the routing
criterion that the network nodes support.
[0055] In various implementations, the device 300 determines
whether a network node N is enabled for (e.g., supports) a
particular routing criterion (e.g., ALG(K)). If the device 300
determines that the network node N does not support ALG(K), the
device 300 does not include the network node N in the route. For
example, in some implementations, the network node N does not
compute ALG(K) Dijkstra and does not install ALG(K) prefix SID. If
the device 300 determines that the network node N supports ALG(K),
the device 300 prunes all the nodes that do not support ALG(K),
prunes all the communication links falling under the exclude
constraints defined for ALG(K), computes Dijkstra on the resulting
topology according to the target metric associated with ALG(K), and
installs the prefix SID according to the computed Dijkstra shortest
route for any prefix leaf with an ALG(K) prefix SID.
[0056] In various implementations, the device 300 determines a
backup route (e.g., a secondary route, for example, a Fast Reroute
(FRR) backup route). In some implementations, the backup route is
associated with (e.g., respects) the same characteristics (e.g.,
constraints) as the route (e.g., the primary route). For example,
in some implementations, the backup route is determined based on
the same routing criterion as the primary route. In some
implementations, to determine (e.g., compute) the backup route for
the Prefix SID S of ALG(K), the device 300 executes a
Topology-Independent Loop-Free Alternate (TI-LFA) algorithm on the
topology T'(K), where T'(K) is T(K) minus the resource protected
with TILFA (e.g., link, node, SRLG). In some implementations, the
post-convergence backup route is encoded with SIDs associated with
ALG(K).
[0057] In some implementations, the device 300 provides automated
steering of service traffic on the IGP prefix SID with the routing
criterion implementing the service level agreement (SLA) associated
with (e.g., required by) the service route. In some
implementations, when a provider edge (PE) receives a Border
Gateway Protocol (BGP)/Service route R via N with Color Extended
Community C, the PE installs R via S, where S is the Prefix SID of
N for Alg(K) mapped to C. In such implementations, there is
automated steering of BGP/Service routes onto prefix SIDs
associated with the routing criterion. The following is a
non-limiting example of automated steering of BGP/Service routes:
[0058] PE receives BGP route 1/8 via 2.2.2.2 with color 1 [0059]
2.2.2.2 is advertised in IGP with Prefix SID 17002 for a particular
routing criterion(e.g., ALG 11) [0060] ALG 11 is defined by Mapping
Server as "IGP metric, exclude TE-affinity 2, color 1"
[0061] In the above example, PE installs 1/8 via 17002 because
17002 is the Prefix SID of 2.2.2.2 according to ALG 11. In the
above example, ALG 11 is bound to color 1.
[0062] In some implementations, a single SID is utilized to encode
the shortest route instead of N SIDs. In some implementations, the
device 300 encodes the shortest-route as a list of N SIDs of
algorithm zero. In some implementations, the SID list size is the
primary data plane constraint for a segment route (SR)
deployment.
[0063] In some implementations, the device 300 enables flexible and
customized configuration of the network nodes and/or the
communication links. In some implementations, the device 300
supports dual-plane policies. In some implementations, the device
300 encodes planes differently (e.g., any TE affinity value can be
used, and/or any SRLG value can be used). In various
implementations, the device 300 enables network operators, network
nodes and/or communication links to define their own routing
criterion.
[0064] In some implementations, the device 300 enables network-wide
automation of adopting/modifying routing criteria. In some
implementations, a mapping server extension is defined to
distribute the definition of routing criteria (e.g., an IGP
algorithm) across all the network nodes of the domain/area. In some
implementations, the device 300 detects inconsistent definitions of
a routing criterion. In some implementations, a router capability
extension is defined to indicate (e.g., advertise) the definition
of a routing criterion for the network nodes. In some
implementations, if network nodes supporting the same routing
criterion do not indicate the same definition for the routing
criterion, the device 300 detects an inconsistency. In some
implementations, the device 300 enables automated steering of
service flows onto the prefix SID associated with the routing
criterion. In some implementations, the device 300 determines a
backup route that is associated with (e.g., follows or respects)
the same constraints as the primary route.
[0065] While various aspects of implementations within the scope of
the appended claims are described above, it should be apparent that
the various features of implementations described above may be
embodied in a wide variety of forms and that any specific structure
and/or function described above is merely illustrative. Based on
the present disclosure one skilled in the art should appreciate
that an aspect described herein may be implemented independently of
any other aspects and that two or more of these aspects may be
combined in various ways. For example, an apparatus may be
implemented and/or a method may be practiced using any number of
the aspects set forth herein. In addition, such an apparatus may be
implemented and/or such a method may be practiced using other
structure and/or functionality in addition to or other than one or
more of the aspects set forth herein.
[0066] It will also be understood that, although the terms "first,"
"second," etc. may be used herein to describe various elements,
these elements should not be limited by these terms. These terms
are only used to distinguish one element from another. For example,
a first contact could be termed a second contact, and, similarly, a
second contact could be termed a first contact, which changing the
meaning of the description, so long as all occurrences of the
"first contact" are renamed consistently and all occurrences of the
second contact are renamed consistently. The first contact and the
second contact are both contacts, but they are not the same
contact.
[0067] The terminology used herein is for the purpose of describing
particular embodiments only and is not intended to be limiting of
the claims. As used in the description of the embodiments and the
appended claims, the singular forms "a", "an" and "the" are
intended to include the plural forms as well, unless the context
clearly indicates otherwise. It will also be understood that the
term "and/or" as used herein refers to and encompasses any and all
possible combinations of one or more of the associated listed
items. It will be further understood that the terms "comprises"
and/or "comprising," when used in this specification, specify the
presence of stated features, integers, steps, operations, elements,
and/or components, but do not preclude the presence or addition of
one or more other features, integers, steps, operations, elements,
components, and/or groups thereof.
[0068] As used herein, the term "if" may be construed to mean
"when" or "upon" or "in response to determining" or "in accordance
with a determination" or "in response to detecting," that a stated
condition precedent is true, depending on the context. Similarly,
the phrase "if it is determined [that a stated condition precedent
is true]" or "if [a stated condition precedent is true]" or "when
[a stated condition precedent is true]" may be construed to mean
"upon determining" or "in response to determining" or "in
accordance with a determination" or "upon detecting" or "in
response to detecting" that the stated condition precedent is true,
depending on the context.
* * * * *