U.S. patent application number 14/870649 was filed with the patent office on 2017-03-30 for method and apparatus for supporting service function chaining in a communication network.
This patent application is currently assigned to HUAWEI TECHNOLOGIES CO., LTD.. The applicant listed for this patent is Hamidreza FARMANBAR. Invention is credited to Hamidreza FARMANBAR.
Application Number | 20170093698 14/870649 |
Document ID | / |
Family ID | 58407007 |
Filed Date | 2017-03-30 |
United States Patent
Application |
20170093698 |
Kind Code |
A1 |
FARMANBAR; Hamidreza |
March 30, 2017 |
METHOD AND APPARATUS FOR SUPPORTING SERVICE FUNCTION CHAINING IN A
COMMUNICATION NETWORK
Abstract
A method and apparatus supporting service function chaining in a
communication network is provided. Service function chaining
requires packets of a service to pass through a defined sequence of
service nodes of the network. Traffic engineering support includes
defining service segments, determining demands for each service
segment, determining flow group conservation constraints using the
determined demands, and determining a resource allocation for data
links which respects the flow group conservation constraints along
with a link capacity constraint. A service-based forwarding
operation re-labels packets as they traverse each service segment,
and forwards packets toward a destination service node of each
service segment.
Inventors: |
FARMANBAR; Hamidreza;
(Ottawa, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
FARMANBAR; Hamidreza |
Ottawa |
|
CA |
|
|
Assignee: |
HUAWEI TECHNOLOGIES CO.,
LTD.
Shenzhen
CN
|
Family ID: |
58407007 |
Appl. No.: |
14/870649 |
Filed: |
September 30, 2015 |
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04L 47/29 20130101;
H04L 45/38 20130101; H04L 45/306 20130101; H04L 45/74 20130101;
H04L 47/822 20130101 |
International
Class: |
H04L 12/721 20060101
H04L012/721; H04L 12/911 20060101 H04L012/911 |
Claims
1. A method for supporting service-based packet communication in a
multi-hop data network, comprising: receiving an indication of a
set of services, each service of the set of services corresponding
to a respective node group comprising: one or more source nodes
providing packets belonging to the service; a destination node
receiving the packets belonging to the service; and a set of
service nodes through which the packets belonging to the service
are required to pass, each service utilizing a respective set of
service links connecting predetermined pairs of members of the
respective node group; for each service node and each destination
node belonging to at least one node group, determining a respective
service segment corresponding to members of the sets of service
links which connect to said service node or destination node and
which are indicative of data flow into said service node or
destination node fix at least one of the set of services; for each
service segment, and for each node in the node groups, determining
a demand indicative of combined demand of source nodes belonging to
services, of the set of services, for which service packets pass
through said service segment; for each service segment, and for
each of a plurality of nodes of the data network, including nodes
of the node groups, determining a flow group conservation
constraint indicative that an amount of resource allocation for
data links incoming to the node and for the service segment; is
less than an amount of resource allocation for data links outgoing
from the node and for the service segment by a first margin equal
to the determined demand indicative of combined demand for the
node, when the node is a source node or a service node providing
service packets to the service segment; is greater than the amount
of resource allocation for data links outgoing from the node and
for the service segment by a second margin equal to a sum of
determined demands indicative of combined demands, the sum being
over source node is a service node or a destination node receiving
service packets from the service segment; and is similar to the
amount of resource allocation for data links outgoing from the node
and for the service segment otherwise; for each of a plurality of
data links operatively coupling nodes of the data network, the data
links including the service links, determining a respective link
capacity constraint; determining a resource allocation respecting
the flow group conservation constraints and the link capacity
constraints; and controlling operation of the data network in
accordance with the determined resource allocation.
2. The method of claim 1, wherein controlled operation of the data
network comprises packet routing, and wherein routing a packet
comprises: prior to transmission of the packet from a first service
node onto a data link corresponding to a first service segment,
labeling the packet with an indication of the first service
segment; forwarding the packet toward a second service node based
on the indication of the first service segment; and upon receipt of
the packet at the second service node, re-labeling the packet with
an indication of a second service segment to be subsequently
traversed by the packet.
3. The method of claim 2, wherein forwarding the packet toward the
second service node comprises receiving and forwarding the packet
by one or more intermediate data network nodes.
4. The method of claim 2, further comprising forwarding the packet
toward a third service node or a destination node based on the
indication of the second service segment.
5. The method of claim 2, wherein, during re-labeling of the
packet, the indication of the second service segment is determined
based on the indication of the first service segment or based on a
service identifier carried by the packet.
6. The method of claim 1, wherein the resource allocation is
determined so as to satisfy a predetermined network objective
directed to one or more of: load balancing; sum rate maximization;
and weighted sum rate maximization.
7. The method of claim 6, wherein the resource allocation is
determined so as to maximize an objective function corresponding to
the predetermined network objective.
8. The method of claim 1, wherein the resource allocation
specifies, for a link of the plurality of data links, a proportion
of data resources of the link which are to be used in support of a
specified one of the set of services traversing the link.
9. The method of claim 1, further comprising creating a graph data
structure encoding services of the set of services, and wherein
determination of the respective service segment is based on
computation performed on the graph data structure.
10. The method of claim 1, wherein at least one service link of the
set of service links comprises one or more intermediate routers,
one or more data path branches, or a combination thereof.
11. The method of claim 1, wherein controlling operation of the
data network comprises providing packet handling instructions to
one or more nodes of the network, said one or more nodes including
the service nodes.
12. A traffic engineering controller for a multi-hop data network,
comprising: an input network interface configured to receive an
indication of a set of services, each service of the set of
services corresponding to a respective node group comprising: one
or more source nodes providing packets belonging to the service; a
destination node receiving the packets belonging to the service;
and a set of service nodes through which the packets belonging to
the service are required to pass, each service utilizing a
respective set of service links connecting predetermined pairs of
members of the respective node group; a processor configured to:
for each service node and each destination node belonging to at
least one node group, determine a respective service segment
corresponding to members of the sets of service links winch connect
to said service node or destination node and which are indicative
of data flow into said service node or destination node for at
least one of the set of services; for each service segment, and for
each node the node groups, determine a demand indicative of
combined demand of source nodes belonging to services, of the set
of services, for which service packets pass through said service
segment; for each service segment, and for each of a plurality of
nodes of the data network, including nodes of the node groups,
determine a flow group conservation constraint indicative that an
amount of resource allocation for data links incoming to the node
and for the service segment: is less than an amount of resource
allocation for data links outgoing from the node and for the
service segment by a first margin equal to the determined demand
indicative of combined demand for the node, when the node is a
source node or a service node providing service packets to the
service segment; is greater than the amount of resource allocation
for data links outgoing from the node and for the service segment
by a second margin equal to a sum of determined demands indicative
of combined demands, the sum being over source nodes or service
nodes providing service packets to the service segment, when the
node is a service node or a destination node receiving service
packets from the service segment; and is similar to the amount of
resource allocation for data links outgoing from the node and for
the service segment otherwise; for each of a plurality of data
links operatively coupling nodes of the data network, the data
links including the service links, determine a respective link
capacity constraint; and determine a resource allocation respecting
the flow group conservation constraints and the link capacity
constraints; and an output network interface configured to transmit
signals for controlling operation of the data network in accordance
with the determined resource allocation.
13. The traffic engineering controller of claim 12, wherein the
processor is configured to determine the resource allocation so as
to satisfy a predetermined network objective directed to one or
more of: load balancing; sum rate maximization; and weighted sum
rate maximization.
14. The traffic engineering controller of claim 13, wherein the
processor is configured to determine the resource allocation so as
to maximize an objective function corresponding to the
predetermined network objective.
15. The traffic engineering controller of claim 12, wherein the
resource allocation specifies, for a link of the plurality of data
links, a proportion of data resources of the link which are to be
used in support of a specified one of the set of services
traversing the link.
16. The traffic engineering controller of claim 12, wherein the
processor is further configured to create a graph data structure
encoding services of the set of services, and wherein determination
of the respective service segment is based on computation performed
on the graph data structure.
17. The traffic engineering controller of claim 12, wherein at
least one service link of the set of service links comprises one or
more intermediate routers, one or more data path branches, or a
combination thereof.
18. The traffic engineering controller of claim 12, wherein
controlling operation of the data network comprises providing
packet handling instructions to one or more nodes of the network,
said one or more nodes including the service nodes.
19. A router for routing a packet in a multi-hop data network, the
packet belonging to a service, the service corresponding to a set
of service nodes through which the packet is required to pass, the
router communicatively coupled to one of the set of service nodes
and comprising a data packet handling interface configured to:
receive the packet and process a label, carried by the packet,
comprising an indication of a first service segment traversed by
the data packet; adjust the label to include an indication of a
second service segment to be traversed by the packet upon
transmission of the packet from the router; and transmit the packet
toward a further service node of the set of service nodes based on
the indication of the second service segment.
20. The router of claim 19, wherein transmitting the packet toward
the further service node comprises transmitting the packet to an
intermediate router located between the router and the further
service node.
21. The router of claim 19, further configured to determine the
indication of the further service segment based on the indication
of the first service segment or based on a service identifier
carried by the packet.
22. The router of claim 19, further comprising an input network
interface configured to receive the indication of the second
service segment from a traffic engineering controller for inclusion
in the label.
23. The router of claim 19, further configured to determine the
indication of the second service segment based on the indication of
the first service segment, according to service-based label
switching information received from a traffic engineering
controller via an input network interface of the router.
24. The router of claim 19, further comprising an input network
interface configured to receive service-based forwarding
information from a traffic engineering controller, wherein
transmitting the packet is based on the service-based forwarding
information.
25. The router of claim 19, wherein the packet is routed according
to destination-based routing based on the label.
26. A method for supporting service-based packet communication in a
multi-hop data network, comprising: providing an indication of a
plurality of service segments, each service segment corresponding
to a set of service links via which data flows into a service node
or destination node, said data corresponding to a service requiring
the data to pass through a specified sequence of service nodes;
determining a plurality of demand values corresponding respectively
to the plurality of service segments, each demand value indicative
of a combined demand of source nodes belonging to services for
which service packets pass through the respective service segment;
and performing a traffic engineering optimization calculation with
all service segments present and in consideration of the determined
plurality of demand values.
Description
FIELD OF THE INVENTION
[0001] The present invention pertains to the field of data
communications and in particular to a method and apparatus for
supporting service function chaining in a communication
network.
BACKGROUND
[0002] Service function chaining is a technique in which a data
traffic flow is steered through an ordered series of service
functions. Typically, each service function is located at a logical
location in the network topology. Each service function may be
responsible for specific treatment of received packets. As such,
the service function chain allows for packets in a packet flow to
undergo a sequence of packet treatments.
[0003] However, accommodating service function chaining imposes
additional requirements and constraints on network management
operations. For example, traffic engineering, flow control, routing
and packet forwarding computations may require adjustment so that
defined service function chains are respected while data flows are
optimized. The distributed nature of service function chains across
multiple nodes makes this a non-trivial issue.
[0004] Therefore there is a need for a method and apparatus for
supporting service function chaining in a communication network
that obviates or mitigates one or more limitations of the prior
art.
[0005] This background information is provided to reveal
information believed by the applicant to be of possible relevance
to the present invention. No admission is necessarily intended, nor
should be construed, that any of the preceding information
constitutes prior art against the present invention.
SUMMARY
[0006] An object of embodiments of the present invention is to
provide a method and apparatus for supporting service function
chaining in a communication network. In accordance with embodiments
of the present invention, there is provided a method for supporting
service-based packet communication in a multi-hop data network,
comprising: receiving an indication of a set of services, each
service of the set of services corresponding to a respective node
group comprising: one or more source nodes providing packets
belonging to the service; a destination node receiving the packets
belonging to the service; and a set of service nodes through which
the packets belonging to the service are required to pass, each
service utilizing a respective set of service links connecting
predetermined pairs of members of the respective node group; for
each service node and each destination node belonging to at least
one node group, determining a respective service segment
corresponding to members of the sets of service links which connect
to said service node or destination node and which are indicative
of data flow into said service node or destination node for at
least one of the set of services; for each service segment, and for
each node in the node groups, determining a demand indicative of
combined demand of source nodes belonging to services, of the set
of services, for which service packets pass through said service
segment; for each service segment, and for each of a plurality of
nodes of the data network, including nodes of the node groups,
determining a flow group conservation constraint indicative that an
amount of resource allocation for data links incoming to the node
and for the service segment: is less than an amount of resource
allocation for data links outgoing from the node and for the
service segment by a first margin equal to the determined demand
indicative of combined demand for the node, when the node is a
source node or a service node providing service packets to the
service segment; is greater than the amount of resource allocation
for data links outgoing from the node and for the service segment
by a second margin equal to a sum of determined demands indicative
of combined demands, the sum being over source nodes or service
nodes providing service packets to the service segment, when the
node is a service node or a destination node receiving service
packets from the service segment; and is similar to the amount of
resource allocation for data links outgoing from the node and for
the service segment otherwise; for each of a plurality of data
links operatively coupling nodes of the data network, the data
links including the service links, determining a respective link
capacity constraint; determining a resource allocation respecting
the flow group conservation constraints and the link capacity
constraints; and controlling operation of the data network in
accordance with the determined resource allocation.
[0007] In accordance with embodiments of the present invention,
there is provided a traffic engineering controller for a multi-hop
data network, comprising: an input network interface configured to
receive an indication of a set of services, each service of the set
of services corresponding to a respective node group comprising:
one or more source nodes providing packets belonging to the
service; a destination node receiving the packets belonging to the
service; and a set of service nodes through which the packets
belonging to the service are required to pass, each service
utilizing a respective set of service links pairwise connecting
predetermined pairs of members of the respective node group; a
processor configured to: for each service node and each destination
node belonging to at least one node group, determine a respective
service segment corresponding to members of the sets of service
links which connect to said service node or destination node and
which are indicative of data flow into said service node or
destination node for at least one of the set of services; for each
service segment, and for each node the node groups, determine a
demand indicative of combined demand of source nodes belonging to
services, of the set of services, for which service packets pass
through said service segment; for each service segment, and for
each of a plurality of nodes of the data network, including nodes
of the node groups, determine a flow group conservation constraint
indicative that an amount of resource allocation for data links
incoming to the node and for the service segment: is less than an
amount of resource allocation for data links outgoing from the node
and for the service segment by a first margin equal to the
determined demand indicative of combined demand for the node, when
the node is a source node or a service node providing service
packets to the service segment; is greater than the amount of
resource allocation for data links outgoing from the node and for
the service segment by a second margin equal to a sum of determined
demands indicative of combined demands, the sum being over source
nodes or service nodes providing service packets to the service
segment, when the node is a service node or a destination node
receiving service packets from the service segment; and is similar
to the amount of resource allocation for data links outgoing from
the node and for the service segment otherwise; for each of a
plurality of data links operatively coupling nodes of the data
network, the data links including the service links, determine a
respective link capacity constraint; and determine a resource
allocation respecting the flow group conservation constraints and
the link capacity constraints; and an output network interface
configured to transmit signals for controlling operation of the
data network in accordance with the determined resource
allocation.
[0008] In accordance with embodiments of the present invention,
there is provided a router for routing a packet in a multi-hop data
network., the packet belonging to a service, the service
corresponding to a set of service nodes through which the packet is
required to pass, the router communicatively coupled to one of the
set of service nodes and comprising a data packet handling
interface configured to: receive the packet and process a label,
carried by the packet, comprising an indication of a first service
segment traversed by the data packet; adjust the label to include
an indication of a second service segment to be traversed by the
packet upon transmission of the packet from the router; and
transmit the packet toward a further service node of the set of
service nodes based on the indication of the second service
segment.
[0009] In accordance with embodiments of the present invention,
there is provided a method for supporting service-based packet
communication in a multi-hop data network, comprising: providing an
indication of a plurality of service segments, each service segment
corresponding to a set of service links via which data flows into a
service node or destination node, said data corresponding to a
service requiring the data to pass through a specified sequence of
service nodes; determining a plurality of demand values
corresponding respectively to the plurality of service segments,
each demand value indicative of a combined demand of source nodes
belonging to services for which service packets pass through the
respective service segment; and performing a traffic engineering
optimization calculation with all service segments present and in
consideration of the determined plurality of demand values.
[0010] In accordance with embodiments of the present invention,
there is provided a plurality of routers for routing a packet in a
multi-hop data network, the packet belonging to a service, the
service corresponding to a set of service nodes through the packet
is required to pass, the plurality of routers collectively
configured to: label the packet with an indication of a first
service segment prior to transmission of the packet from a first
service node of the set of service nodes onto a data link
corresponding to the first service segment; forward the packet
toward a second service node of the set of service nodes based on
the indication of the first service segment; and upon receipt of
the packet at the second service node, re-label the packet with an
indication of a second service segment to be subsequently traversed
by the packet.
BRIEF DESCRIPTION OF THE FIGURES
[0011] Further features and advantages of the present invention
will become apparent from the following detailed description, taken
in combination with the appended drawings, in which:
[0012] FIG. 1 illustrates a method for service-based traffic
engineering, in accordance with embodiments of the present
invention.
[0013] FIG. 2 illustrates a method for service-based packet
forwarding, in accordance with embodiments of the present
invention.
[0014] FIG. 3 illustrates an example network configuration in
accordance with an embodiment of the present invention.
[0015] FIG. 4 illustrates an example graph data structure in
accordance with an embodiment of the present invention.
[0016] FIG. 5 illustrates an example network configuration in
accordance with another embodiment of the present invention.
[0017] FIG. 6 illustrates a traffic engineering controller in
accordance with embodiments of the present invention.
[0018] FIG. 7 illustrates a traffic engineering controller
operatively coupled to a service-based forwarding function, in
accordance with an embodiment of the present invention.
[0019] FIG. 8 illustrates a router configured to implement
service-based forwarding, in accordance with embodiments of the
present invention.
[0020] FIGS. 9A to 9C illustrate a sequence of operations being
performed in accordance with embodiments of the present
invention.
[0021] It will be noted that throughout the appended drawings, like
features are identified by like reference numerals.
DETAILED DESCRIPTION
[0022] Embodiments of the present invention are directed toward the
support of service function chaining, in a network using traffic
engineering, traffic forwarding, or both. Embodiments of the
present invention may be used to steer service traffic flows from
their source nodes to their destination nodes, through a
predetermined sequence of intermediate service nodes, and in a
manner that achieves predetermined network objectives. Network
objectives may include load balancing, sum rate maximization, and
weighted sum rate maximization, for example. As such, embodiments
of the present invention relate to traffic engineering under the
additional constraint that packets of packet flows associated with
given services are required to pass through specified sequences of
service nodes. In some embodiments, a packet forwarding mechanism
for implementation in the data plane may also be provided. In the
packet forwarding mechanism, packets are labelled with destination
information designating the next service node in the service
function chain to be visited. As each service node is reached, the
packets can be re-labeled.
[0023] Service-based traffic engineering in embodiments of the
invention may involve three steps. In the first step, service
segments are introduced. In the second step, demand values of the
service segments may be determined. In the third step, a traffic
engineering optimization calculation, for example comparable to a
destination-based traffic engineering calculation is performed with
all service segments present and in consideration of the determined
demand values. Traffic engineering may thus be performed based on
services rather than on flows. The details of these steps will be
described below.
[0024] Having reference to FIG. 1, embodiments of the present
invention provide for a method for supporting service-based packet
communication in a multi-hop data network. The method includes
receiving 110 an indication of a set of services to be supported by
the data network. Each service corresponds to a respective node
group as well as a respective set of service links. Each node group
includes one or more source nodes which provide data packets in
accordance with and belonging to the service. Each node group
further includes a destination node which receives the packets
belonging to the service. Each node group further includes a set of
service nodes through which the packets belonging to the service
are required to pass. The set of service nodes corresponds to a
Service Function Chain (SFC). In some embodiments, the destination
node can be set equal to the last service node in the SFC. The
service links connect certain pairs of members of the corresponding
node group and may indicate directional data flow between those
members. For example, each service link may be a logical link from
one member of the node group to another. Service links may pass
through intermediate nodes (such as routers) and data links;
however these intermediate nodes may be abstracted from the
definition of the service link. Service links may indicate the
direction of data flow from flow source nodes of a service, through
intermediate service nodes to the destination node.
[0025] In more detail, and in various embodiments, a service may be
defined as a group of flows that are required to pass through a
certain sequence of service functions. A flow is identified by its
source and destination nodes. A flow within a service passes
through a predetermined sequence of associated service functions
before reaching its destination node. Service functions may be
specific to the associated service. Some service functions may be
more generic and applicable to more than one service. The service
functions can he instantiated at certain network nodes, and flows
can pass through their corresponding predetermined service function
nodes. In various embodiments, a service corresponds to a set of
source nodes, which can be source nodes of the flows within the
service, and a sequence of service function nodes including the
destination node.
[0026] The method further includes determining 120 a service
segment for each service node and destination node belonging to at
least one of the node groups. In some embodiments, each service
segment corresponds to those members of all sets of service links
(i.e. members of the union of an sets of service links) which
connect to a given common service node or destination node, and
which are indicative of data flow into that service node or
destination node, for at least one of the set of services. In other
words, at least one service segment may be defined on the basis of
each service node or destination node, the service segment
including the service links which are incoming to that service node
or destination node as well as the source nodes and/or service
nodes which are directly coupled to these service links.
[0027] In some embodiments, the service segments can be defined
differently yet similarly to the above. In particular, when
service-based forwarding based on service segment identifiers (in a
manner to be described below) is implemented, service segments as
defined above may be subdivided into multiple service segments
(also referred to as sub-segments). The subdivision is performed in
a manner that allows services nodes to determine with service a
packet belongs to based solely on a service segment identifier
carried by the packet.
[0028] Each service node and each destination node may potentially
receive data in association with multiple services, and a service
segment may include incoming service links for all of these
multiple services. While a service segment is described above as
corresponding to a set of service links, this correspondence can be
formulated in a variety of alternative ways. For example, rather
than specifying the associated service links, a service segment can
be described by specifying the nodes (belonging to at least one
node group) which act as endpoints for those associated service
links. In some embodiments, service segments can be determined
through creation and processing of a graph data structure which
represents the set of services.
[0029] The method further includes, for each node of the data
network and for each service segment, determining 125 a flow group
conservation constraint. The nodes of the data network include but
are not limited to the nodes of the various node groups described
above. For example, the nodes may include intermediate nodes, such
as routers, which lie or potentially lie along a service link. The
flow group conservation constraints specify how data is introduced
at sources, flows through intermediate nodes, and reaches intended
destinations. The "flow group" to which the flow group conservation
constraint can pertain to a flow segment group or a service
segment, as described elsewhere herein.
[0030] A flow or service can be subdivided into a series of flow
segments. For example, where the flow or service begins at source
node A, passes sequentially through service nodes S.sub.i (for i=1,
2, . . . n) and terminates at destination node Q, then the flow
segments correspond to (A, S.sub.1), (S.sub.i, S.sub.i+1) for i=1,
2, . . . n and (S.sub.n, Q).
[0031] The method further includes, for a set of data links of the
network, including physical links which support logical service
links, determining 130 a set of associated link capacity
constraints, which provide limits on the amount of bandwidth to be
supported by the various data links in the set. The limits may
based on the physically available bandwidth of the data links, or
based on a nominal portion of the bandwidth allocated for handling
by the traffic engineering method or apparatus as described
herein.
[0032] The method further includes determining 135 a resource
allocation respecting the flow group conservation constraints and
the link capacity constraints. The resource allocation may also
maximize a given objective function, and hence may be the solution
to a constrained optimization problem. In some embodiments, the
method further includes defining an objective function to be
maximized, prior to determining the resource allocation. The
objective function may be predetermined or given by an external
network management entity, for example, and may reflect one or more
network objectives to be achieved. The objective function may be
static or dynamic.
[0033] The resource allocation may specify, for a given link, a
proportion of data resources of the link which are to be used in
support of a service traversing the link. The resource allocation
may relate to an assigned data rate, bandwidth reservation, or the
like, for each data link. For example, a resource allocation may
specify a nominal maximum, minimum and/or average data rate for a
given service on a given service link. The method further includes
controlling 140 operation of the data network in accordance with
the determined resource allocation, for example including routing
and/or forwarding packets according to the allocation. Controlling
operation of the data network may include providing instructions to
various routers, source nodes, service nodes, and other
infrastructure components, the instructions directing one or more
operations of these components.
[0034] According to some embodiments, routing packets includes
forwarding packets between network nodes using a combination of
destination-based forwarding and packet re-labeling. As illustrated
in FIG. 2, a particular method of routing packets includes, prior
to transmission of the packet from a source node onto a data link
corresponding to a first service segment, labeling 210 the packet
with an indication of the first service segment. The method further
comprises routing 215 the packet based on the indication of the
first service segment. The routing is configured to forward the
packet toward a second service node, using destination-based
routing which identifies the second service node as the packet
destination based on the indication of the first service segment
carried by the packet. The routing may include receiving the packet
at intermediate non-service nodes (i.e. network nodes other than
and situated between service nodes) and forwarding the packet
onward toward the second service node. These non-service nodes do
not adjust the service segment label in the illustrated embodiment.
The method further includes, upon receipt of the packet at the
second service node, re-labeling 220 the packet with an indication
of a second service segment to be subsequently traversed by the
packet. Re-labeling is performed at service nodes, but typically
not performed at nodes other than service nodes. Packet labeling
may include configuring a field in the packet header, for example.
Multiple instances of packet re-labeling may occur at successive
service nodes. Routing of packets carrying a service segment
identifier includes determining a service node or destination node,
associated with the service segment and toward which the packets
are to be forwarded, and forwarding the packets accordingly.
[0035] According to embodiments of the present invention, services
to be supported may be specified in advance, for example by various
network elements such as servers and client devices, and an
indication of a set of services to be supported can be received and
processed. Each service of the set of services is defined in part
by a Service Function Chain (SFC), which describes the set of
service nodes through which packets belonging to the service are
required to pass. The service nodes are distributed through the
communication network, typically interspersed with other devices
such as routers, which may correspond to non-service nodes. The
service nodes may further implement a routing function as well as a
service function which forms part of the SFC. Source nodes and
destination nodes may also form part of a service definition, as
well as a set of service links connecting the various nodes and
specifying the flow of data from the source nodes to the
destination nodes. The set of service links may be implicitly
defined by the ordering of the service nodes.
[0036] In the present disclosure, a SFC can be defined using arrow
notation, such as X.fwdarw.Y.fwdarw.Z, specifying that packets are
required to pass in order through nodes X, Y and Z.
[0037] In various embodiments, the communication network can be
characterized as a graph G(N,A) having a set of nodes N and a set
of edges A. A set of service nodes N.sub.S, which is a subset of
all nodes N of graph G, can be defined. The set of service nodes
N.sub.S corresponds to all those nodes which are specified as
service nodes in SFCs of the services to be supported. Sets of
source nodes and destination nodes can similarly be defined as a
function of all services being supported.
[0038] The term "service" refers to a group of flows which are to
pass through a common sequence of service nodes. A flow may be
identified by a pair of nodes corresponding to a data source and a
data destination, respectively, in accordance with conventions such
as used in the Multi-Commodity Flow (MCF) flow problem, as would be
readily understood by a person skilled in the art. A flow group may
correspond, for example, to a set of flows with a common
destination. The sequence of service nodes corresponds to the
Service Function Chain for that service. In various embodiments,
the service may also be restricted to a group of flows having
common characteristics, such as Quality of Service (QoS)
requirements. In various embodiments, a service may be identified
by a set of source nodes and an ordered sequence of service nodes.
The sequence of service nodes corresponds to the SFC.
[0039] In embodiments, services can be defined, and flows can be
aggregated, in various ways. In some cases, a service or flow group
can consist of a single flow. In some cases, the number of flows in
a service or flow group can be selectable and/or variable.
Different services or flow groups may include different numbers of
flows. In some embodiments, flows may be allocated to a service
based at least partially on traffic engineering considerations.
[0040] A service can be defined as a pair (A, X.fwdarw.Y.fwdarw.Z),
where A is the set of source nodes of the service and
X.fwdarw.Y.fwdarw.Z is the SFC for the service. Where the set A is
known and there is no risk of confusion, it may be omitted horn the
definition.
[0041] Examples of services include services related to Machine
Type Communication (MTC) and Mobile Broadband (MBB). A flow within
an MTC service may pass through a serving gateway node in order for
certain service functions to be applied on packets at a first
service node. The flow may then pass through a packet gateway,
considered as second service node.
[0042] FIG. 3 illustrates an example network having two services,
according to an embodiment of the present invention. The network
includes a set of source nodes 310, first, second and third service
nodes 320, 322, 324, and a Packet Gateway (PGW) service node 330.
The first service, S.sub.1, forwards packets from source nodes in a
first subset 312 of the source nodes 310 through the first and
third service nodes 320, 324 to the PGW node 330. The second
service, S.sub.2, forwards packets from source nodes in a second
subset 314 of the source nodes 310 through the second service node
322 to the PGW node 330.
[0043] In some embodiments, the SFC may indicate a full or partial
order in which the service nodes are to handle packets belonging to
the service. For example, the SFC may specify that a first service
node is to handle packets prior to a second service node handling
the packets. In other embodiments, the order in which service nodes
are to handle packets is unspecified. This may be the case when the
order of service node visitation is not important to the
service.
[0044] Embodiments of the present invention include identifying a
set of service segments. As noted above, each service segment can
correspond to those service links which directly connect to a given
service node or to a given destination node and which are
indicative of data flow into that service node or destination node
for at least one service. All services in a given set of services
to be supported, and all service links corresponding to those
services, are considered when identifying a service segment.
[0045] In embodiments of the present invention, when the SFCs of
two different services have a common service node, and the portion
of the two SFCs that is subsequent to the common service node are
different, then the definition of one or more service segments is
adjusted. The adjustment is performed in such a manner that packets
belonging to the two different services retain different labels so
that they can subsequently be routed through the two different SFCs
based on labels. The adjustment may include splitting a service
segment into multiple segments (sub-segments). The adjustment may
include defining two different service segments corresponding to
two different sets of service links which feed directly or
indirectly to the common service node and which are indicative of
data flow into or toward that service node for at least one
service.
[0046] For example, in some embodiments, a service segment as
defined above may be separated into multiple sub-segments whenever
such multiple sub-segments are required to resolve a routing
ambiguity. The routing ambiguity may correspond to a situation in
which packets of different services traverse the same service
segment, but subsequently are required to traverse different
service segments. Separating the segment into sub-segments is
configured to avoid the routing ambiguity. The sub-segments can
overlap. For example, the sub-segments share a common service node
or destination node to which service links of the sub-segments
lead. In some cases, the service nodes and service links of two
sub-segments can be identical.
[0047] The reason for such an adjustment is to avoid aggregating
all service links in one service segment. This avoids having all
packets in a service segment being given the same label, which
would inhibit the ability of the common service node, or other
subsequent service nodes, from appropriately re-labeling packets so
that they go through their requisite planned sequence of service
nodes, in the case that packet re-labeling is based solely on
service segment identifiers carried by the packets.
[0048] In some embodiments, the adjustment to service segments may
be performed to facilitate traffic forwarding as described herein,
but may not necessarily be performed to facilitate traffic
engineering.
[0049] Alternatively, instead of adjusting service segment
definitions as above, traffic forwarding can be based in part on a
service identifier carried by the packets, rather than based solely
on the current service segment identifier carried by the
packets.
[0050] Referring again to FIG. 3, four service segments are
identified. The first service segment 342 comprises network paths
leading from the first subset 312 of source nodes to the first
service node 320. The second service segment 346 comprises network
paths leading from the second subset 314 of source nodes to the
second service node 324. The third service segment 352 comprises
network paths leading from the first service node 320 to the third
service node 324. The fourth service segment 356 comprises network
paths leading from the second and third service nodes 322, 324 to
the PGW node 330.
[0051] As an alternative, substantially equivalent definition, a
service segment can be defined by those nodes, belonging to the
union of all node groups, which are directly connected at the
endpoints of the service links corresponding to the service segment
as defined above. The service segment definition may also include a
specification of the logical interconnections between nodes.
Referring to FIG. 3, the first service segment 342 thus comprises
the first subset 312 of source nodes and the first service node
320. The second service segment 346 comprises the second subset 314
of source nodes and the second service node 324. The third service
segment 352 comprises the first service node 320 and the third
service node 324. The fourth service segment 356 comprises the
second and third service nodes 322, 324 and the PGW node 330.
[0052] It should be noted that, while FIG. 3 illustrates service
links as simple curves joining source nodes, service nodes and
destination nodes, each service link may include other components,
such as non-service nodes indicative of routers or other network
equipment, multiple network path branches which lead to nodes
operating in a series and/or parallel configuration, and the like.
The service links mask and abstract these other network elements. A
service link may correspond to a potentially complex network of
routing nodes, which may forward service packets toward the next
service node.
[0053] The service nodes correspond to intermediate destinations
for data carried by service segments. Further, the number of
service segments may be at least equal to the total number of
service nodes. Since the service nodes are treated as local
destinations on service segments, concepts from destination-based
traffic engineering and destination-based routing may be employed.
For example, given a group of flows, individual flows within the
group which have the same destination may be treated substantially
identically, with substantially no need to distinguish between such
same-destination flows. In contrast to destination-based traffic
engineering, service-based traffic engineering as employed herein
accommodates the requirement of service function chaining for
individual services. Traffic engineering uses information about the
traffic entering and leaving the network to generate a routing
scheme that optimizes network performance.
[0054] In some embodiments, a graph data structure can be defined
and used to identify the set of service segments. The graph data
structure encodes all services of the set of services being
supported. In particular, the graph data structure indicates a set
of vertices interconnected by a set of edges. Each member of the
set of vertices represents a member of a node group of at least one
service (that is, a service node, source node, or destination
node). Each node is represented in the graph once, even when it is
used by more than one service. Each member of the set of edges
represents existence of a service link between a pair of the nodes
represented by a corresponding pair of the vertices. More
particularly, an edge of the graph data structure is provided
between a first node and a second node of the graph data structure,
if and only if there is at least one SFC which specifies that
packets according to the service are to passion the first service
node to the second service node directly and with no intervening
service nodes. In the graph data structure, nodes of the node
groups are included as vertices whereas nodes which do not belong
to the node groups (such as routers interior to a service link) are
not included as explicit vertices.
[0055] In various embodiments, a service segment is represented by
a set of directed edges of the graph data structure, namely edges
that are directed to a common vertex (e.g. a vertex representing a
service node). The service segment may further be defined to
include those vertices of the graph data structure which the set of
directed edges are directed from. That is, the directed edges plus
the vertices coupled to the directed edges at either end may
constitute the service segment. The service segment excludes
portions of the graph data structure which are not immediately
connected to the set of directed edges described above.
[0056] In embodiments of the present invention, and with reference
to the graph data structure defined above, each service segment
belonging to the set of service segments can be identified as a
subset of the set of edges (also of the graph data structure), that
terminate at a common respective member of the set of vertices.
Alternatively, a service segment can he identified by the set of
vertices connected by this subset of edges.
[0057] By way of example, a scenario supporting five services
S.sub.i, i=1 to 5, is considered. With R.sub.i, i=1 to 5,
representing overlapping or non-overlapping sets of source nodes,
and A through representing service nodes, the services are defined
as:
[0058] S.sub.1:(R.sub.1, A.fwdarw.B.fwdarw.C)
[0059] S.sub.2:(R.sub.2, D.fwdarw.B.fwdarw.C)
[0060] S.sub.3:(R.sub.3, E.fwdarw.C)
[0061] S.sub.4:(R.sub.4, F.fwdarw.G.fwdarw.H)
[0062] S.sub.5: (R.sub.5, I.fwdarw.G.fwdarw.H)
[0063] FIG. 4 illustrates a graph data structure according to
S.sub.i, i=1to 5. Vertices are provided for all service nodes A
through H and connected by edges corresponding to the service
links. Some service nodes, such as B, C and C. belong to multiple,
services and thus are associated with multiple branches.
[0064] FIG. 4 further illustrates nine service segments 405, 410,
415, 420, 425, 430, 435, 440, 445 determined for the graph data
structure. The service segments can be specified in terms of an
ordered pair (X, Y) where X represents the set of source nodes and
Y represents the destination node. Under this convention, the
service segments can be specified as (R.sub.1, A) 405, (R.sub.2, D)
410, (R.sub.3, E) 415, (R.sub.4, F) 420, (R.sub.5, I) 425, ({A,D},
B) 430, ({B,E}, C) 435, ({F,I}, G) 440, and ({G}, H) 445.
[0065] If additional services are added, the graph data structure
and list of service segments may be updated accordingly. For
example, if a service S.sub.6: (R.sub.6, D.fwdarw.E.fwdarw.H) were
added, then the service segment ({G}, H) would be revised to ({G,
E}, H), and two additional service segments (R.sub.6, D) and (D,E)
would be added.
[0066] Embodiments of the present invention include determining
demands related to the service segments defined above. A service
segment comprises a set of segment-specific source nodes and a
segment-specific destination node. A segment-specific source node
is a source node or a service node, belonging to a service segment,
from which service packets flow into the service segment. A
segment-specified destination node is a service node or a
destination node, belonging to a service segment, to which service
packets in the service segment flow. As such, segment-specific
source and destination nodes behave as source and destination nodes
when the service segment is viewed in isolation. A segment-specific
source node need not be a source node of a service. When service
segments are coupled together in sequence, a segment-specific
Source node of one service segment can be a segment-specified
destination node of another service segment and vice-versa.
[0067] Determining the demand of a service segment corresponds to
determining the demands for all segment-specific source nodes of
the service segment. This can be performed through a recursive
process as described below. Other, substantially equivalent
calculations may be applied to determine the demands of service
segments.
[0068] According to embodiments of the present invention, service
segments demands are derived as follows. Where K is the number of
identified service segments, each service segment is assigned an
index value from 1 to K. For each service segment indexed from k=1
to k=K, S.sup.k represents the set of segment-specific source nodes
of service segment k, and q.sup.k represents the segment-specific
destination node of service segment k. Where, for a given pair of
index values k and j, node q.sup.k belongs to S.sup.j (i.e. the
segment-specific destination node of service segment k is a
segment-specific source node for service segment j), a
corresponding segment-specific: demand is specified as:
d j ( q k ) = n .di-elect cons. S k d k ( n ) . ( 1 )
##EQU00001##
[0069] A recursive process for determining the segment-specific
demands is described as follows. First, service segments k are
identified in which all nodes in S.sup.k are also source nodes of
services. For nodes n in S.sup.k, set d.sup.k(n) equal to an amount
of demand specified for node n acting as a source node of the
corresponding service.
[0070] Next, for the identified service segments k in which all
nodes in S.sup.k are also source nodes of services, and for service
segments j for which q.sup.k belongs to S.sup.j, evaluate
d.sup.j(q.sup.k) according to Equation (1).
[0071] Next, repeat the following process until the demands of all
service segments are known. Determine service segments k for which
d.sup.k(n) is known for all nodes n in S.sup.k but for which
d.sup.j(q.sup.k) is not yet determined for service segments j for
which q.sup.k belongs to S.sup.j. For these service segments,
evaluate d.sup.j(q.sup.k) according to Equation (1) (where j is
such that q.sup.k belongs to S.sup.j). It is noted that a given
segment-specific destination node q.sup.k may belong to multiple
sets of segment-specific source nodes, associated with more than
one service segment.
[0072] As an example, in terms of FIG. 3, the d.sup.k(n) values may
be determined for source nodes in set 310. The d.sup.k(n) values
may then be determined for service nodes 320 and 322. The
d.sup.k(n) value may then be determined for service node 324, as
equal to the d.sup.k(n) value of service node 320. Finally, the
d.sup.k(n) value may be determined for destination node 330, as a
sum of d.sup.k(n) values of service nodes 322 and 324.
[0073] In some embodiments, an alternative method for determining
demands of service segments can be used. The alternative method
comprises measuring traffic data rates entering a segment-specific,
source node within a service segment, and using the measured
traffic data rate as the appropriate d.sup.k(n) value.
[0074] Embodiments of the present invention relate to determining a
set of flow group conservation constraints which specify how data
is introduced at sources, flows through intermediate nodes, and
reaches intended destinations. The flow group conservation
constraints are expressed in terms of the service segments which
are determined as described above, and in terms of the d.sup.k(n)
values indicative of aggregate (cumulative) demands at the various
source nodes and service nodes, as also described above. In other
words, for a service segment k, d.sup.k(n) represents a combined or
cumulative amount of demand. More particularly, this amount of
demand represents the combined demand of source nodes belonging to
particular services, out of the set of all services, for which
service packets pass through the service segment k.
[0075] In various embodiments of the present invention, each
physical node, including but not limited to service nodes, is
associated with number of flow group conservation constraints
substantially equal to the number of service segments associated
with that physical node.
[0076] In the formulation below, A.sub.in(n) and A.sub.out(n)
represent the set of links terminating at a network node n and the
set of links originating at node n, respectively. As before,
S.sup.k represents the set of segment-specific source nodes for a
service segment k, and q.sup.k represents the segment-specific
destination node for service segment k. The segment-specific source
nodes and segment-specific destination node for a service segment
are different than the source nodes and destination nodes for a
service. The segment-specific destination node is the node of the
service segment that receives the service traffic. The
segment-specific source nodes for a service segment are the nodes
of the service segment that provide the service traffic, for
example as packets received from other nodes and forwarded on to
the service segment.
[0077] For each node n including but not necessarily limited to
source nodes, service nodes and destination nodes, and for each
service segment k indexed from 1 to K, a flow group conservation
constraint is defined as follows:
a .di-elect cons. A in ( n ) x a k - a .di-elect cons. A out ( n )
x a k = { 0 , n S k , n .noteq. q k - d k ( n ) , n .di-elect cons.
S k m .di-elect cons. S k d k ( m ) , n = q k ##EQU00002##
[0078] The variables x.sup.k a may be viewed as decision variables
indicative of an amount of resource allocation for link a connected
to node n for conveying data in support of service segment k.
[0079] For nodes which are neither segment-specific source node nor
segment-specific destination nodes, the flow group conservation
constraints reflect that the amount of resource allocation on links
out of the node is equal to the amount of source allocation on
links into the node.
[0080] For nodes which are segment-specific destination nodes, the
flow group conservation constraints reflect that the amount of
resource allocation on links into the node is greater than the
amount of resource allocation on links out of the node by a margin
equal to the total incoming flow demand to the node, insofar as the
flow demand relates to services for which the node is a
segment-specific destination node.
[0081] For nodes which are segment-specific source nodes, the flow
group conservation constraints reflect that the amount of resource
allocation on links out of the node is greater than the amount of
resource allocation on links into the node by a margin equal to the
total demand of the node.
[0082] Embodiments of the present invention include determining an
allocation of communication resources that respects a set of
constraints, such as flow group conservation constraints and link
capacity constraints. Other constraints, such as non-negativity
constraints may also be explicitly added if required. The
allocation may correspond to the amount of rate assigned and/or
reserved by a supervisory traffic engineering controller on a given
link for a given flow group or service.
[0083] Prior to determining the allocation of communication
resources, the constraints are determined. In particular, the flow
group conservation constraint may be determined for nodes and
service segments in the communication network, as described
above.
[0084] The link capacity constraints may be determined from
received information about the communication network. For links a
in the communication network, an associated maximum link capacity
may be received as a predetermined quantity c.sub.a, for example
given in bits per second. The link capacity constraint is then
formulated as:
k = 1 K x a k .ltoreq. c a , ##EQU00003##
where K is the number of service segments and x.sup.k.sub.a is the
allocation on link a for service segment k.
[0085] As noted above, embodiments of the present invention
comprise determining a resource allocation which satisfies the flow
group conservation constraints and the link capacity constraints.
The resource allocation may also maximize or approximately maximize
a predetermined objective function U(x). Here, x is a vector
consisting of entries x.sup.k.sub.a over all links a and service
segments k for which x.sup.k.sub.a is defined as described above.
The objective function may encode one or more given network
objectives such as load balancing, sum rate maximization, and
weighted sum rate maximization, as would be readily understood by a
worker skilled in the art.
[0086] As such, determining the resource allocation may correspond
to solving a constrained optimization problem. Depending on the
form of the optimization problem, various solution techniques may
be employed, such as linear programming solution techniques, branch
and bound algorithms, heuristic methods based on problem structure,
or the like. In some embodiments, the constrained optimization
problem may be at least partially formulated as:
max x U ( x ) ##EQU00004##
[0087] subject to:
a .di-elect cons. A in ( n ) x a k - a .di-elect cons. A out ( n )
x a k = { 0 , n S k , n .noteq. q k - d k ( n ) , n .di-elect cons.
S k m .di-elect cons. S k d k ( m ) , n = q k ##EQU00005##
[0088] for k=1 to K and
[0089] all nodes n of the network.
k = 1 K x a k .ltoreq. c a , ##EQU00006##
for all .alpha. for which x.sup.k.sub.a is defined.
[0090] In some embodiments, the optimization problem may be solved
jointly for all service segments. In some embodiments, the
optimization problem may be solved in stages, each stage
corresponding to a different service segment or set of service
segments.
[0091] The solution x to the constrained optimization problem can
be used as a basis for controlling resource allocations of network
nodes, such as service nodes, in a manner which accommodates the
services provided. Nodes can be informed of the resource
allocations, which may correspond to bandwidth reservations, and
the nodes can subsequently implement packet handling policies,
including traffic forwarding and routing policies, that respect the
resource allocations.
[0092] Various embodiments of the invention relate to a method of
traffic forwarding in a multi-hop data network, in a manner
supportive of services associated with Service Function Chains
(SFCs). Accordingly, a data plane forwarding mechanism may be
provided which causes service packets to be routed through a
corresponding sequence of service nodes associated with a SFC.
[0093] In accordance with embodiments, packets are labeled with an
indication of a service segment to be traversed, prior to traversal
of same. Packets which are to sequentially traverse multiple
service segments may be re-labeled once or several times. The
number of re-labelings (following initial labeling) may equal the
number of service nodes being visited prior to the destination
node. Packet labeling and re-labeling may include configuring a
field in the packet header, such as a destination address field.
Packet labeling and re-labeling May occur at source nodes and at
service nodes located at the boundaries between service segments.
Packets labeled with an indication of a service segment are handled
by routers and other network equipment in a manner that forwards
the packets toward the "root" service node (or destination node) of
that service segment. The root node is the node to which all
service links of the service segment commonly lead.
[0094] Forwarding of a labeled packet may be performed similarly to
destination-based routing operations. Destination-based traffic
engineering is described for example in H. Abrahamsson et al. "A
multi-path routing algorithm for IP networks based on flow
optimization," international Workshop on Quality of Future Internet
Services, Zurich, October 2002. in some embodiments of the present
invention, destination-based routing may be performed based on the
current packet label, and a sequence of destination-based routing
operations may be applied to a packet based on the corresponding
sequence of packet labels as re-labeling occurs,
[0095] In various embodiments, packet labeling/e-labelling
information may be transmitted to various source nodes and/or
service nodes for use in labeling and re-labeling of packets. The
information may be transmitted via control plane messages, for
example, and may correspond to a rule or set of rules, a lookup
table, or other format.
[0096] In various embodiments, the new service segment identifier
with which to re-label a packet is based solely on the existing
service segment identifier carried by the packet. A packet
re-labeling table may be provided to the service node with pairs of
entries listing existing service segment identifiers and new
segment identifiers. The service node, in receipt of a packet may
look up the existing service segment identifier in the table and
replace it with the corresponding new service segment identifier.
In other embodiments, the packet may carry with it an identifier of
the service to which it belongs. In this case, packet service
segment identifier labeling and/or re-labeling may be based on the
service identifier rather than the current service segment
identifier. For example, service nodes may hold a table which
relates service identifiers to the corresponding service segment
identifiers to be used next.
[0097] Network nodes, including but not limited to service nodes,
may implement packet routing using a routing table which is based
on service segment identifiers. Correspondence between service
segment identifiers of packets and an outgoing link on which to
forward the packets may be encoded within the routing tables. At
service nodes, packet re-labeling information may be integrated
with the routing table.
[0098] When each service node is associated with exactly one
outgoing service link, service segment identifiers used for routing
purposes may correspond directly to the service segment identifiers
used for traffic engineering purposes. However, when one or more
service nodes are associated with multiple outgoing service links,
a finer-grained set of service segment identifiers used for routing
purposes may be required. FIG. 5 illustrates a motivating example,
in which Service Node SN3 546 supports two services outgoing on two
different service links corresponding to two different service
segments 525, 530. The services are defined as S.sub.1:
SN1.fwdarw.SN3.fwdarw.SN4.fwdarw.PGW), and S.sub.2: (R.sub.2,
SN2.fwdarw.SN3.fwdarw.SN5.fwdarw.PGW). If both incoming service
links to SN3 546 were associated with a single service segment
identifier, and service nodes were configured to perform label
switching based solely on the current service segment identifier,
then SN3 546 would be unable to differentiate between the two
services and forward packets onto the appropriate outgoing service
link. One solution in this particular case is to associate each of
the incoming links to SN3 546 with a different service segment
identifier.
[0099] In more detail, FIG. 5 illustrates a first service segment
S.sub.1 505 incoming to a first service node SN1 542, a second
service segment S.sub.2 510 incoming to a second service node SN2
544, third and fourth service segments S.sub.3 515 and S.sub.4 520
incoming to a third service node SN3 546, a fifth service segment
S.sub.5 525 incoming to a fourth service node SN4 548, a sixth
service segment S.sub.6 530 incoming to a fifth service node SN5
550, and a seventh service segment S.sub.7 535 incoming to a
destination node PGW 552.
[0100] More generally, when two SFCs coincide at one or more nodes,
but diverge subsequently to the coinciding nodes, then a separate
service segment may be defined for each SFC, to facilitate routing
based solely on service segment identifiers. When the two SFCs
share a service link, the shared service link may be associated
with two service segments. This principle can be readily extended
to multiple SFCs.
[0101] For example, consider two services, S.sub.1: (R.sub.1,
SN1.fwdarw.SN3.fwdarw.SN4.fwdarw.PGW) and S.sub.2: (R.sub.2,
SN1.fwdarw.SN3.fwdarw.SN5.fwdarw.PGW). If SN3 is required to
differentiate between S.sub.1 and S.sub.2 based on service segment
identifier, then two separate service segments between SN1 and SN3
can be defined, and packets belonging to S.sub.1 may traverse one
of the service segments while packets belonging to S.sub.2 traverse
the other. It is noted that the two logical service segments may
share the same underlying physical resources. Similarly, the
service segment between R.sub.1 and SN1 should be different than
the service segment between R.sub.2 and SN.sub.1. This may be
automatic if R.sub.1 and R.sub.2 are disjoint, but the definition
of service segments may require additional handling rules if
R.sub.1 and R.sub.2 overlap or coincide.
[0102] Embodiments of the present invention comprise controlling
operation of the data network in accordance with the determined
resource allocation. Controlling operation of the data network may
include providing instructions to various network elements such as
routers and service nodes, the instructions directing the network
elements to implement the determined resource allocations. The
instructions may additionally or alternatively direct the network
elements to route packets according to the resource allocation. The
instructions may direct the network elements to route packets in a
manner that causes packets belonging to given services to traverse
a path corresponding to the SFC of that service. In some
embodiments, controlling operation of the data network may further
include routing packets according to the resource allocation. As
such, while some embodiments of the present invention relate to
traffic engineering control of the data network, other embodiments
may relate to both control of the data network and execution of
data network operations, such as packet routing, in accordance with
such traffic engineering control.
[0103] Embodiments of the present invention may include a
service-based traffic engineering controller located in a
communication network control plane. FIG. 6 illustrates a traffic
engineering controller 600 configured to receive service
information 620, such as definitions of services, service function
chains, and demand levels of source nodes associated with the
services. The traffic engineering controller is further configured
to receive network topology information 625 and network parameter
information 627. Network topology information may be descriptive of
the locations of nodes in the network and data links therebetween.
Network parameter information may include capacities for the data
links. The traffic engineering controller is configured to
determine a resource allocation which supports the services, for
example by solving the constrained optimization problem as
described above.
[0104] The traffic engineering controller is further configured to
provide service-based forwarding information 630 and service-based
label switching information 635. Service-based forwarding
information may be determined, by the traffic engineering
controller, based on the resource allocation determined for the
data network. The resource allocation may be determined by solving
the constrained optimization problem for x as described above. For
example, suppose the resource allocation solution x includes
particular non-zero values x.sup.k.sub.a for a given service
segment k and set of associated outgoing physical links a=1, 2, . .
. . The service-based forwarding information may then specify that,
when packets with service segment identifier k arrive at node n,
they are forwarded onto each outgoing physical link a with a
traffic volume proportional to
P(a)=x.sub.a.sup.k/.SIGMA..sub.ax.sub.a.sup.k. For example, each
service packet at node n can be forwarded onto link a with
probability P(a).
[0105] Service-based label switching information may be determined,
by the traffic engineering controller, based on the identification
of service segments. For example, service nodes located at the
boundaries of service segments may be identified and provided with
label-switching information. The label-switching information may
indicate a rule, such as: IF incoming packet is labeled with
service segment identifier m.sub.1, THEN change the label of the
packet to service segment identifier m.sub.2, where m.sub.1 and
m.sub.2 are specified by the rule. While label switching may occur
at service nodes, label switching may not occur at other nodes,
such as intermediate routers internal to a service link.
[0106] The traffic engineering controller includes an input network
interface 605 configured to receive information such as the service
information, network topology information and network parameter
information. The input network interface may be connected to other
networked devices or functions which act as sources for such
information. The traffic engineering controller further includes an
output network interface 610 configured to transmit signals for
controlling operation of the data network in accordance with the
determined resource allocation. The control signals may include
information such as the service-based forwarding information and
the service-based label switching information. The output network
interface may be connected via the communication network control
plane to various other network devices such as routers, service
nodes, service based forwarding controller, and the like, which use
this information to perform packet handling operations. The traffic
engineering controller further includes a processor 615 operatively
coupled to memory 617, the processor configured to execute program
instructions stored in the memory in order to determine a desired
resource allocation based on the service information, network
topology information and network parameter information, as well as
determining the service-based forwarding information and the
service-based label switching information. The processor may be a
microprocessor or collection of microprocessors configured to
execute program instructions stored in memory, or another
electronic processing device such as a microcontroller,
application-specific integrated circuit, or other processing
hardware. In some embodiments, as the operations of the processor
are computationally intensive and repeatedly performed, a
relatively powerful processing facility such as a set of parallel
processors may be utilized.
[0107] The traffic engineering controller may include a networked
computing device, a collection of computing devices, or a
virtualized computing device. Virtualized computing devices may be
hosted by general-purpose computing hardware in one or more
locations.
[0108] Embodiments of the present invention include one or more
routers which are configured to operate as described herein to
inspect, handle and potentially modify received packets.
[0109] FIG. 7 illustrates a traffic engineering controller 600
operatively coupled to a service-based forwarding function 700
residing in a data plane, in accordance with an embodiment of the
present invention. The service-based forwarding function 700 may be
implemented at a plurality of routers or other network nodes, in a
distributed manner, for example. The service-based forwarding
function 700 may also be implemented by networked computing device,
a collection of networked computing devices, or a virtualized
computing device. In some embodiments, the service-based forwarding
function 700 may be implemented by one or a plurality of network
routers, nodes, source nodes, or service nodes.
[0110] The service-based forwarding function 700 is configured to
receive the service-based forwarding information 630 and the
service-based label switching information 635 from the traffic
engineering controller. The information may be conveyed via control
messages through the data network. The service-based forwarding
function 700 is further configured to implement packet forwarding
710 in the data network in compliance with the service-based
forwarding information 630 and the service-based label switching
information 635.
[0111] For example, the service-based forwarding function may be
configured to handle packets in accordance with resource
allocations specified in the service-based forwarding information
provided by the traffic engineering controller. The service-based
forwarding function may further be configured to perform routing
and packet labeling and re-labeling according to service-based
label switching information provided by the traffic engineering
controller.
[0112] FIG. 8 illustrates a router configured to implement at least
part of the service-based forwarding function, in accordance with
embodiments of the present invention. The service-based router
includes an input network interface 805 configured to receive
information such as the service-based forwarding information 630
and the service-based label switching information 635. The router
further includes data packet handling interface 810 configured to
receive, handle and forward data packets in accordance with the
service-based forwarding information and the service-based label
switching information. The data packet handling interface 810 may
be configured to receive and transmit data packets to and from the
network on several selectable links. The data packet handling
interface 810 may be associated with a routing table 830 configured
to control routing of data packets. The router further includes a
processor 815 operatively coupled to memory 820, the processor
configured to execute program instructions stored in the memory in
order to implement packet handling functions in accordance with the
present invention, for example by updating the routing table 830.
Alternatively, the processor and memory may be replaced with other
processing components, such as dedicated logic components,
firmware, or integrated circuits.
[0113] FIGS. 9A to 9C illustrate a sequence of operations being
performed in accordance with embodiments of the present invention.
As illustrated, the sequence of operations includes identifying 905
service segments for a portion of the communication network. The
identification is based on information regarding a set of services
to be supported. The identification 905 of service segments
includes identifying 910 SFCs of all services to be supported. The
STCs may be explicitly or implicitly defined by the services. In
the present embodiment, the identification of service segments
further includes forming 915 a graph data structure according to
the identified SFCs. The graph data structure encodes the topology
of services being supported, for example as a tree graph, as
discussed above. The identification of service segments further
includes identifying 920 service segments, based on the graph data
structure, as collections of nodes in the graph data structure, as
also discussed above.
[0114] As further illustrated, the sequence of operations includes
determining 930 demands for the identified service segments. The
demands for service segments can be determined separately 935 for
each service segment and for each node n of the graph data
structure. The demand a.sup.k(n) for service segment k and node n
can be determined using Equation (1) as described above.
[0115] As further illustrated, the sequence of operations includes
determining 940 flow group conservation constraints for each
service segment k and each node n. The flow group conservation
constraints are expressed based on the demands d.sup.k(n) and are
also discussed above.
[0116] As further illustrated, the sequence of operations includes
determining 960 a feasible and/or optimal traffic allocation
subject to the determined conservation constraints along with link
capacity constraints. This may include computing a solution to an
optimization problem as illustrated, and also as described
above.
[0117] In some embodiments, the network nodes may further be
configured to provide information to the traffic engineering
controller, the service-based forwarding function, or both. The
information may be indicative of performance feedback, network
topology, data traffic conditions, and may be used to adjust
operation of the traffic engineering controller and/or
service-based forwarding controller.
[0118] Through the descriptions of the preceding embodiments, the
present invention may be implemented by using hardware only or by
using software and a necessary universal hardware platform. Based
on such understandings, the technical solution of the present
invention may be embodied in the form of a software product. The
software product may be stored in a non-volatile or non-transitory
storage medium, which can be a compact disk read-only memory
(CD-ROM), USB flash disk, or a removable hard disk. The software
product includes a number of instructions that enable a computer
device (personal computer, server, or network device) to execute
the methods provided in the embodiments of the present invention.
For example, such an execution may correspond to a simulation of
the logical operations as described herein. The software product
may additionally or alternatively include number of instructions
that enable a computer device to execute operations for configuring
or programming a digital logic apparatus in accordance with
embodiments of the present invention.
[0119] Various methods as disclosed herein may be implemented on
one or more real or virtual computing devices, such as devices
within a communication network control plane, devices operating in
the data plane, or a combination thereof. Computing devices used to
implement method operations may include a processor operatively
coupled to memory, the memory providing instructions for execution
by the processor to perform the method as described herein.
[0120] In some embodiments the traffic engineering controller,
aspects of the service-based forwarding function and/or service
nodes can be configured with sufficient functionality to enable
instantiation of their respective functionality on an as-needed
basis according to current processing requirements. These may, for
example, be realized as virtual network functions (VNFs) within a
Network Function Virtualization (NFV) framework. For example, a VNF
corresponds to a function enabling operation of a communication
network. For example a VNF can provide the functions of a router,
switch, gateway, firewall, load balancer, server, mobility
management entity, and the like. The function is virtualized in the
sense that it may utilize a set of virtual resources, such as
computing, storage and networking resources, rather than utilizing
dedicated hardware resources. As such, VNF may be instantiated on
an as-needed basis using available virtual resources. NFV and
virtual network functions architecture is described in ETSI GS
NFV-SWA 001, for example.
[0121] In some embodiments the traffic engineering controller,
aspects of the service-based forwarding function and/or service
nodes may comprise software defined networking (SDN) components, or
programs deployed on the same or differing device platforms of the
communication network. SDN is an architectural framework for
creating intelligent programmable networks, where the control
planes and the data planes are decoupled, network intelligence and
state are logically centralized, and the underlying network
infrastructure is abstracted from the application. In embodiments
of the present invention, the control plane may use customer
information and provide information to form a network logical
topology, for example as created via software defined toplogy
(SDT). The SDT can be combined with the SDIN and software defined
protocol (SDP) to create a customized virtual network (VN). A VN is
a collection of resources virtualized for a particular service.
Customers include users of services via a LEE, terminal, or other
customer device. Providers include service providers, VN operators,
and other providers of services over the wireless network.
[0122] As a separate matter, SDN allows for the management of
network services through abstraction of lower-level functionality,
Control functions may be separated from forwarding functions for
example by controlling the forwarding nodes from a control element.
NFV can facilitate the virtualization of entire classes of network
node functions. VNF can comprise or operate on one or more virtual
machines running on relatively generic servers or computing
equipment, such as commercial off-the-shelf hardware capable of
being configured to provide a variety of functionalities, as
opposed to dedicated hardware for a given functionality.
[0123] Various embodiments of the present invention utilize real
and/or virtual computer resources. Such computer resources utilize,
at a hardware level, a set of one or more microprocessors
operatively coupled to a corresponding set of memory components
which include stored program instructions for execution by the
microprocessors. Computing resources may be used to provide virtual
computing resources at one or more levels of virtualization. For
example, one or more given generic computer hardware platforms may
be used to provide one or more virtual computing machines. Computer
hardware, such as processor resources, memory, and the like, may
also be virtualized in order to provide resources from which
further virtual computing machines are built. A set of computing
resources which are allocatable for providing various computing
resources which in turn are used to realize various computing
components of a system, may be regarded as providing a distributed
computing system, the internal architecture of which may be
configured in various ways.
[0124] Although the present invention has been described with
reference to specific features and embodiments thereof, it is
evident that various modifications and combinations can be made
thereto without departing from the invention. The specification and
drawings are, accordingly, to be regarded simply as an illustration
of the invention as defined by the appended claims, and are
contemplated to cover any and all modifications, variations,
combinations or equivalents that fall within the scope of the
present invention.
* * * * *