```
file "ietf-te-path-computation@2018-03-02.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-te {
prefix "te";
}
import ietf-te-types {
prefix "te-types";
}
Busi, Belotti, et al. Expires September 5, 2018 [Page 35]
Internet-DraftYang model for requesting Path Computation March 2018
organization
"Traffic Engineering Architecture and Signaling (TEAS)
Working Group";
contact
"WG Web:
```
WG List:
WG Chair: Lou Berger
WG Chair: Vishnu Pavan Beeram
";
description "YANG model for stateless TE path computation";
revision "2018-03-02" {
description "Revision to fix issues #22, 29, 33 and 39";
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-info {
Busi, Belotti, et al. Expires September 5, 2018 [Page 36]
Internet-DraftYang model for requesting Path Computation March 2018
leaf path-id {
type yang-types:uuid;
config false;
description "path-id ref.";
}
uses te-types:generic-path-properties;
description "Path computation output information";
}
grouping end-points {
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.";
}
description "Path Computation End Points grouping.";
}
grouping requested-metrics-info {
description "requested metric";
list requested-metrics {
key 'metric-type';
description "list of requested metrics";
leaf metric-type {
type identityref {
base te-types:path-metric-type;
}
Busi, Belotti, et al. Expires September 5, 2018 [Page 37]
Internet-DraftYang model for requesting Path Computation March 2018
description "the requested metric";
}
}
}
identity svec-metric-type {
description
"Base identity for svec metric type";
}
identity svec-metric-cumul-te {
base svec-metric-type;
description
"TE cumulative path metric";
}
identity svec-metric-cumul-igp {
base svec-metric-type;
description
"IGP cumulative path metric";
}
identity svec-metric-cumul-hop {
base svec-metric-type;
description
"Hop cumulative path metric";
}
identity svec-metric-aggregate-bandwidth-consumption {
base svec-metric-type;
description
"Cumulative bandwith consumption of the set of synchronized
paths";
}
identity svec-metric-load-of-the-most-loaded-link {
base svec-metric-type;
description
"Load of the most loaded link";
Busi, Belotti, et al. Expires September 5, 2018 [Page 38]
Internet-DraftYang model for requesting Path Computation March 2018
}
grouping svec-metrics-bounds_config {
description "TE path metric bounds grouping for computing a set
of
synchronized requests";
leaf metric-type {
type identityref {
base svec-metric-type;
}
description "TE path metric type usable for computing a set of
synchronized requests";
}
leaf upper-bound {
type uint64;
description "Upper bound on end-to-end svec path metric";
}
}
grouping svec-metrics-optimization_config {
description "TE path metric bounds grouping for computing a set
of
synchronized requests";
leaf metric-type {
type identityref {
base svec-metric-type;
}
description "TE path metric type usable for computing a set of
synchronized requests";
}
leaf weight {
type uint8;
description "Metric normalization weight";
}
}
grouping svec-exclude {
description "List of resources to be excluded by all the paths
in the SVEC";
Busi, Belotti, et al. Expires September 5, 2018 [Page 39]
Internet-DraftYang model for requesting Path Computation March 2018
container exclude-objects {
description "resources to be excluded";
list excludes {
key index;
description
"List of explicit route objects to always exclude
from synchronized path computation";
uses te-types:explicit-route-hop;
}
}
}
grouping synchronization-constraints {
description "Global constraints applicable to synchronized
path computation";
container svec-constraints {
description "global svec constraints";
list path-metric-bound {
key metric-type;
description "list of bound metrics";
uses svec-metrics-bounds_config;
}
}
uses te-types:generic-path-srlgs;
uses svec-exclude;
}
grouping synchronization-optimization {
description "Synchronized request optimization";
container optimizations {
description
"The objective function container that includes
attributes to impose when computing a synchronized set of
paths";
choice algorithm {
description "Optimizations algorithm.";
case metric {
list optimization-metric {
Busi, Belotti, et al. Expires September 5, 2018 [Page 40]
Internet-DraftYang model for requesting Path Computation March 2018
key "metric-type";
description "svec path metric type";
uses svec-metrics-optimization_config;
}
}
case objective-function {
container objective-function {
description
"The objective function container that includes
attributes to impose when computing a TE path";
uses te-types:path-objective-function_config;
}
}
}
}
}
grouping synchronization-info {
description "Information for sync";
list synchronization {
key "synchronization-id";
description "sync list";
leaf synchronization-id {
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;
Busi, Belotti, et al. Expires September 5, 2018 [Page 41]
Internet-DraftYang model for requesting Path Computation March 2018
default false;
description "link-diverse";
}
leaf node-diverse {
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 synchronization-constraints;
uses synchronization-optimization;
}
}
grouping no-path-info {
description "no-path-info";
container no-path {
presence "Response without path information, due to failure
performing the path computation";
description "if path computation cannot identify a path,
rpc returns no path.";
}
}
/*
* Root container
*/
container paths {
Busi, Belotti, et al. Expires September 5, 2018 [Page 42]
Internet-DraftYang model for requesting Path Computation March 2018
list path {
key "path-id";
config false;
uses path-info;
description "List of previous computed paths.";
}
description "Root container for path-computation";
}
/**
* AUGMENTS TO TE RPC
*/
augment "/te:tunnels-rpc/te:input/te:tunnel-info" {
description "statelessComputeP2PPath input";
list path-request {
key "request-id";
description "request-list";
leaf request-id {
type uint32;
mandatory true;
description "Each path computation request is uniquely
identified by the request-id-number.
It must be present also in rpcs.";
}
uses end-points;
uses te:bidir-assoc-properties;
uses te-types:path-route-objects;
uses te-types:generic-path-constraints;
uses te-types:generic-path-optimization;
uses requested-metrics-info;
}
uses synchronization-info;
}
augment "/te:tunnels-rpc/te:output/te:result" {
description "statelessComputeP2PPath output";
list response {
key response-id;
Busi, Belotti, et al. Expires September 5, 2018 [Page 43]
Internet-DraftYang model for requesting Path Computation March 2018
config false;
description "response";
leaf response-id {
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 computed-path {
uses path-info;
description "Path computation service.";
}
}
}
}
}
}
```
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].
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
Busi, Belotti, et al. Expires September 5, 2018 [Page 44]
Internet-DraftYang model for requesting Path Computation March 2018
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.
[ITU-T G.709-2016] ITU-T Recommendation G.709 (06/16), "Interface
for the optical transport network", June 2016
Busi, Belotti, et al. Expires September 5, 2018 [Page 45]
Internet-DraftYang model for requesting Path Computation March 2018
9.2. Informative References
[RFC4655] Farrel, A. et al., "A Path Computation Element (PCE)-Based
Architecture", RFC 4655, August 2006.
[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 September 5, 2018 [Page 46]
Internet-DraftYang model for requesting Path Computation March 2018
Appendix A. Examples of dimensioning the "detailed connectivity matrix"
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.
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
Busi, Belotti, et al. Expires September 5, 2018 [Page 47]
Internet-DraftYang model for requesting Path Computation March 2018
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.
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
Busi, Belotti, et al. Expires September 5, 2018 [Page 48]
Internet-DraftYang model for requesting Path Computation March 2018
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
objective functions of [RFC5541] as they are conceived
only for optimization)*5 = 30 cardinality.
Technology
constraints For further study
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
Busi, Belotti, et al. Expires September 5, 2018 [Page 49]
Internet-DraftYang model for requesting Path Computation March 2018
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,
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.
Busi, Belotti, et al. Expires September 5, 2018 [Page 50]
Internet-DraftYang model for requesting Path Computation March 2018
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
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.
Busi, Belotti, et al. Expires September 5, 2018 [Page 51]
Internet-DraftYang model for requesting Path Computation March 2018
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 September 5, 2018 [Page 52]
Internet-DraftYang model for requesting Path Computation March 2018
Oscar Gonzalez de Dios
Telefonica
Email: oscar.gonzalezdedios@telefonica.com
Anurag Sharma
Google
Email: ansha@google.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 September 5, 2018 [Page 53]
```