Yang model for requesting Path Computation
draft-ietf-teas-yang-path-computation-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Italo Busi , Sergio Belotti , Victor Lopez , Oscar Gonzalez de Dios , ansharma@infinera.com , Yan Shi , Ricard Vilalta , Karthik Sethuraman , Michael Scharf , Daniele Ceccarelli | ||
| Last updated | 2017-12-19 (Latest revision 2017-11-12) | ||
| Replaces | draft-busibel-teas-yang-path-computation | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-teas-yang-path-computation-00
TEAS Working Group Italo Busi (Ed.)
Internet Draft Huawei
Intended status: Informational Sergio Belotti (Ed.)
Expires: May 2018 Nokia
Victor Lopez
Oscar Gonzalez de Dios
Telefonica
Anurag Sharma
Infinera
Yan Shi
China Unicom
Ricard Vilalta
CTTC
Karthik Sethuraman
NEC
November 13, 2017
Yang model for requesting Path Computation
draft-ietf-teas-yang-path-computation-00.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
Busi, Belotti, al. Expires May 13, 2018 [Page 1]
Internet-DraftYang model for requesting Path Computation November 2017
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on May 13, 2016.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Abstract
There are scenarios, typically in a hierarchical SDN context, in
which an orchestrator may not have detailed information to be able
to perform an end-to-end path computation and would need to request
lower layer/domain controllers to calculate some (partial) feasible
paths.
Multiple protocol solutions can be used for communication between
different controller hierarchical levels. This document assumes that
the controllers are communicating using YANG-based protocols (e.g.,
NETCONF or RESTCONF).
This document describes some use cases where a path computation
request, via YANG-based protocols (e.g., NETCONF or RESTCONF), can
be needed.
This document also proposes a yang model for a stateless RPC which
complements the stateful solution defined in [TE-TUNNEL].
Table of Contents
1. Introduction...................................................3
2. Use Cases......................................................4
Busi, Belotti, et al. Expires May 13, 2018 [Page 2]
Internet-DraftYang model for requesting Path Computation November 2017
2.1. IP-Optical integration....................................5
2.1.1. Inter-layer path computation.........................6
2.1.2. Route Diverse IP Services............................8
2.2. Multi-domain TE Networks..................................8
2.3. Data center interconnections..............................9
3. Interactions with TE Topology.................................11
3.1. TE Topology Aggregation using the "virtual link model"...11
3.2. TE Topology Abstraction..................................19
3.3. Complementary use of TE topology and path computation....20
4. Motivation for a YANG Model...................................22
4.1. Benefits of common data models...........................22
4.2. Benefits of a single interface...........................23
4.3. Extensibility............................................23
5. Path Computation for multiple LSPs............................24
6. YANG Model for requesting Path Computation....................25
6.1. Stateless and Stateful Path Computation..................25
6.2. YANG model for stateless TE path computation.............26
6.2.1. YANG Tree...........................................26
6.2.2. YANG Module.........................................34
7. Security Considerations.......................................40
8. IANA Considerations...........................................41
9. References....................................................41
9.1. Normative References.....................................41
9.2. Informative References...................................42
10. Acknowledgments..............................................42
1. Introduction
There are scenarios, typically in a hierarchical SDN context, in
which an orchestrator may not have detailed information to be able
to perform an end-to-end path computation and would need to request
lower layer/domain controllers to calculate some (partial) feasible
paths.
When we are thinking to this type of scenarios we have in mind
specific level of interfaces on which this request can be applied.
We can reference ABNO Control Interface [RFC7491] in which an
Application Service Coordinator can request ABNO controller to take
in charge path calculation (see Figure 1 in the RFC) and/or ACTN
[ACTN-frame],where controller hierarchy is defined, the need for
path computation arises on both interfaces CMI (interface between
Customer Network Controller(CNC) and Multi Domain Service
Coordinator (MDSC)) and/or MPI (interface between MSDC-PNC).[ACTN-
Busi, Belotti, et al. Expires May 13, 2018 [Page 3]
Internet-DraftYang model for requesting Path Computation November 2017
Info] describes an information model for the Path Computation
request.
Multiple protocol solutions can be used for communication between
different controller hierarchical levels. This document assumes that
the controllers are communicating using YANG-based protocols (e.g.,
NETCONF or RESTCONF).
Path Computation Elements, Controllers and Orchestrators perform
their operations based on Traffic Engineering Databases (TED). Such
TEDs can be described, in a technology agnostic way, with the YANG
Data Model for TE Topologies [TE-TOPO]. Furthermore, the technology
specific details of the TED are modeled in the augmented TE topology
models (e.g. [L1-TOPO] for Layer-1 ODU technologies).
The availability of such topology models allows providing the TED
using YANG-based protocols (e.g., NETCONF or RESTCONF). Furthermore,
it enables a PCE/Controller performing the necessary abstractions or
modifications and offering this customized topology to another
PCE/Controller or high level orchestrator.
The tunnels that can be provided over the networks described with
the topology models can be also set-up, deleted and modified via
YANG-based protocols (e.g., NETCONF or RESTCONF)using the TE-Tunnel
Yang model [TE-TUNNEL].
This document describes some use cases where a path computation
request, via YANG-based protocols (e.g., NETCONF or RESTCONF), can
be needed.
This document also proposes a yang model for a stateless RPC which
complements the stateful solution defined in [TE-TUNNEL].
2. Use Cases
This section presents different use cases, where an orchestrator
needs to request underlying SDN controllers for path computation.
The presented uses cases have been grouped, depending on the
different underlying topologies: a) IP-Optical integration; b)
Multi-domain Traffic Engineered (TE) Networks; and c) Data center
interconnections.
Busi, Belotti, et al. Expires May 13, 2018 [Page 4]
Internet-DraftYang model for requesting Path Computation November 2017
2.1. IP-Optical integration
In these use cases, an Optical domain is used to provide
connectivity between IP routers which are connected with the Optical
domains using access links (see Figure 1).
--------------------------------------------------------------------
I I
I I
I I
I IP+Optical Use Cases I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
Figure 1 - IP+Optical Use Cases
It is assumed that the Optical domain controller provides to the
orchestrator an abstracted view of the Optical network. A possible
abstraction shall be representing the optical domain as one "virtual
node" with "virtual ports" connected to the access links.
The path computation request helps the orchestrator to know which
are the real connections that can be provided at the optical domain.
Busi, Belotti, et al. Expires May 13, 2018 [Page 5]
Internet-DraftYang model for requesting Path Computation November 2017
--------------------------------------------------------------------
I I
I I
I I
I I
I I
I I
I I
I I
I IP+Optical Topology Abstraction I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
Figure 2 - IP+Optical Topology Abstraction
2.1.1. Inter-layer path computation
In this use case, the orchestrator needs to setup an optimal path
between two IP routers R1 and R2.
As depicted in Figure 2, the Orchestrator has only an "abstracted
view" of the physical network, and it does not know the feasibility
or the cost of the possible optical paths (e.g., VP1-VP4 and VP2-
VP5), which depend from the current status of the physical resources
within the optical network and on vendor-specific optical
attributes.
The orchestrator can request the underlying Optical domain
controller to compute a set of potential optimal paths, taking into
account optical constraints. Then, based on its own constraints,
policy and knowledge (e.g. cost of the access links), it can choose
Busi, Belotti, et al. Expires May 13, 2018 [Page 6]
Internet-DraftYang model for requesting Path Computation November 2017
which one of these potential paths to use to setup the optimal e2e
path crossing optical network.
--------------------------------------------------------------------
I I
I IP+Optical Path Computation Example I
I I
I I
I (only in PDF version) I
I I
--------------------------------------------------------------------
Figure 3 - IP+Optical Path Computation Example
For example, in Figure 3, the Orchestrator can request the Optical
domain controller to compute the paths between VP1-VP4 and VP2-VP5
and then decide to setup the optimal end-to-end path using the VP2-
VP5 Optical path even this is not the optimal path from the Optical
domain perspective.
Considering the dynamicity of the connectivity constraints of an
Optical domain, it is possible that a path computed by the Optical
domain controller when requested by the Orchestrator is no longer
valid when the Orchestrator requests it to be setup up.
It is worth noting that with the approach proposed in this document,
the likelihood for this issue to happen can be quite small since the
time window between the path computation request and the path setup
request should be quite short (especially if compared with the time
that would be needed to update the information of a very detailed
abstract connectivity matrix).
If this risk is still not acceptable, the Orchestrator may also
optionally request the Optical domain controller not only to compute
the path but also to keep track of its resources (e.g., these
resources can be reserved to avoid being used by any other
connection). In this case, some mechanism (e.g., a timeout) needs to
be defined to avoid having stranded resources within the Optical
domain.
These issues and solutions can be fine-tuned during the design of
the YANG model for requesting Path Computation.
Busi, Belotti, et al. Expires May 13, 2018 [Page 7]
Internet-DraftYang model for requesting Path Computation November 2017
2.1.2. Route Diverse IP Services
This is for further study.
2.2. Multi-domain TE Networks
In this use case there are two TE domains which are interconnected
together by multiple inter-domains links.
A possible example could be a multi-domain optical network.
--------------------------------------------------------------------
I I
I I
I I
I I
I I
I I
I Multi-domain multi-link interconnection I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
Figure 4 - Multi-domain multi-link interconnection
In order to setup an end-to-end multi-domain TEpath (e.g., between
nodes A and H), the orchestrator needs to know the feasibility or
the cost of the possible TE paths within the two TE domains, which
depend from the current status of the physical resources within each
TE network. This is more challenging in case of optical networks
because the optimal paths depend also on vendor-specific optical
attributes (which may be different in the two domains if they are
provided by different vendors).
Busi, Belotti, et al. Expires May 13, 2018 [Page 8]
Internet-DraftYang model for requesting Path Computation November 2017
In order to setup a multi-domain TE path (e.g., between nodes A and
H), Orchestrator can request the TE domain controllers to compute a
set of intra-domain optimal paths and take decisions based on the
information received. For example:
o The Orchestrator asks TE domain controllers to provide set of
paths between A-C, A-D, E-H and F-H
o TE domain controllers return a set of feasible paths with the
associated costs: the path A-C is not part of this set(in optical
networks, it is typical to have some paths not being feasible due
to optical constraints that are known only by the optical domain
controller)
o The Orchestrator will select the path A- D-F- H since it is the
only feasible multi-domain path and then request the TE domain
controllers to setup the A-D and F-H intra-domain paths
o If there are multiple feasible paths, the Orchestrator can select
the optimal path knowing the cost of the intra-domain paths
(provided by the TE domain controllers) and the cost of the
inter-domain links (known by the Orchestrator)
This approach may have some scalability issues when the number of TE
domains is quite big (e.g. 20).
In this case, it would be worthwhile using the abstract TE topology
information provided by the domain controllers to limit the number of
potential optimal end-to-end paths and then request path computation
to fewer domain controllers in order to decide what the optimal path
within this limited set is.
For more details, see section 3.3.
2.3. Data center interconnections
In these use case, there is an TE domain which is used to provide
connectivity between data centers which are connected with the TE
domain using access links.
Busi, Belotti, et al. Expires May 13, 2018 [Page 9]
Internet-DraftYang model for requesting Path Computation November 2017
--------------------------------------------------------------------
I I
I I
I I
I I
I I
I I
I Data Center Interconnection Use Case I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
I I
I I
I I
--------------------------------------------------------------------
Figure 5 - Data Center Interconnection Use Case
In this use case, a virtual machine within Data Center 1 (DC1) needs
to transfer data to another virtual machine that can reside either
in DC2 or in DC3.
The optimal decision depends both on the cost of the TE path (DC1-
DC2 or DC1-DC3) and of the computing power (data center resources)
within DC2 or DC3.
The Cloud Orchestrator may not be able to make this decision because
it has only an abstract view of the TE network (as in use case in
2.1).
The cloud orchestrator can request to the TE domain controller to
compute the cost of the possible TE paths (e.g., DC1-DC2 and DC1-
DC3) and to the DC controller to compute the cost of the computing
power (DC resources) within DC2 and DC3 and then it can take the
decision about the optimal solution based on this information and
its policy.
Busi, Belotti, et al. Expires May 13, 2018 [Page 10]
Internet-DraftYang model for requesting Path Computation November 2017
3. Interactions with TE Topology
The use cases described in section 2 have been described assuming
that the topology view exported by each underlying SDN controller to
the orchestrator is aggregated using the "virtual node model",
defined in [RFC7926].
TE Topology information, e.g., as provided by [TE-TOPO], could in
theory be used by an underlying SDN controllers to provide TE
information to the orchestrator thus allowing the Path Computation
Element (PCE) within the Orchestrator to perform multi-domain path
computation by its own, without requesting path computations to the
underlying SDN controllers.
This section analyzes the need for an orchestrator to request
underlying SDN controllers for path computation even in these
scenarios as well as how the TE Topology information and the path
computation can be complementary.
In nutshell, there is a scalability trade-off between providing all
the TE information needed by the Orchestrator's PCE to take optimal
path computation decisions by its own versus requesting the
Orchestrator to ask to too many underlying SDN Domain Controllers a
set of feasible optimal intra-domain TE paths.
3.1. TE Topology Aggregation using the "virtual link model"
Using the TE Topology model, as defined in [TE-TOPO], the underlying
SDN controller can export the whole TE domain as a single abstract
TE node with a "detailed connectivity matrix", which extends the
"connectivity matrix", defined in [RFC7446], with specific TE
attributes (e.g., delay, SRLGs and summary TE metrics).
The information provided by the "detailed abstract connectivity
matrix" would be equivalent to the information that should be
provided by "virtual link model" as defined in [RFC7926].
For example, in the IP-Optical integration use case, described in
section 2.1, the Optical domain controller can make the information
shown in Figure 3 available to the Orchestrator as part of the TE
Topology information and the Orchestrator could use this information
to calculate by its own the optimal path between routers R1 and R2,
without requesting any additional information to the Optical Domain
Controller.
Busi, Belotti, et al. Expires May 13, 2018 [Page 11]
Internet-DraftYang model for requesting Path Computation November 2017
However, there is a tradeoff between the accuracy (i.e., providing
"all" the information that might be needed by the Orchestrator's
PCE) and scalability to be considered when designing the amount of
information to provide within the "detailed abstract connectivity
matrix".
Figure 6 below shows another example, similar to Figure 3, where
there are two possible Optical paths between VP1 and VP4 with
different properties (e.g., available bandwidth and cost).
--------------------------------------------------------------------
I I
I IP+Optical Path Computation Example I
I with multiple choices I
I I
I I
I I
I (only in PDF version) I
I I
--------------------------------------------------------------------
Figure 6 - IP+Optical Path Computation Example with multiple choices
Reporting all the information, as in Figure 6, using the "detailed
abstract connectivity matrix", is quite challenging from a
scalability perspective. The amount of this information is not just
based on number of end points (which would scale as N-square), but
also on many other parameters, including client rate, user
constraints / policies for the service, e.g. max latency < N ms, max
cost, etc., exclusion policies to route around busy links, min OSNR
margin, max preFEC BER etc. All these constraints could be different
based on connectivity requirements.
In the following table, a list of the possible constraints,
associated with their potential cardinality, is reported.
The maximum number of potential connections to be computed and
reported is, in first approximation, the multiplication of all of
them.
Busi, Belotti, et al. Expires May 13, 2018 [Page 12]
Internet-DraftYang model for requesting Path Computation November 2017
Constraint Cardinality
---------- -------------------------------------------------------
End points N(N-1)/2 if connections are bidirectional (OTN and WDM),
N(N-1) for unidirectional connections.
Bandwidth In WDM networks, bandwidth values are expressed in GHz.
On fixed-grid WDM networks, the central frequencies are
on a 50GHz grid and the channel width of the transmitters
are typically 50GHz such that each central frequency can
be used, i.e., adjacent channels can be placed next to
each other in terms of central frequencies.
On flex-grid WDM networks, the central frequencies are on
a 6.25GHz grid and the channel width of the transmitters
can be multiples of 12.5GHz.
For fixed-grid WDM networks typically there is only one
possible bandwidth value (i.e., 50GHz) while for flex-
grid WDM networks typically there are 4 possible
bandwidth values (e.g., 37.5GHz, 50GHz, 62.5GHz, 75GHz).
In OTN (ODU) networks, bandwidth values are expressed as
pairs of ODU type and, in case of ODUflex, ODU rate in
bytes/sec as described in section 5 of [RFC7139].
For "fixed" ODUk types, 6 possible bandwidth values are
possible (i.e., ODU0, ODU1, ODU2, ODU2e, ODU3, ODU4).
For ODUflex(GFP), up to 80 different bandwidth values can
be specified, as defined in Table 7-8 of [ITU-T G.709-
2016].
For other ODUflex types, like ODUflex(CBR), the number of
possible bandwidth values depends on the rates of the
clients that could be mapped over these ODUflex types, as
shown in Table 7.2 of [ITU-T G.709-2016], which in theory
could be a countinuum of values. However, since different
ODUflex bandwidths that use the same number of TSs on
each link along the path are equivalent for path
computation purposes, up to 120 different bandwidth
ranges can be specified.
Busi, Belotti, et al. Expires May 13, 2018 [Page 13]
Internet-DraftYang model for requesting Path Computation November 2017
Ideas to reduce the number of ODUflex bandwidth values in
the detailed connectivity matrix, to less than 100, are
for further study.
Bandwidth specification for ODUCn is currently for
further study but it is expected that other bandwidth
values can be specified as integer multiples of 100Gb/s.
In IP we have bandwidth values in bytes/sec. In
principle, this is a countinuum of values, but in
practice we can identify a set of bandwidth ranges, where
any bandwidth value inside the same range produces the
same path.
The number of such ranges is the cardinality, which
depends on the topology, available bandwidth and status
of the network. Simulations (Note: reference paper
submitted for publication) show that values for medium
size topologies (around 50-150 nodes) are in the range 4-
7 (5 on average) for each end points couple.
Metrics IGP, TE and hop number are the basic objective metrics
defined so far. There are also the 2 objective functions
defined in [RFC5541]: Minimum Load Path (MLP) and Maximum
Residual Bandwidth Path (MBP). Assuming that one only
metric or objective function can be optimized at once,
the total cardinality here is 5.
With [PCEP-Service-Aware], a number of additional metrics
are defined, including Path Delay metric, Path Delay
Variation metric and Path Loss metric, both for point-to-
point and point-to-multipoint paths. This increases the
cardinality to 8.
Bounds Each metric can be associated with a bound in order to
find a path having a total value of that metric lower
than the given bound. This has a potentially very high
cardinality (as any value for the bound is allowed). In
practice there is a maximum value of the bound (the one
with the maximum value of the associated metric) which
results always in the same path, and a range approach
like for bandwidth in IP should produce also in this case
the cardinality. Assuming to have a cardinality similar
to the one of the bandwidth (let say 5 on average) we
should have 6 (IGP, TE, hop, path delay, path delay
variation and path loss; we don't consider here the two
Busi, Belotti, et al. Expires May 13, 2018 [Page 14]
Internet-DraftYang model for requesting Path Computation November 2017
objective functions of [RFC5541] as they are conceived
only for optimization)*5 = 30 cardinality.
Priority We have 8 values for setup priority, which is used in
path computation to route a path using free resources
and, where no free resources are available, resources
used by LSPs having a lower holding priority.
Local prot It's possible to ask for a local protected service, where
all the links used by the path are protected with fast
reroute (this is only for IP networks, but line
protection schemas are available on the other
technologies as well). This adds an alternative path
computation, so the cardinality of this constraint is 2.
Administrative
Colors Administrative colors (aka affinities) are typically
assigned to links but when topology abstraction is used
affinity information can also appear in the detailed
connectivity matrix.
There are 32 bits available for the affinities. Links can
be tagged with any combination of these bits, and path
computation can be constrained to include or exclude any
or all of them. The relevant cardinality is 3 (include-
any, exclude-any, include-all) times 2^32 possible
values. However, the number of possible values used in
real networks is quite small.
Included Resources
A path computation request can be associated to an
ordered set of network resources (links, nodes) to be
included along the computed path. This constraint would
have a huge cardinality as in principle any combination
of network resources is possible. However, as far as the
Orchestrator doesn't know details about the internal
topology of the domain, it shouldn't include this type of
constraint at all (see more details below).
Excluded Resources
A path computation request can be associated to a set of
network resources (links, nodes, SRLGs) to be excluded
from the computed path. Like for included resources,
Busi, Belotti, et al. Expires May 13, 2018 [Page 15]
Internet-DraftYang model for requesting Path Computation November 2017
this constraint has a potentially very high cardinality,
but, once again, it can't be actually used by the
Orchestrator, if it's not aware of the domain topology
(see more details below).
As discussed above, the Orchestrator can specify include or exclude
resources depending on the abstract topology information that the
domain controller exposes:
o In case the domain controller exposes the entire domain as a
single abstract TE node with his own external terminations and
connectivity matrix (whose size we are estimating), no other
topological details are available, therefore the size of the
connectivity matrix only depends on the combination of the
constraints that the Orchestrator can use in a path computation
request to the domain controller. These constraints cannot refer
to any details of the internal topology of the domain, as those
details are not known to the Orchestrator and so they do not
impact size of connectivity matrix exported.
o Instead in case the domain controller exposes a topology
including more than one abstract TE nodes and TE links, and their
attributes (e.g. SRLGs, affinities for the links), the
Orchestrator knows these details and therefore could compute a
path across the domain referring to them in the constraints. The
connectivity matrixes to be estimated here are the ones relevant
to the abstract TE nodes exported to the Orchestrator. These
connectivity matrixes and therefore theirs sizes, while cannot
depend on the other abstract TE nodes and TE links, which are
external to the given abstract node, could depend to SRLGs (and
other attributes, like affinities) which could be present also in
the portion of the topology represented by the abstract nodes,
and therefore contribute to the size of the related connectivity
matrix.
We also don't consider here the possibility to ask for more than one
path in diversity or for point-to-multi-point paths, which are for
further study.
Considering for example an IP domain without considering SRLG and
affinities, we have an estimated number of paths depending on these
estimated cardinalities:
Endpoints = N*(N-1), Bandwidth = 5, Metrics = 6, Bounds = 20,
Priority = 8, Local prot = 2
Busi, Belotti, et al. Expires May 13, 2018 [Page 16]
Internet-DraftYang model for requesting Path Computation November 2017
The number of paths to be pre-computed by each IP domain is
therefore 24960 * N(N-1) where N is the number of domain access
points.
This means that with just 4 access points we have nearly 300000
paths to compute, advertise and maintain (if a change happens in the
domain, due to a fault, or just the deployment of new traffic, a
substantial number of paths need to be recomputed and the relevant
changes advertised to the upper controller).
This seems quite challenging. In fact, if we assume a mean length of
1K for the json describing a path (a quite conservative estimate),
reporting 300000 paths means transferring and then parsing more than
300 Mbytes for each domain. If we assume that 20% (to be checked) of
this paths change when a new deployment of traffic occurs, we have
60 Mbytes of transfer for each domain traversed by a new end-to-end
path. If a network has, let say, 20 domains (we want to estimate the
load for a non-trivial domain setup) in the beginning a total
initial transfer of 6Gigs is needed, and eventually, assuming 4-5
domains are involved in mean during a path deployment we could have
240-300 Mbytes of changes advertised to the higher order controller.
Further bare-bone solutions can be investigated, removing some more
options, if this is considered not acceptable; in conclusion, it
seems that an approach based only on connectivity matrix is hardly
feasible, and could be applicable only to small networks with a
limited meshing degree between domains and renouncing to a number of
path computation features.
It is also worth noting that the "connectivity matrix" has been
originally defined in WSON, [RFC7446] to report the connectivity
constrains of a physical node within the WDM network: the
information it contains is pretty "static" and therefore, once taken
and stored in the TE data base, it can be always being considered
valid and up-to-date in path computation request.
Using the "connectivity matrix" with an abstract node to abstract
the information regarding the connectivity constraints of an Optical
domain, would make this information more "dynamic" since the
connectivity constraints of an Optical domain can change over time
because some optical paths that are feasible at a given time may
become unfeasible at a later time when e.g., another optical path is
established. The information in the "detailed abstract connectivity
matrix" is even more dynamic since the establishment of another
optical path may change some of the parameters (e.g., delay or
Busi, Belotti, et al. Expires May 13, 2018 [Page 17]
Internet-DraftYang model for requesting Path Computation November 2017
available bandwidth) in the "detailed abstract connectivity matrix"
while not changing the feasibility of the path.
"Connectivity matrix" is sometimes confused with optical reach table
that contain multiple (e.g. k-shortest) regen-free reachable paths
for every A-Z node combination in the network. Optical reach tables
can be calculated offline, utilizing vendor optical design and
planning tools,and periodically uploaded to the Controller: these
optical path reach tables are fairly static. However, to get the
connectivity matrix, between any two sites, either a regen free path
can be used, if one is available, or multiple regen free paths are
concatenated to get from src to dest, which can be a very large
combination. Additionally, when the optical path within optical
domain needs to be computed, it can result in different paths based
on input objective, constraints, and network conditions. In summary,
even though "optical reachability table" is fairly static, which
regen free paths to build the connectivity matrix between any source
and destination is very dynamic, and is done using very
sophisticated routing algorithms.
There is therefore the need to keep the information in the
"connectivity matrix" updated which means that there another
tradeoff between the accuracy (i.e., providing "all" the information
that might be needed by the Orchestrator's PCE) and having up-to-
date information. The more the information is provided and the
longer it takes to keep it up-to-date which increases the likelihood
that the Orchestrator's PCE computes paths using not updated
information.
It seems therefore quite challenging to have a "detailed abstract
connectivity matrix" that provides accurate, scalable and updated
information to allow the Orchestrator's PCE to take optimal
decisions by its own.
If the information in the "detailed abstract connectivity matrix" is
not complete/accurate, we can have the following drawbacks
considering for example the case in Figure 6:
o If only the VP1-VP4 path with available bandwidth of 2 Gb/s and
cost 50 is reported, the Orchestrator's PCE will fail to compute
a 5 Gb/s path between routers R1 and R2, although this would be
feasible;
Busi, Belotti, et al. Expires May 13, 2018 [Page 18]
Internet-DraftYang model for requesting Path Computation November 2017
o If only the VP1-VP4 path with available bandwidth of 10 Gb/s and
cost 60 is reported, the Orchestrator's PCE will compute, as
optimal, the 1 Gb/s path between R1 and R2 going through the VP2-
VP5 path within the Optical domain while the optimal path would
actually be the one going thought the VP1-VP4 sub-path (with cost
50) within the Optical domain.
Instead, using the approach proposed in this document, the
Orchestrator, when it needs to setup an end-to-end path, it can
request the Optical domain controller to compute a set of optimal
paths (e.g., for VP1-VP4 and VP2-VP5) and take decisions based on
the information received:
o When setting up a 5 Gb/s path between routers R1 and R2, the
Optical domain controller may report only the VP1-VP4 path as the
only feasible path: the Orchestrator can successfully setup the
end-to-end path passing though this Optical path;
o When setting up a 1 Gb/s path between routers R1 and R2, the
Optical domain controller (knowing that the path requires only 1
Gb/s) can report both the VP1-VP4 path, with cost 50, and the
VP2-VP5 path, with cost 65. The Orchestrator can then compute the
optimal path which is passing thought the VP1-VP4 sub-path (with
cost 50) within the Optical domain.
3.2. TE Topology Abstraction
Using the TE Topology model, as defined in [TE-TOPO], the underlying
SDN controller can export an abstract TE Topology, composed by a set
of TE nodes and TE links, which are abstracting the topology
controlled by each domain controller.
Considering the example in Figure 4, the TE domain controller 1 can
export a TE Topology encompassing the TE nodes A, B, C and D and the
TE Link interconnecting them. In a similar way, TE domain controller
2 can export a TE Topology encompassing the TE nodes E, F, G and H
and the TE Link interconnecting them.
In this example, for simplicity reasons, each abstract TE node maps
with each physical node, but this is not necessary.
In order to setup a multi-domain TE path (e.g., between nodes A and
H), the Orchestrator can compute by its own an optimal end-to-end
path based on the abstract TE topology information provided by the
domain controllers. For example:
Busi, Belotti, et al. Expires May 13, 2018 [Page 19]
Internet-DraftYang model for requesting Path Computation November 2017
o Orchestrator's PCE, based on its own information, can compute the
optimal multi-domain path being A-B-C-E-G-H, and then request the
TE domain controllers to setup the A-B-C and E-G-H intra-domain
paths
o But, during path setup, the domain controller may find out that
A-B-C intra-domain path is not feasible (as discussed in section
2.2, in optical networks it is typical to have some paths not
being feasible due to optical constraints that are known only by
the optical domain controller), while only the path A-B-D is
feasible
o So what the hierarchical controller computed is not good and need
to re-start the path computation from scratch
As discussed in section 3.1, providing more extensive abstract
information from the TE domain controllers to the multi-domain
Orchestator may lead to scalability problems.
In a sense this is similar to the problem of routing and wavelength
assignment within an Optical domain. It is possible to do first
routing (step 1) and then wavelength assignment (step 2), but the
chances of ending up with a good path is low. Alternatively, it is
possible to do combined routing and wavelength assignment, which is
known to be a more optimal and effective way for Optical path setup.
Similarly, it is possible to first compute an abstract end-to-end
path within the multi-domain Orchestrator (step 1) and then compute
an intra-domain path within each Optical domain (step 2), but there
are more chances not to find a path or to get a suboptimal path that
performing per-domain path computation and then stitch them.
3.3. Complementary use of TE topology and path computation
As discussed in section 2.2, there are some scalability issues with
path computation requests in a multi-domain TE network with many TE
domains, in terms of the number of requests to send to the TE domain
controllers. It would therefore be worthwhile using the TE topology
information provided by the domain controllers to limit the number
of requests.
An example can be described considering the multi-domain abstract
topology shown in Figure 7. In this example, an end-to-end TE path
between domains A and F needs to be setup. The transit domain should
be selected between domains B, C, D and E.
Busi, Belotti, et al. Expires May 13, 2018 [Page 20]
Internet-DraftYang model for requesting Path Computation November 2017
--------------------------------------------------------------------
I I
I I
I I
I Multi-domain with many domains I
I (Topology information) I
I I
I I
I (only in PDF version) I
I I
I I
I I
--------------------------------------------------------------------
Figure 7 - Multi-domain with many domains (Topology information)
The actual cost of each intra-domain path is not known a priori from
the abstract topology information. The Orchestrator only knows, from
the TE topology provided by the underlying domain controllers, the
feasibility of some intra-domain paths and some upper-bound and/or
lower-bound cost information. With this information, together with
the cost of inter-domain links, the Orchestrator can understand by
its own that:
o Domain B cannot be selected as the path connecting domains A and
E is not feasible;
o Domain E cannot be selected as a transit domain since it is know
from the abstract topology information provided by domain
controllers that the cost of the multi-domain path A-E-F (which
is 100, in the best case) will be always be higher than the cost
of the multi-domain paths A-D-F (which is 90, in the worst case)
and A-E-F (which is 80, in the worst case)
Therefore, the Orchestrator can understand by its own that the
optimal multi-domain path could be either A-D-F or A-E-F but it
cannot known which one of the two possible option actually provides
the optimal end-to-end path.
The Orchestrator can therefore request path computation only to the
TE domain controllers A, D, E and F (and not to all the possible TE
domain controllers).
Busi, Belotti, et al. Expires May 13, 2018 [Page 21]
Internet-DraftYang model for requesting Path Computation November 2017
--------------------------------------------------------------------
I I
I I
I I
I Multi-domain with many domains I
I (Path Computation information) I
I I
I I
I I
I I
I (only in PDF version) I
I I
I I
I I
--------------------------------------------------------------------
Figure 8 - Multi-domain with many domains (Path Computation
information)
Based on these requests, the Orchestrator can know the actual cost
of each intra-domain paths which belongs to potential optimal end-
to-end paths, as shown in Figure 8, and then compute the optimal
end-to-end path (e.g., A-D-F, having total cost of 50, instead of A-
C-F having a total cost of 70).
4. Motivation for a YANG Model
4.1. Benefits of common data models
Path computation requests should be closely aligned with the YANG
data models that provide (abstract) TE topology information, i.e.,
[TE-TOPO] as well as that are used to configure and manage TE
Tunnels, i.e., [TE-TUNNEL]. Otherwise, an error-prone mapping or
correlation of information would be required. For instance, there is
benefit in using the same endpoint identifiers in path computation
requests and in the topology modeling. Also, the attributes used in
path computation constraints could use the same or similar data
models. As a result, there are many benefits in aligning path
computation requests with YANG models for TE topology information
and TE Tunnels configuration and management.
Busi, Belotti, et al. Expires May 13, 2018 [Page 22]
Internet-DraftYang model for requesting Path Computation November 2017
4.2. Benefits of a single interface
A typical use case for path computation requests is the interface
between an orchestrator and a domain controller. The system
integration effort is typically lower if a single, consistent
interface is used between such systems, i.e., one data modeling
language (i.e., YANG) and a common protocol (e.g., NETCONF or
RESTCONF).
Practical benefits of using a single, consistent interface include:
1. Simple authentication and authorization: The interface between
different components has to be secured. If different protocols
have different security mechanisms, ensuring a common access
control model may result in overhead. For instance, there may
be a need to deal with different security mechanisms, e.g.,
different credentials or keys. This can result in increased
integration effort.
2. Consistency: Keeping data consistent over multiple different
interfaces or protocols is not trivial. For instance, the
sequence of actions can matter in certain use cases, or
transaction semantics could be desired. While ensuring
consistency within one protocol can already be challenging, it
is typically cumbersome to achieve that across different
protocols.
3. Testing: System integration requires comprehensive testing,
including corner cases. The more different technologies are
involved, the more difficult it is to run comprehensive test
cases and ensure proper integration.
4. Middle-box friendliness: Provider and consumer of path
computation requests may be located in different networks, and
middle-boxes such as firewalls, NATs, or load balancers may be
deployed. In such environments it is simpler to deploy a single
protocol. Also, it may be easier to debug connectivity
problems.
5. Tooling reuse: Implementers may want to implement path
computation requests with tools and libraries that already
exist in controllers and/or orchestrators, e.g., leveraging the
rapidly growing eco-system for YANG tooling.
4.3. Extensibility
Path computation is only a subset of the typical functionality of a
controller. In many use cases, issuing path computation requests
comes along with the need to access other functionality on the same
Busi, Belotti, et al. Expires May 13, 2018 [Page 23]
Internet-DraftYang model for requesting Path Computation November 2017
system. In addition to obtaining TE topology, for instance also
configuration of services (setup/modification/deletion) may be
required, as well as:
1. Receiving notifications for topology changes as well as
integration with fault management
2. Performance management such as retrieving monitoring and
telemetry data
3. Service assurance, e.g., by triggering OAM functionality
4. Other fulfilment and provisioning actions beyond tunnels and
services, such as changing QoS configurations
YANG is a very extensible and flexible data modeling language that
can be used for all these use cases.
Adding support for path computation requests to YANG models would
seamlessly complement with [TE-TOPO] and [TE-TUNNEL] in the use
cases where YANG-based protocols (e.g., NETCONF or RESTCONF) are
used.
5. Path Computation for multiple LSPs
There are use cases, where path computation is required for multiple
Traffic Engineering Label Switched Paths (TE LSPs) through a network
or through a network domain. It may be advantageous to request the
new paths for a set of LSPs in one single path computation request
[RFC5440] that also includes information regarding the desired
objective function, see [RFC5541].
In the context of abstraction and control of TE networks (ACTN), as
defined in [ACTN-Frame], when a MDSC receives a vitual network (VN)
request from a CNC, the MDSC needs to perform path computation for
multiple LSPs as a typical VN is constructed by a set of multiple
paths also called end-to-end tunnels. The MDSC may send a single
path computation request to the PNC for multiple LSPs, i.e. between
the VN end points (access points in ACTN terminology).
In a more general context, when a MDSC needs to send multiple path
provisioning requests to the PNC, the MDSC may also group these path
provisioning requests together and send them in a single message to
the PNC instead of sending separet requests for each path.
Busi, Belotti, et al. Expires May 13, 2018 [Page 24]
Internet-DraftYang model for requesting Path Computation November 2017
6. YANG Model for requesting Path Computation
The TE Tunnel YANG model has been extended to support the need to
request path computation.
It is possible to request path computation by configuring a
"compute-only" TE tunnel and retrieving the computed path(s) in the
LSP(s) Record-Route Object (RRO) list as described in section 3.3.1
of [TE-TUNNEL].
This is a stateful solution since the state of each created
"compute-only" TE tunnel needs to be maintained and updated, when
underlying network conditions change.
The need also for a stateless solution, based on an RPC, has been
recognized, as outlined in section 6.1.
A proposal for a stateless RPC to request path computation is
provided in section 6.2.
6.1. Stateless and Stateful Path Computation
It is very useful to provide options for both stateless and stateful
path computation mechanisms. It is suggested to use stateless
mechanisms as much as possible and to rely on stateful path
computation when really needed.
Stateless RPC allows requesting path computation using a simple
atomic operation and it is the natural option/choice, especially
with stateless PCE.
Since the operation is stateless, there is no guarantee that the
returned path would still be available when path setup is requested:
this is not a major issue in case the time between path computation
and path setup is short.
The RPC response must be provided synchronously and, if
collaborative computations are time consuming, it may not be
possible to immediate reply to client.
In this case, the client can define a maximum time it can wait for
the reply, such that if the computation does not complete in time,
the server will abort the path computation and reply to the client
with an error. It may be possible that the server has tighter timing
Busi, Belotti, et al. Expires May 13, 2018 [Page 25]
Internet-DraftYang model for requesting Path Computation November 2017
constraints than the client: in this case the path computation is
aborted earlier than the time specified by the client.
Note - The RPC response issue (slow RPC server) is not specific to
the path computation RPC case so, it may be worthwhile, evaluating
whether a more generic solution applicable to any YANG RPC can be
used instead.
In case the stateless solution is not sufficient, a stateful
solution, based on "compute-only" TE tunnel, could be used to
support asynchronous operations and/or to get notifications in case
the computed path has been changed.
It is worth noting that also the stateful solution, although
increasing the likelihood that the computed path is available at
path setup, it does not guaranteed that because notifications may
not be reliable or delivered on time.
The stateful path computation has also the following drawbacks:
o Several messages required for any path computation
o Requires persistent storage in the provider controller
o Need for garbage collection for stranded paths
o Process burden to detect changes on the computed paths in order
to provide notifications update
6.2. YANG model for stateless TE path computation
6.2.1. YANG Tree
Figure 9 below shows the tree diagram of the YANG model defined in
module ietf-te-path-computation.yang.
module: ietf-te-path-computation
+--rw paths
| +--ro path* [path-id]
| +--ro _telink* [link-ref]
| | +--ro link-ref ->
/nd:networks/network[nd:network-id=current()/../network-
ref]/lnk:link/link-id
Busi, Belotti, et al. Expires May 13, 2018 [Page 26]
Internet-DraftYang model for requesting Path Computation November 2017
| | +--ro network-ref? -> /nd:networks/network/network-id
| +--ro path-constraints
| | +--ro path-metric-bound* [metric-type]
| | | +--ro metric-type identityref
| | | +--ro upper-bound? uint64
| | +--ro topology-id? te-types:te-topology-id
| | +--ro ignore-overload? boolean
| | +--ro bandwidth-generic
| | | +--ro te-bandwidth
| | | +--ro (technology)?
| | | +--:(psc)
| | | | +--ro psc? rt-types:bandwidth-ieee-
float32
| | | +--:(otn)
| | | | +--ro otn* [rate-type]
| | | | +--ro rate-type identityref
| | | | +--ro counter? uint16
| | | +--:(lsc)
| | | | +--ro wdm* [spectrum slot]
| | | | +--ro spectrum identityref
| | | | +--ro slot int16
| | | | +--ro width? uint16
| | | +--:(generic)
| | | +--ro generic? te-bandwidth
| | +--ro disjointness? te-types:te-path-
disjointness
| | +--ro setup-priority? uint8
| | +--ro hold-priority? uint8
| | +--ro signaling-type? identityref
| | +--ro path-affinities
| | | +--ro constraint* [usage]
| | | +--ro usage identityref
| | | +--ro value? admin-groups
| | +--ro path-srlgs
| | +--ro usage? identityref
| | +--ro values* srlg
| +--ro path-id yang-types:uuid
+--ro pathComputationService
+--ro _path-ref* -> /paths/path/path-id
Busi, Belotti, et al. Expires May 13, 2018 [Page 27]
Internet-DraftYang model for requesting Path Computation November 2017
+--ro _servicePort
| +--ro source? inet:ip-address
| +--ro destination? inet:ip-address
| +--ro src-tp-id? binary
| +--ro dst-tp-id? binary
| +--ro bidirectional
| +--ro association
| +--ro id? uint16
| +--ro source? inet:ip-address
| +--ro global-source? inet:ip-address
| +--ro type? identityref
| +--ro provisioing? identityref
+--ro path-constraints
| +--ro path-metric-bound* [metric-type]
| | +--ro metric-type identityref
| | +--ro upper-bound? uint64
| +--ro topology-id? te-types:te-topology-id
| +--ro ignore-overload? boolean
| +--ro bandwidth-generic
| | +--ro te-bandwidth
| | +--ro (technology)?
| | +--:(psc)
| | | +--ro psc? rt-types:bandwidth-ieee-
float32
| | +--:(otn)
| | | +--ro otn* [rate-type]
| | | +--ro rate-type identityref
| | | +--ro counter? uint16
| | +--:(lsc)
| | | +--ro wdm* [spectrum slot]
| | | +--ro spectrum identityref
| | | +--ro slot int16
| | | +--ro width? uint16
| | +--:(generic)
| | +--ro generic? te-bandwidth
| +--ro disjointness? te-types:te-path-disjointness
| +--ro setup-priority? uint8
| +--ro hold-priority? uint8
| +--ro signaling-type? identityref
Busi, Belotti, et al. Expires May 13, 2018 [Page 28]
Internet-DraftYang model for requesting Path Computation November 2017
| +--ro path-affinities
| | +--ro constraint* [usage]
| | +--ro usage identityref
| | +--ro value? admin-groups
| +--ro path-srlgs
| +--ro usage? identityref
| +--ro values* srlg
+--ro optimizations
+--ro (algorithm)?
+--:(metric) {path-optimization-metric}?
| +--ro optimization-metric* [metric-type]
| | +--ro metric-type identityref
| | +--ro weight? uint8
| +--ro tiebreakers
| +--ro tiebreaker* [tiebreaker-type]
| +--ro tiebreaker-type identityref
+--:(objective-function) {path-optimization-objective-
function}?
+--ro objective-function
+--ro objective-function-type? identityref
augment /te:tunnels-rpc/te:input/te:tunnel-info:
+---- request-list* [request-id-number]
| +---- request-id-number uint32
| +---- servicePort*
| | +---- source? inet:ip-address
| | +---- destination? inet:ip-address
| | +---- src-tp-id? binary
| | +---- dst-tp-id? binary
| | +---- bidirectional
| | +---- association
| | +---- id? uint16
| | +---- source? inet:ip-address
| | +---- global-source? inet:ip-address
| | +---- type? identityref
| | +---- provisioing? identityref
| +---- path-constraints
| | +---- path-metric-bound* [metric-type]
| | | +---- metric-type identityref
| | | +---- upper-bound? uint64
Busi, Belotti, et al. Expires May 13, 2018 [Page 29]
Internet-DraftYang model for requesting Path Computation November 2017
| | +---- topology-id? te-types:te-topology-id
| | +---- ignore-overload? boolean
| | +---- bandwidth-generic
| | | +---- te-bandwidth
| | | +---- (technology)?
| | | +--:(psc)
| | | | +---- psc? rt-types:bandwidth-ieee-
float32
| | | +--:(otn)
| | | | +---- otn* [rate-type]
| | | | +---- rate-type identityref
| | | | +---- counter? uint16
| | | +--:(lsc)
| | | | +---- wdm* [spectrum slot]
| | | | +---- spectrum identityref
| | | | +---- slot int16
| | | | +---- width? uint16
| | | +--:(generic)
| | | +---- generic? te-bandwidth
| | +---- disjointness? te-types:te-path-disjointness
| | +---- setup-priority? uint8
| | +---- hold-priority? uint8
| | +---- signaling-type? identityref
| | +---- path-affinities
| | | +---- constraint* [usage]
| | | +---- usage identityref
| | | +---- value? admin-groups
| | +---- path-srlgs
| | +---- usage? identityref
| | +---- values* srlg
| +---- optimizations
| +---- (algorithm)?
| +--:(metric) {path-optimization-metric}?
| | +---- optimization-metric* [metric-type]
| | | +---- metric-type identityref
| | | +---- weight? uint8
| | +---- tiebreakers
| | +---- tiebreaker* [tiebreaker-type]
| | +---- tiebreaker-type identityref
Busi, Belotti, et al. Expires May 13, 2018 [Page 30]
Internet-DraftYang model for requesting Path Computation November 2017
| +--:(objective-function) {path-optimization-objective-
function}?
| +---- objective-function
| +---- objective-function-type? identityref
+---- synchronization* [synchronization-index]
+---- synchronization-index uint32
+---- svec
| +---- relaxable? boolean
| +---- link-diverse? boolean
| +---- node-diverse? boolean
| +---- srlg-diverse? boolean
| +---- request-id-number* uint32
+---- path-constraints
+---- path-metric-bound* [metric-type]
| +---- metric-type identityref
| +---- upper-bound? uint64
+---- topology-id? te-types:te-topology-id
+---- ignore-overload? boolean
+---- bandwidth-generic
| +---- te-bandwidth
| +---- (technology)?
| +--:(psc)
| | +---- psc? rt-types:bandwidth-ieee-
float32
| +--:(otn)
| | +---- otn* [rate-type]
| | +---- rate-type identityref
| | +---- counter? uint16
| +--:(lsc)
| | +---- wdm* [spectrum slot]
| | +---- spectrum identityref
| | +---- slot int16
| | +---- width? uint16
| +--:(generic)
| +---- generic? te-bandwidth
+---- disjointness? te-types:te-path-disjointness
+---- setup-priority? uint8
+---- hold-priority? uint8
+---- signaling-type? identityref
Busi, Belotti, et al. Expires May 13, 2018 [Page 31]
Internet-DraftYang model for requesting Path Computation November 2017
+---- path-affinities
| +---- constraint* [usage]
| +---- usage identityref
| +---- value? admin-groups
+---- path-srlgs
+---- usage? identityref
+---- values* srlg
augment /te:tunnels-rpc/te:output/te:result:
+--ro response* [response-index]
+--ro response-index uint32
+--ro (response-type)?
+--:(no-path-case)
| +--ro no-path
+--:(path-case)
+--ro pathCompService
+--ro _path-ref* -> /paths/path/path-id
+--ro _servicePort
| +--ro source? inet:ip-address
| +--ro destination? inet:ip-address
| +--ro src-tp-id? binary
| +--ro dst-tp-id? binary
| +--ro bidirectional
| +--ro association
| +--ro id? uint16
| +--ro source? inet:ip-address
| +--ro global-source? inet:ip-address
| +--ro type? identityref
| +--ro provisioing? identityref
+--ro path-constraints
| +--ro path-metric-bound* [metric-type]
| | +--ro metric-type identityref
| | +--ro upper-bound? uint64
| +--ro topology-id? te-types:te-topology-
id
| +--ro ignore-overload? boolean
| +--ro bandwidth-generic
| | +--ro te-bandwidth
| | +--ro (technology)?
| | +--:(psc)
Busi, Belotti, et al. Expires May 13, 2018 [Page 32]
Internet-DraftYang model for requesting Path Computation November 2017
| | | +--ro psc? rt-types:bandwidth-
ieee-float32
| | +--:(otn)
| | | +--ro otn* [rate-type]
| | | +--ro rate-type identityref
| | | +--ro counter? uint16
| | +--:(lsc)
| | | +--ro wdm* [spectrum slot]
| | | +--ro spectrum identityref
| | | +--ro slot int16
| | | +--ro width? uint16
| | +--:(generic)
| | +--ro generic? te-bandwidth
| +--ro disjointness? te-types:te-path-
disjointness
| +--ro setup-priority? uint8
| +--ro hold-priority? uint8
| +--ro signaling-type? identityref
| +--ro path-affinities
| | +--ro constraint* [usage]
| | +--ro usage identityref
| | +--ro value? admin-groups
| +--ro path-srlgs
| +--ro usage? identityref
| +--ro values* srlg
+--ro optimizations
+--ro (algorithm)?
+--:(metric) {path-optimization-metric}?
| +--ro optimization-metric* [metric-type]
| | +--ro metric-type identityref
| | +--ro weight? uint8
| +--ro tiebreakers
| +--ro tiebreaker* [tiebreaker-type]
| +--ro tiebreaker-type identityref
+--:(objective-function) {path-optimization-
objective-function}?
+--ro objective-function
+--ro objective-function-type?
identityref
Busi, Belotti, et al. Expires May 13, 2018 [Page 33]
Internet-DraftYang model for requesting Path Computation November 2017
Figure 9 - TE path computation tree
6.2.2. YANG Module
<CODE BEGINS>file " ietf-te-path-computation.yang "
module ietf-te-path-computation {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-te-path-computation";
// replace with IANA namespace when assigned
prefix "tepc";
import ietf-inet-types {
prefix "inet";
}
import ietf-yang-types {
prefix "yang-types";
}
import ietf-network-topology {
prefix "nt";
}
import ietf-te {
prefix "te";
}
import ietf-te-types {
prefix "te-types";
}
organization
"Traffic Engineering Architecture and Signaling (TEAS)
Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/teas/>
WG List: <mailto:teas@ietf.org>
Busi, Belotti, et al. Expires May 13, 2018 [Page 34]
Internet-DraftYang model for requesting Path Computation November 2017
WG Chair: Lou Berger
<mailto:lberger@labn.net>
WG Chair: Vishnu Pavan Beeram
<mailto:vbeeram@juniper.net>
";
description "YANG model for stateless TE path computation";
revision "2016-10-10" {
description "Initial revision";
reference "YANG model for stateless TE path computation";
}
/*
* Features
*/
feature stateless-path-computation {
description
"This feature indicates that the system supports
stateless path computation.";
}
/*
* Groupings
*/
grouping Path {
list _telink {
key 'link-ref';
config false;
uses nt:link-ref;
description "List of telink refs.";
}
uses te-types:generic-path-constraints;
Busi, Belotti, et al. Expires May 13, 2018 [Page 35]
Internet-DraftYang model for requesting Path Computation November 2017
leaf path-id {
type yang-types:uuid;
config false;
description "path-id ref.";
}
description "Path is described by an ordered list of TE Links.";
}
grouping PathCompServicePort {
leaf source {
type inet:ip-address;
description "TE tunnel source address.";
}
leaf destination {
type inet:ip-address;
description "P2P tunnel destination address";
}
leaf src-tp-id {
type binary;
description "TE tunnel source termination point identifier.";
}
leaf dst-tp-id {
type binary;
description "TE tunnel destination termination point
identifier.";
}
uses te:bidir-assoc-properties;
description "Path Computation Service Port grouping.";
}
grouping PathComputationService {
leaf-list _path-ref {
type leafref {
path '/paths/path/path-id';
}
config false;
description "List of previously computed path references.";
}
Busi, Belotti, et al. Expires May 13, 2018 [Page 36]
Internet-DraftYang model for requesting Path Computation November 2017
container _servicePort {
uses PathCompServicePort;
description "Path Computation Service Port.";
}
uses te-types:generic-path-constraints;
uses te-types:generic-path-optimization;
description "Path computation service.";
}
grouping synchronization-info {
description "Information for sync";
list synchronization {
key "synchronization-index";
description "sync list";
leaf synchronization-index {
type uint32;
description "index";
}
container svec {
description
"Synchronization VECtor";
leaf relaxable {
type boolean;
default true;
description
"If this leaf is true, path computation process is free
to ignore svec content.
otherwise it must take into account this svec.";
}
leaf link-diverse {
type boolean;
default false;
description "link-diverse";
}
leaf node-diverse {
Busi, Belotti, et al. Expires May 13, 2018 [Page 37]
Internet-DraftYang model for requesting Path Computation November 2017
type boolean;
default false;
description "node-diverse";
}
leaf srlg-diverse {
type boolean;
default false;
description "srlg-diverse";
}
leaf-list request-id-number {
type uint32;
description
"This list reports the set of M path computation requests
that must be synchronized.";
}
}
uses te-types:generic-path-constraints;
}
}
grouping no-path-info {
description "no-path-info";
container no-path {
description "no-path container";
}
}
/*
* Root container
*/
container paths {
list path {
key "path-id";
config false;
uses Path;
description "List of previous computed paths.";
}
description "Root container for path-computation";
Busi, Belotti, et al. Expires May 13, 2018 [Page 38]
Internet-DraftYang model for requesting Path Computation November 2017
}
container pathComputationService {
config false;
uses PathComputationService;
description "Service for computing paths.";
}
/**
* AUGMENTS TO TE RPC
*/
augment "/te:tunnels-rpc/te:input/te:tunnel-info" {
description "statelessComputeP2PPath input";
list request-list {
key "request-id-number";
description "request-list";
leaf request-id-number {
type uint32;
mandatory true;
description "Each path computation request is uniquely
identified by the request-id-number.
It must be present also in rpcs.";
}
list servicePort {
min-elements 1;
uses PathCompServicePort;
description "List of service ports.";
}
uses te-types:generic-path-constraints;
uses te-types:generic-path-optimization;
}
uses synchronization-info;
}
augment "/te:tunnels-rpc/te:output/te:result" {
Busi, Belotti, et al. Expires May 13, 2018 [Page 39]
Internet-DraftYang model for requesting Path Computation November 2017
description "statelessComputeP2PPath output";
list response {
key response-index;
config false;
description "response";
leaf response-index {
type uint32;
description
"The list key that has to reuse request-id-number.";
}
choice response-type {
config false;
description "response-type";
case no-path-case {
uses no-path-info;
}
case path-case {
container pathCompService {
uses PathComputationService;
description "Path computation service.";
}
}
}
}
}
}
<CODE ENDS>
Figure 10 - TE path computation YANG module
7. Security Considerations
This document describes use cases of requesting Path Computation
using YANG models, which could be used at the ABNO Control Interface
[RFC7491] and/or between controllers in ACTN [ACTN-frame]. As such,
it does not introduce any new security considerations compared to
the ones related to YANG specification, ABNO specification and ACTN
Framework defined in [RFC6020], [RFC7950], [RFC7491] and [ACTN-
frame].
Busi, Belotti, et al. Expires May 13, 2018 [Page 40]
Internet-DraftYang model for requesting Path Computation November 2017
This document also defines common data types using the YANG data
modeling language. The definitions themselves have no security
impact on the Internet, but the usage of these definitions in
concrete YANG modules might have. The security considerations
spelled out in the YANG specification [RFC6020] apply for this
document as well.
8. IANA Considerations
This section is for further study: to be completed when the YANG
model is more stable.
9. References
9.1. Normative References
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[RFC7139] Zhang, F. et al., "GMPLS Signaling Extensions for Control
of Evolving G.709 Optical Transport Networks", RFC 7139,
March 2014.
[RFC7491] Farrel, A., King, D., "A PCE-Based Architecture for
Application-Based Network Operations", RFC 7491, March 2015.
[RFC7926] Farrel, A. et al., "Problem Statement and Architecture for
Information Exchange Between Interconnected Traffic
Engineered Networks", RFC 7926, July 2016.
[RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", RFC
7950, August 2016.
[TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies",
draft-ietf-teas-yang-te-topo, work in progress.
[TE-TUNNEL] Saad, T. et al., "A YANG Data Model for Traffic
Engineering Tunnels and Interfaces", draft-ietf-teas-yang-
te, work in progress.
[ACTN-Frame] Ceccarelli, D., Lee, Y. et al., "Framework for
Abstraction and Control of Traffic Engineered Networks"
draft-ietf-actn-framework, work in progress.
Busi, Belotti, et al. Expires May 13, 2018 [Page 41]
Internet-DraftYang model for requesting Path Computation November 2017
[ITU-T G.709-2016] ITU-T Recommendation G.709 (06/16), "Interface
for the optical transport network", June 2016
9.2. Informative References
[RFC5541] Le Roux, JL. et al., " Encoding of Objective Functions in
the Path Computation Element Communication Protocol
(PCEP)", RFC 5541, June 2009.
[RFC7446] Lee, Y. et al., "Routing and Wavelength Assignment
Information Model for Wavelength Switched Optical
Networks", RFC 7446, February 2015.
[OTN-TOPO] Zheng, H. et al., "A YANG Data Model for Optical
Transport Network Topology", draft-ietf-ccamp-otn-topo-
yang, work in progress.
[ACTN-Info] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D.,
"Information Model for Abstraction and Control of
Transport Networks", draft-leebelotti-actn-info, work in
progress.
[PCEP-Service-Aware] Dhody, D. et al., " Extensions to the Path
Computation Element Communication Protocol (PCEP) to
compute service aware Label Switched Path (LSP)", draft-
ietf-pce-pcep-service-aware, work in progress.
10. Acknowledgments
The authors would like to thank Igor Bryskin and Xian Zhang for
participating in discussions and providing valuable insights.
The authors would like to thank the authors of the TE Tunnel YANG
model [TE-TUNNEL], in particular Igor Bryskin, Vishnu Pavan Beeram,
Tarek Saad and Xufeng Liu, for their inputs to the discussions and
support in having consistency between the Path Computation and TE
Tunnel YANG models.
This document was prepared using 2-Word-v2.0.template.dot.
Busi, Belotti, et al. Expires May 13, 2018 [Page 42]
Internet-DraftYang model for requesting Path Computation November 2017
Contributors
Dieter Beller
Nokia
Email: dieter.beller@nokia.com
Gianmarco Bruno
Ericsson
Email: gianmarco.bruno@ericsson.com
Francesco Lazzeri
Ericsson
Email: francesco.lazzeri@ericsson.com
Young Lee
Huawei
Email: leeyoung@huawei.com
Carlo Perocchio
Ericsson
Email: carlo.perocchio@ericsson.com
Authors' Addresses
Italo Busi (Editor)
Huawei
Email: italo.busi@huawei.com
Sergio Belotti (Editor)
Nokia
Email: sergio.belotti@nokia.com
Victor Lopez
Telefonica
Email: victor.lopezalvarez@telefonica.com
Busi, Belotti, et al. Expires May 13, 2018 [Page 43]
Internet-DraftYang model for requesting Path Computation November 2017
Oscar Gonzalez de Dios
Telefonica
Email: oscar.gonzalezdedios@telefonica.com
Anurag Sharma
Infinera
Email: AnSharma@infinera.com
Yan Shi
China Unicom
Email: shiyan49@chinaunicom.cn
Ricard Vilalta
CTTC
Email: ricard.vilalta@cttc.es
Karthik Sethuraman
NEC
Email: karthik.sethuraman@necam.com
Michael Scharf
Nokia
Email: michael.scharf@nokia.com
Daniele Ceccarelli
Ericsson
Email: daniele.ceccarelli@ericsson.com
Busi, Belotti, et al. Expires May 13, 2018 [Page 44]