Internet DRAFT - draft-ietf-teas-te-topo-and-tunnel-modeling
draft-ietf-teas-te-topo-and-tunnel-modeling
TEAS Working Group Igor Bryskin
Internet Draft Individual
Intended status: Informational Vishnu Pavan Beeram
Tarek Saad
Juniper Networks
Xufeng Liu
Volta Networks
Expires: January 12, 2021 July 12, 2020
TE Topology and Tunnel Modeling for Transport Networks
draft-ietf-teas-te-topo-and-tunnel-modeling-06
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
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 12, 2021.
Copyright Notice
Copyright (c) 2020 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
Bryskin, et al. Expires January 12, 2021 [Page 1]
Internet-Draft TE Topology and Tunnel Modeling July 2020
(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
This document describes how to model TE topologies and tunnels for
transport networks, by using the TE topology YANG model [I-D.ietf-
teas-yang-te-topo] and the TE tunnel YANG model [I-D.ietf-teas-yang-
te].
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
Table of Contents
1. Modeling Considerations........................................3
1.1. TE Topology Model.........................................3
1.2. TE Topology Modeling Constructs...........................5
1.3. Abstract TE Topology Calculation, Configuration and
Maintenance...................................................22
1.3.1. Single-Node Abstract TE Topology....................23
1.3.2. Full Mesh Link Abstract TE Topology.................25
1.3.3. Star-n-Spokes Abstract TE Topology..................27
1.3.4. Arbitrary Abstract TE Topology......................28
1.3.5. Customized Abstract TE Topologies...................29
1.3.6. Hierarchical Abstract TE Topologies.................30
1.4. Merging TE Topologies Provided By Multiple Providers.....31
1.4.1. Dealing With Multiple Abstract TE Topologies Provided By
The Same Provider..........................................34
1.5. Configuring Abstract TE Topologies.......................36
1.6. TE Tunnel Model..........................................37
1.7. TE Tunnel/Transport Service Modeling Constructs..........39
1.7.1. Bidirectional Tunnels...............................53
1.8. Transport Service Mapping................................55
1.9. Multi-Domain Transport Service Coordination..............56
2. Use Cases.....................................................61
2.1. Use Case 1. Transport service control on a single layer
multi-domain transport network................................61
Bryskin, et al. Expires January 12, 2021 [Page 2]
Internet-Draft TE Topology and Tunnel Modeling July 2020
2.2. Use Case 2. End-to-end TE tunnel control on a single layer
multi-domain transport network................................69
2.3. Use Case 3. Transport service control on a ODUk/Och multi-
domain transport network with Ethernet access links...........73
2.4. Use Case 4. Transport service control on a ODUk/Och multi-
domain transport network with multi-function access links.....80
2.5. Use Case 5. Real time updates of IP/MPLS layer TE link
attributes that depend on supporting transport connectivity (e.g.
transport SRLGs, propagation delay, etc.).....................83
2.6. Use Case 6. Virtual Network Service......................84
3. Security Considerations.......................................87
4. IANA Considerations...........................................87
5. References....................................................88
5.1. Normative References.....................................88
5.2. Informative References...................................88
6. Acknowledgments...............................................88
Appendix A. Data Examples........................................89
A.1. Use Case 1...............................................89
A.1.1. Domain 1............................................89
A.1.2. Domain 2............................................96
A.1.3. Domain 3...........................................102
Authors' Addresses..............................................108
1. Modeling Considerations
1.1. TE Topology Model
The TE Topology Model is written in YANG modeling language. It is
defined and developed by the IETF TEAS WG and is documented as "YANG
Data Model for TE Topologies" [I-D.ietf-teas-yang-te-topo]. The model
describes a TE network provider's Traffic Engineering data store as
it is seen by a client. It allows for the provider to convey to each
of its clients:
o information on network resources available to the client in the
form of one or several native TE topologies (for example, one for
each layer network supported by the provider);
o one or several abstract TE topologies, customized on per-client
basis and sorted according to the provider's preference as to how
the abstract TE topologies are to be used by the client;
o updates with incremental changes happened to the previously
provided abstract/native TE topology elements;
o updates on telemetry/state information the client has expressed
interest in;
Bryskin, et al. Expires January 12, 2021 [Page 3]
Internet-Draft TE Topology and Tunnel Modeling July 2020
o overlay/underlay relationships between the TE topologies provided
to the client (e.g. TE path computed in an underlay TE topology
supporting a TE link in an overlay TE topology);
o client/server inter-layer adaptation relationships between the TE
topologies provided to the client in the form of TE inter-layer
locks or transitional links;
The TE Topology Model allows a network client to:
o (Re-)configure/negotiate abstract TE topologies provided to the
client by a TE network provider, so that said abstract TE
topologies optimally satisfy the client's needs, constraints and
optimization criteria, based on the client's network planning,
service forecasts, telemetry information extracted from the
network, previous history of service provisioning and performance
monitoring, etc.;
o Obtain abstract/native TE topologies from multiple providers and
lock them horizontally (inter-domain) and vertically (inter-layer)
into the client's own native TE topologies;
o Configure, with each provider the trigger, frequency and contents
of the TE topology update notifications;
o Configure, with each provider the trigger, frequency and contents
of the TE topology telemetry (e.g. statistics counters) update
notifications.
Bryskin, et al. Expires January 12, 2021 [Page 4]
Internet-Draft TE Topology and Tunnel Modeling July 2020
1.2. TE Topology Modeling Constructs
Figure 1. TE Topology
o TE domain - a multi-layer traffic engineered network under direct
and complete control of a single authority, network provider. TE
domain can be described by one or more TE topologies. For example,
separate TE topologies can describe each of the domain's layer
networks. TE domain can hierarchically encompass/parent other
(child) TE domains, and can be encompassed by its own parent.
o TE topology - a graphical representation of a TE domain. TE
topology is comprised of TE nodes (TE graph vertices)
interconnected via TE links (TE graph edges).
_____________________________________________________________________
/* TE topology */
augment /nw:networks/nw:network:
/* TE topology global ID */
+--rw provider-id? te-types:te-global-id
+--rw client-id? te-types:te-global-id
+--rw te-topology-id? te-types:te-topology-id
..................................................................
/* TE topology general parameters */
| +--rw preference? uint8
| +--rw optimization-criterion? identityref
..................................................................
Bryskin, et al. Expires January 12, 2021 [Page 5]
Internet-Draft TE Topology and Tunnel Modeling July 2020
/* TE topology list of TE nodes */
augment /nw:networks/nw:network/nw:node:
+--rw te-node-id? te-types:te-node-id
..................................................................
/* TE topology list of TE links */
augment /nw:networks/nw:network/nt:link:
..................................................................
/* TE topology list of TE link termination points */
augment /nw:networks/nw:network/nw:node/nt:termination-point:
+--rw te-tp-id? te-types:te-tp-id
..................................................................
_____________________________________________________________________
Figure 2. TE Node
Bryskin, et al. Expires January 12, 2021 [Page 6]
Internet-Draft TE Topology and Tunnel Modeling July 2020
o TE node - an element of a TE topology (appears as a vertex on TE
graph). A TE node represents one or several nodes (physical
switches), or a fraction of a node. A TE node belongs to and is
fully defined in exactly one TE topology. A TE node is assigned a
TE topology scope-unique ID. TE node attributes include
information related to the data plane aspects of the associated
node(s) (e.g. TE node's connectivity matrix), as well as
configuration data (such as TE node name). A given TE node can be
reached on the TE graph, representing the TE topology, over one of
TE links terminated by the TE node.
_____________________________________________________________________
/* TE node */
augment /nw:networks/nw:network/nw:node:
/* TE node ID */
+--rw te-node-id? te-types:te-node-id
..................................................................
/* TE node general attributes */
| +--rw te-node-attributes */
..................................................................
/* TE node connectivity matrices */
| +--rw connectivity-matrices
..................................................................
/* TE node underlay TE topology */
| +--rw underlay-topology {te-topology-hierarchy}?
| +--rw network-ref? leafref
..................................................................
/* TE node information sources*/
| +--ro information-source-entry* [information-source]
..................................................................
/* TE node statistics */
+--ro statistics
..................................................................
/* TE node TTP list */
+--rw tunnel-termination-point* [tunnel-tp-id]
..................................................................
_____________________________________________________________________
Bryskin, et al. Expires January 12, 2021 [Page 7]
Internet-Draft TE Topology and Tunnel Modeling July 2020
o TE link - an element of a TE topology (appears as an edge on TE
graph), TE link is unidirectional and its arrow indicates the TE
link's direction. Edges with two arrows on the TE topology graph
(see Figure 1) represent bi-directional combinations of two
parallel oppositely directed TE links. A TE link represents one or
several physical links or a fraction of a physical link. A TE
link belongs to and is fully defined in exactly one TE topology. A
TE link is assigned a TE topology scope-unique ID. TE link
attributes include parameters related to the data plane aspects of
the associated link(s) (e.g. unreserved bandwidth, resource
maps/pools, etc.), as well as the configuration data (such as
remote node/link IDs, SRLGs, administrative colors, etc.) A TE
link is connected to a TE node, terminating the TE link via
exactly one TE link termination point (LTP).
_____________________________________________________________________
/* TE link */
augment /nw:networks/nw:network/nt:link:
/* TE link bundle information */
| +--rw (bundle-stack-level)?
| | | +--rw bundled-links
| | +--rw component-links
..................................................................
/* TE link general attributes */
| +--rw te-link-attributes
..................................................................
/* TE link underlay TE topology */
| +--rw underlay! {te-topology-hierarchy}?
| | +--rw primary-path
| | +--rw backup-path* [index]
..................................................................
/* TE link layer network */
| +--rw interface-switching-capability* [switching-
capability encoding]
..................................................................
/* TE link protection type */
| | +--rw protection-type? uint16
..................................................................
/* TE link supporting TE tunnels */
| | +--rw tunnels
Bryskin, et al. Expires January 12, 2021 [Page 8]
Internet-Draft TE Topology and Tunnel Modeling July 2020
..................................................................
/* TE link transitional link flag */
| +--ro is-transitional? empty
..................................................................
/* TE link information sources */
| +--ro information-source? te-info-source
..................................................................
/* TE link statistics */
+--ro statistics
..................................................................
_____________________________________________________________________
o Intra-domain TE link - TE link connecting two TE nodes within the
same TE topology representing a TE network domain (e.g. L14 in
Figure 1). From the point of view of the TE topology where the
intra-domain TE link is defined, the TE link is close-ended, that
is, both local and remote TE nodes of the link are defined in the
same TE topology.
o Inter-domain TE link - TE link connecting two border TE nodes
that belong to separate TE topologies describing neighboring TE
network domains (e.g. L3x in Figure 1). From the point of view of
the TE topology where the inter-domain TE link is defined, the TE
link is open-ended, that is, the remote TE node of the link is not
defined in the TE topology where the local TE node and the TE link
itself are defined.
[Note: from the point of view of a TE node terminating an inter-
domain TE link there is no difference between inter-domain and
access TE links]
o Access TE link - TE link connecting a border TE node of a TE
topology describing a TE network domain to a TE node of a TE
topology describing a customer network site (e.g. L1x in Figure 1)
From the point of view of the TE topology where the access TE link
is defined, the TE link is open-ended, that is, the remote TE node
of the link (t.e. TE node representing customer network
element(s)) is not defined in the TE topology where the local TE
node and the TE link itself are defined.
Bryskin, et al. Expires January 12, 2021 [Page 9]
Internet-Draft TE Topology and Tunnel Modeling July 2020
[Note: from the point of view of a TE node terminating an access
TE link there is no difference between access and inter-domain TE
links]
o Dynamic TE link - a TE link that shows up in (and disappears
from) a TE topology as a result of multi-layer traffic
engineering. Dynamic TE link (supported by a hierarchy TE tunnel
dynamically set up in a server layer network) is automatically
(i.e. without explicit configuration request) added to a client
layer network TE topology to augment the topology with additional
flexibility to ensure successful completion of the path
computation for and provisioning of a client layer network
connection/LSP. For example, an ODUk hierarchy TE tunnel can
support a dynamic Ethernet layer TE link to enable provisioning of
an Ethernet layer connection on a network that does not have
sufficient static Ethernet layer connectivity. Likewise, dynamic
TE link is automatically removed from the TE topology (and its
supporting hierarchy TE tunnel released) as soon as the TE link
stops carrying client layer connections/LSPs.
o TE link termination point (LTP) - a conceptual point of connection
of a TE node to one of the TE links terminated by the TE node (see
Figure 2a). Unlike TE link, LTP is bi-directional - an inbound TE
link and an oppositely directed outbound TE link have to be
connected to the TE node via the same LTP to constitute a bi-
directional TE link combination.
Figure 2a. Bi-directional TE link combination (left), independent
uni-directional TE links (right)
_____________________________________________________________________
/* LTP */
augment /nw:networks/nw:network/nw:node/nt:termination-point:
/* LTP ID */
+--rw te-tp-id? te-types:te-tp-id
/* LTP network layer ID */
| +--rw interface-switching-capability* [switching-
capability encoding]
| | +--rw switching-capability identityref
Bryskin, et al. Expires January 12, 2021 [Page 10]
Internet-Draft TE Topology and Tunnel Modeling July 2020
| | +--rw encoding identityref
/* LTP bandwidth information */
| | +--rw max-lsp-bandwidth* [priority]
| | +--rw priority uint8
| | +--rw bandwidth? te-bandwidth
/* LTP inter-layer locks */
| +--rw inter-layer-lock-id? uint32
..................................................................
_____________________________________________________________________
o TE tunnel termination point (TTP) - an element of TE topology
representing one or several potential TE tunnel
termination/adaptation points (e.g. OCh layer transponder). A TTP
is hosted by exactly one TE node (see Figure 2). A TTP is assigned
a TE node scope-unique ID. Depending on the TE node's internal
constraints, a given TTP hosted by the TE node could be accessed
via one, several or all TE links originated/terminated from/by the
TE node. TTP's important attributes include Local Link
Connectivity List, Adaptation Client Layer List, TE inter-layer
locks (see below), Unreserved Adaptation Bandwidth (announcing the
TTP's remaining adaptation resources sharable between all
potential client LTPs), and Property Flags (indicating
miscellaneous properties of the TTP, such as capability to support
1+1 protection for a TE tunnel terminated on the TTP).
_____________________________________________________________________
/* TTP */
+--rw tunnel-termination-point* [tunnel-tp-id]
/* TTP ID */
+--rw tunnel-tp-id binary
/* TTP layer network ID */
| +--rw switching-capability? identityref
| +--rw encoding? identityref
//* Inter-layer-locks supported by TTP */
| +--rw inter-layer-lock-id? uint32
/* TTP's protection capabilities */
| +--rw protection-type? identityref
/* TTP's list of client layer users */
| +--rw client-layer-adaptation
..................................................................
/* TTP's Local Link Connectivity List (LLCL) */
Bryskin, et al. Expires January 12, 2021 [Page 11]
Internet-Draft TE Topology and Tunnel Modeling July 2020
| +--rw local-link-connectivities
..................................................................
_____________________________________________________________________
o Label - in the context of circuit switched layer networks
identifies a particular resource on a TE link (e.g. Och
wavelength, ODUk container)
+--:(label)
+--rw value? rt-types:generalized-label
Figure 3. TTP Local Link Connectivity List
Bryskin, et al. Expires January 12, 2021 [Page 12]
Internet-Draft TE Topology and Tunnel Modeling July 2020
o TTP basic local link connectivity list (basic LLCL) - a list of TE
link/label combinations terminated by the TTP-hosting TE node
(effectively the same as LTP/label pairs), which the TTP could be
connected to (see Figure 3, upper left). From the point of view of
a potential TE path, basic LLCL provides a list of permissible
LTP/label pairs the TE path needs to start/stop on for a
connection, taking the TE path, to be successfully terminated on
the TTP in question.
o TTP detailed local link connectivity list (detailed LLCL) - basic
LLCL extended to provide a set of costs (such as intra-node
summary TE metric, delay, SRLGs, etc.) associated with each LLCL
entry (see Figure 3, upper right)
_____________________________________________________________________
/* TTP LLCL */
| +--rw local-link-connectivities
| +--rw number-of-entries? uint16
/* LLCL entry */
/* LLCL entry LTP */
| +--rw link-tp-ref leafref
..................................................................
/* LLC entry label range */
| +--rw label-restriction* [inclusive-exclusive label-start]
| | +--rw inclusive-exclusive enumeration
| | +--rw label-start rt-types:generalized-label
| | +--rw label-end? rt-types:generalized-
label
| | +--rw range-bitmap? binary
/* LLCL entry underlay TE path(s) */
| +--rw underlay! {te-topology-hierarchy}?
| | +--rw primary-path
| | +--rw backup-path* [index]
/* LLCL entry protection type */
| | +--rw protection-type? uint16
/* LLCL entry supporting TE tunnels */
| | +--rw tunnels
/* LLCL entry bandwidth parameters */
| +--rw max-lsp-bandwidth* [priority]
..................................................................
Bryskin, et al. Expires January 12, 2021 [Page 13]
Internet-Draft TE Topology and Tunnel Modeling July 2020
/* LLCL entry metrics (vector of costs) */
| +--rw te-default-metric? uint32
| +--rw te-delay-metric? uint32
| +--rw te-srlgs
| | +--rw value* te-types:srlg
| +--rw te-nsrlgs {nsrlg}?
..................................................................
/* LLCL entry ID */
| | +--rw id* uint32
_____________________________________________________________________
o TTP adaptation client layer list - a list of client layers that
could be directly adopted by the TTP. This list is necessary to
describe complex multi-layer (more than two layer) client-server
layer hierarchies and, in particular, to identify the position of
the TTP in said hierarchies.
_____________________________________________________________________
/* TTP adaptation client layer list */
| +--rw client-layer-adaptation
| | +--rw switching-capability* [switching-capability
encoding]
/* Client layer ID */
| | +--rw switching-capability identityref
| | +--rw encoding identityref
/* Adaptation bandwidth available for the client layer */
| | +--rw bandwidth? te-bandwidth
_____________________________________________________________________
Bryskin, et al. Expires January 12, 2021 [Page 14]
Internet-Draft TE Topology and Tunnel Modeling July 2020
Figure 4. TE Node Connectivity Matrix
o TE node basic connectivity matrix - a TE node attribute describing
the TE node's switching capabilities/limitations in the form of
permissible switching combinations of the TE node's LTP/label
pairs (see Figure 4, upper left). From the point of view of a
potential TE path arriving at the TE node at a given inbound
LTP/label, the node's basic connectivity matrix describes
permissible outbound LTP/label pairs for the TE path to leave the
TE node.
o TE node detailed connectivity matrix - TE node basic connectivity
matrix extended to provide a set of costs (such as intra-node
summary TE metric, delay, SRLGs, etc.) associated with each
connectivity matrix entry (see Figure 4, upper right).
_____________________________________________________________________
/* TE node connectivity matrix */
| +--rw connectivity-matrix* [id]
| +--rw id uint32
Bryskin, et al. Expires January 12, 2021 [Page 15]
Internet-Draft TE Topology and Tunnel Modeling July 2020
| +--rw from /* left LTP */
| | +--rw tp-ref? leafref
| +--rw to /* right LTP */
| | +--rw tp-ref? leafref
| +--rw is-allowed? boolean
/* Connectivity matrix entry label range */
| +--rw label-restriction* [inclusive-exclusive
label-start]
| | +--rw inclusive-exclusive enumeration
| | +--rw label-start rt-
types:generalized-label
| | +--rw label-end? rt-
types:generalized-label
| | +--rw range-bitmap? binary
/* Connectivity matrix entry underlay TE path(s) */
| +--rw underlay! {te-topology-hierarchy}?
| | +--rw primary-path
| | +--rw backup-path* [index]
/* Connectivity matrix entry protection type */
| | +--rw protection-type? uint16
/* Connectivity matrix entry supporting TE tunnels */
| | +--rw tunnels
/* Connectivity matrix entry bandwidth parameters */
| +--rw max-lsp-bandwidth* [priority]
..................................................................
/* Connectivity matrix entry metrics (vector of costs) */
| +--rw te-default-metric? uint32
| +--rw te-delay-metric? uint32
| +--rw te-srlgs
| | +--rw value* te-types:srlg
| +--rw te-nsrlgs {nsrlg}?
..................................................................
/* Connectivity matrix entry ID */
| | +--rw id* uint32
_____________________________________________________________________
Bryskin, et al. Expires January 12, 2021 [Page 16]
Internet-Draft TE Topology and Tunnel Modeling July 2020
Figure 5. TE Path
o TE path - an ordered list of TE node/link IDs (each possibly
augmented with labels) that interconnects over a TE topology a
pair of TTPs and could be used by a connection (see Figure 5). A
TE path could, for example, be a product of a successful path
computation performed for a given TE tunnel
_____________________________________________________________________
/* TE path */
/* TE topology the path is defined in */
| | | +--rw network-ref? leafref
/* Path type (IRO, XRO, ERO, RRO) */
| | | +--rw path-type? identityref
/* TE path elements */
| | | +--rw path-element* [path-element-id]
| | | +--rw path-element-id uint32
| | | +--rw index? uint32
| | | +--rw (type)?
/* Numbered TE link path element */
| | | +--:(ip-address)
| | | | +--rw ip-address-hop
| | | | +--rw address? inet:ip-address
Bryskin, et al. Expires January 12, 2021 [Page 17]
Internet-Draft TE Topology and Tunnel Modeling July 2020
| | | | +--rw hop-type? te-hop-type
/* AS number path element */
| | | +--:(as-number)
| | | | +--rw as-number-hop
| | | | +--rw as-number? binary
| | | | +--rw hop-type? te-hop-type
/* Unnumbered TE link path element */
| | | +--:(unnumbered-link)
| | | | +--rw unnumbered-hop
| | | | +--rw te-node-id? inet:ip-address
| | | | +--rw tp-id? uint32
| | | | +--rw hop-type? te-hop-type
/* Label path element */
| | | +--:(label)
| | | | +--rw label-hop
| | | | +--rw value? rt-types:generalized-label
| | | | +--rw direction? boolean
| | | +--:(sid)
| | | +--rw sid-hop
| | | +--rw sid? rt-types:generalized-label
_____________________________________________________________________
o TE path segment - a contiguous fragment of a TE path
Figure 6. TE Inter-Layer Lock
Bryskin, et al. Expires January 12, 2021 [Page 18]
Internet-Draft TE Topology and Tunnel Modeling July 2020
o TE inter-layer lock - a modeling concept describing client-server
layer adaptation relationships important for multi-layer traffic
engineering. It is an association of M client layer LTPs and N
server layer TTPs, within which data arriving at any of the client
layer LTPs could be adopted onto any of the server layer TTPs. A
TE inter-layer lock is identified by inter-layer lock ID, which is
unique across all TE topologies provided by the same provider. The
client layer LTPs and the server layer TTPs associated by a given
TE inter-layer lock share the same inter-layer lock ID value.
In Figure 6 a TE inter-layer lock IL_1 associates six client layer
LTPs (C_LTP_1 - C_LTP_6) with two server layer TTPs (S_TTP_1 and
S_TTP_2). As mentioned, they all have the same attribute -inter-
layer lock ID: IL_1, which is the only parameter/value indicating
the association. A given LTP may have zero, one or more inter-
layer lock IDs. In the case of multiple inter-layer lock IDs,
this implies that the data arriving at the LTP can be adopted onto
any of TTPs associated with all specified inter-layer locks. For
example, C_LTP_1 may be attributed with two inter-layer locks-
IL_1 and IL_2. This would mean that C_LTP_1 for adaptation
purposes can use not just TTPs associated with inter-layer lock
IL_1 (i.e. S_TTP_1 and S_TTP_2 in the Figure), but any of TTPs
associated with inter-layer lock IL_2. Likewise, a given TTP may
have one or more inter-layer locks, meaning that it can offer the
adaptation service to any client layer LTP having an inter-layer
lock matching one of its own.
LTPs and TTPs associated within the same TE inter-layer lock may
be hosted by the same (hybrid, multi-layer) TE node or by multiple
TE nodes defined in the same or separate TE topologies. The latter
case is especially important because TE topologies of different
layer networks could be modeled by separate augmentations of the
basic (common to all layers) TE topology model.
| +--rw inter-layer-lock-id? uint32
o Transitional link - an alternative method of modeling of client-
server adaptation relationship. Transitional link is a bi-
directional link connecting an LTP in a client layer to an LTP in
a server layer, which is associated (via TTP's LLCL) with a server
layer TTP capable of adopting of the client layer data onto a TE
tunnel terminated by the TTP. Important attributes pf a
transitional link are loca;/remote LTP IDs, TE metric and
available adaptation bandwidth.
Bryskin, et al. Expires January 12, 2021 [Page 19]
Internet-Draft TE Topology and Tunnel Modeling July 2020
Figure 7. Native and Abstract TE Topologies
o Native TE topology - a TE topology as it is known (to full extent
and unmodified) to the TE topology provider (see lower part of
Figure 7.). A native TE topology might be discovered via various
routing protocols and/or subscribe/publish techniques. For
example, a first-level TE topology provider (such as a T-SDN
Domain Controller, DC) may auto-discover its native TE
topology(ies) by participating in the domain's OSPF-TE protocol
instance; while a second-level TE topology provider (such as a
Hierarchical T-SDN Controller. HC) normally builds its native TE
topology(ies) based on TE topologies exposed by each of the
subordinate, first- level TE topology providers.
o Underlay TE topology - a TE topology that serves as a base for
constructing overlay TE topologies.
Bryskin, et al. Expires January 12, 2021 [Page 20]
Internet-Draft TE Topology and Tunnel Modeling July 2020
o Overlay TE topology - a TE topology constructed based on one or
more underlay TE topologies. Each TE node of the overlay TE
topology represents a separate underlay TE topology (that could be
mapped onto an arbitrary segment of a native TE topology). Each TE
link of the overlay TE topology represents, generally speaking, an
arbitrary TE path in one of the underlay TE topologies. The
overlay TE topology and the supporting underlay TE topologies may
represent separate layer networks (e.g. OTN/ODUk and WDM/OCh
respectively) or the same layer network.
o Abstract TE topology - an overlay TE topology created by a
provider to describe its network in some abstract way. An abstract
TE topology contains at least one abstract TE topology element,
such as TE node or TE link. An abstract TE topology is built based
on contents of one or more of the provider's native TE topologies
(serving as underlay(s)), the provider's policies and the client's
preferences (see upper part of Figure 7).
o Customized TE topology - a TE topology tailored for a given
provider's client. A customized TE topology is usually but not
always an abstract TE topology. For example, a given abstract TE
topology could be exposed to a group or all provider's clients (in
which case the abstract TE topology is not a customized TE
topology). Likewise, a given naive TE topology could be customized
for a given client (for example, by removing high delay TE links
the client does not care about). So customized TE topology is not
an abstract TE topology, because it does not contain abstract TE
topology elements
o TE inter-domain plug - a TE link attribute meaningful for open-
ended inter-domain/access TE links. It contains a network-wide
unique value (inter-domain plug ID) that identifies in the network
a connectivity supporting the inter-domain/access TE link in
question. It is expected that a given pair of neighboring domain
TE topologies (provided by separate providers) will have each at
least one open-ended inter-domain/access TE link with a TE inter-
domain plug matching to one provided by its neighbor, thus
allowing for a client of both domains to identify adjacent nodes
in the separate neighboring TE topologies and resolve the open-
ended inter-domain/access TE links by connecting them regardless
of the links respective local/remote node ID/link ID attributes.
Inter-domain plug IDs may be assigned and managed by a central
network authority. Alternatively, inter-domain plug IDs could be
dynamically auto-discovered (e.g. via LMP protocol).
_____________________________________________________________________
Bryskin, et al. Expires January 12, 2021 [Page 21]
Internet-Draft TE Topology and Tunnel Modeling July 2020
+--rw external-domain
| +--rw network-ref? leafref
| +--rw remote-te-node-id? te-types:te-node-id
| +--rw remote-te-link-tp-id? te-types:te-tp-id
| +--rw plug-id? uint32
_____________________________________________________________________
1.3. Abstract TE Topology Calculation, Configuration and Maintenance
The TE Topology Model does not prescribe what and how abstract TE
topologies are computed, configured, manipulated and supported by a
TE network (e.g. transport network) provider. However, it is assumed
that:
o All TE topologies, native or abstract, conveyed to the same or
different clients, are largely independent one from another. This
implies that each TE topology, generally speaking, has an
independent name space for TE node and link IDs, SRLGs, etc.
(possibly overlapping with the name spaces of other TE
topologies);
o All abstract TE topologies are bound to the respective underlay
native or abstract TE topologies only by the overlay/underlay
relationships defined by the TE Topology Model, but, otherwise,
the abstract TE topologies are decoupled from their respective
underlay TE topologies.
It is envisioned that an original set of abstract TE topologies is
produced by a TE network provider for each of its clients based on
the provider's local configurations and/or policies, as well as the
client-specific profiles. The original set of abstract TE topologies
offered to a client may be accepted by the client as-is.
Alternatively, the client may choose to negotiate/re-configure the
abstract TE topologies, so that the latter optimally satisfy the
client's needs. In particular, for each of the abstract TE topologies
the client may request adding/removing TE nodes, TE links, TTPs
and/or modifying re-configurable parameters of the existing
components. The client may also request different optimization
criteria as compared to those used for the original abstract TE
topology optimization, or/and specify various topology-level
constraints. The provider may accept or reject all or some abstract
TE topology re-configuration requests. Hence, the abstract TE
topology negotiation process may take multiple iterations before the
provider and each of its clients agree upon a set of abstract TE
Bryskin, et al. Expires January 12, 2021 [Page 22]
Internet-Draft TE Topology and Tunnel Modeling July 2020
topologies and their contents. Furthermore, the negotiation process
could be repeated over time to produce new abstract TE topologies
optimal to best suit evolving circumstances.
Figure 8. Native Transport Network Domain TE Topology as an Underlay
for Abstract TE Topologies
Let's assume that a native transport network domain TE topology to be
as depicted in Figure 8. The popular types of abstract TE topologies
based on this native TE topology as an underlay are described in the
following sections.
1.3.1. Single-Node Abstract TE Topology
Figure 9. Blocking/Asymmetrical TE Node with Basic Connectivity
Matrix Attribute
Bryskin, et al. Expires January 12, 2021 [Page 23]
Internet-Draft TE Topology and Tunnel Modeling July 2020
In Figure 9, the transport network domain is presented to a client as
a one-node abstract TE topology, where the single TE node (AN1)
represents the entire domain and terminates all of the inter-
domain/access TE links connecting the domain to its adjacent domains
(i.e. TE links L1...L8). Because AN1 represents the entire domain the
node's Underlay TE Topology attribute matches the ID of one of the
domain's native TE topologies (e.g. one presented in Figure 8).
[Note: all or some of the underlay TE topologies a given abstract TE
topology depends on could be catered to the client by the provider
along with the abstract TE topology in question or upon separate
request(s) issued by the client.]
One important caveat about abstract TE node AN1 is that it should be
considered as an asymmetrical/blocking switch, because, generally
speaking, it is not guaranteed that a suitable TE path exists between
any given pair of inter-domain TE links into/out of the domain. This
means from the TE Topology model point of view that there are certain
limitations as to how AN1's LTPs could be interconnected
inside/across the TE node. The model allows for asymmetrical/blocking
switches by specifying for the associated TE nodes a non-empty basic
connectivity matrix attribute describing permissible inbound-outbound
TE link/label switching combinations. It is assumed that the
provider's path computer can compute a set of optimal TE paths,
connecting inbound TE link/label_x <=> outbound TE link/label_y
combinations inside the abstract TE node over the TE node's underlay
TE topology. Based on the results of such computations, AN1's
connectivity matrix can be (re-)generated and (re-)conveyed to the
abstract TE topology client.
A richer version of the basic connectivity matrix is the detailed
connectivity matrix. The latter not only describes permissible
inbound TE link/label_x <=> TE link/label TE link/label_y switching
combinations, but also provides connectivity matrix entry specific
vectors of various costs/metrics (in terms of delay, bandwidth,
intra-node SRLGs and summary TE metrics) that a potential TE path
will accrue, should a given connectivity matrix entry be selected by
the path for crossing the TE node (see Figure 10).
Bryskin, et al. Expires January 12, 2021 [Page 24]
Internet-Draft TE Topology and Tunnel Modeling July 2020
Figure 10. Blocking/Asymmetrical TE Node with Detailed Connectivity
Matrix Attribute
1.3.2. Full Mesh Link Abstract TE Topology
Figure 11. Full Mesh Link Abstract TE Topology
In Figure 11, the transport network domain is abstracted in the
following way.
Bryskin, et al. Expires January 12, 2021 [Page 25]
Internet-Draft TE Topology and Tunnel Modeling July 2020
o Each of the underlay native TE topology border TE nodes (i.e., the
TE nodes terminating at least one inter-domain/access TE link,
such as TE nodes S3 or S11 in Figure 8) is represented in the
abstract TE topology as a separate abstract TE node, matching one-
for-one to the respective border TE node of the underlay TE
topology. For example, S3' of the abstract TE topology represents
S3 of the underlay TE topology in Figure 8. [Note that such a
relationship is modeled via Supporting Node attribute of TE node
S3' specifying the ID of S3, as well as the ID of the TE topology
where S3 is defined (i.e. TE topology in Figure 8)]. Likewise, S9'
represents S9, S11' represents S11 and so forth;
o TE nodes S3', S5', S8', S9' and S11' are interconnected via a full
mesh of abstract TE links. It is assumed that the provider's path
computer can compute a set of optimal TE paths over one or more of
underlay TE topologies (such as presented in Figure 8)- one for
each of said abstract TE links; and the provider can set up the TE
tunnels in the network supporting each of the abstract TE links,
either during the abstract TE topology configuration (in the case
of committed/pre-established abstract TE links), or at the time
the first client's connection is placed on the abstract TE link in
question (the case of uncommitted abstract TE links). [Note that
so (re-)computed TE paths, as well as the IDs of respective
underlay TE topologies used for their computation are normally
catered to the client in the Underlay TE path attribute of the
associated abstract TE links]
The configuration parameters of each of the abstract TE links (such
as layer ID, bandwidth and protection requirements, preferred TE
paths across the underlay TE topology for the primary and backup
connections, etc.) are expected to be found in the abstract TE
topology profiles/templates locally configured with the provider or
pushed to the provider by the client via the policy NBI. Each of the
abstract TE links may be later re-configured or removed by direct
configuration requests issued by the client via TE Topology NBI.
Likewise, additional abstract TE links may be requested by the client
at any time.
Some possible variants/flavors of the Full Mesh Link Abstract TE
Topology described above are:
o Partial Mesh Link Abstract TE Topology (where some of the abstract
TE links from the full mesh are missing);
o Double Mesh Link Abstract TE Topology (where each pair of abstract
TE nodes is connected via two diverse abstract TE links).
Bryskin, et al. Expires January 12, 2021 [Page 26]
Internet-Draft TE Topology and Tunnel Modeling July 2020
1.3.3. Star-n-Spokes Abstract TE Topology
Figure 12. Star-n-Spoke Abstract TE Topology
The Full Mesh Link Abstract TE Topology suffers from the n-squared
problem; that is, the number of required abstract TE links is
proportional to square of the number of native TE topology border TE
nodes. This problem can be mitigated (i.e., the number of required
abstract TE links may be significantly reduced) by adding, to the
abstract TE topology, an additional abstract TE node (the star)
representing one or several interconnected non-border TE nodes from
the native TE topology. Abstract TE links in the Star-n-Spokes
Topology connect the star with all other TE nodes of the topology
(the spokes). For example, abstract TE node AN1 in Figure 12 could
represent collectively TE nodes S7, S10 and S4 of the native TE
topology (see Figure 8) with abstract TE links connecting AN1 with
all other TE nodes in the Star-n-Spokes Abstract TE Topology in
Figure 12.
In order to introduce a composite abstract TE node, (e.g. AN1 in
Figure 12) representing in a given abstract TE topology an arbitrary
segment of another TE topology (e.g. TE nodes S7, S12 and S4 of the
TE topology in Figure 8) the TE topology provider is expected to
perform the following operations:
o Copy the TE topology segment to be represented by the abstract TE
node (i.e. TE nodes S7, S10 and S4 in Figure 8, as well as the TE
links interconnecting them) into a separate auxiliary TE topology
(with a separate TE topology ID);
Bryskin, et al. Expires January 12, 2021 [Page 27]
Internet-Draft TE Topology and Tunnel Modeling July 2020
o Set for each TE node and TE link of the auxiliary TE topology the
Supporting Node/Link attribute matching the original TE topology
ID, as well as the ID of the respective original TE node/link of
the original TE topology. For example, if S7" of the auxiliary TE
topology is a copy of S7 of the original TE topology, the
Supporting Node attribute of S7" will specify the ID of the
original TE topology (presented in figure 8) and the ID of S7;
o Set for the abstract TE node AN1 the Underlay TE Topology
attribute matching the auxiliary TE Topology ID
Furthermore, the Star-n-Spokes Abstract TE topology provider is
expected to:
o Compute/provision TE paths/tunnels supporting each of the abstract
TE links in Figure 12 (i.e. abstract TE links connecting the
spokes to the star, AN1) as described in 1.3.2;
o Generate the AN1's Basic/Detailed Connectivity Matrix attribute
based on intra-node path computations performed on the AN1's
underlay (i.e. auxiliary) TE topology and describing permissible
inbound TE link/label_x. outbound TE link/label_y switching
combinations as described in 1.3.1
1.3.4. Arbitrary Abstract TE Topology
Figure 13. Arbitrary Abstract TE Topology
To achieve an optimal tradeoff between the number of components, the
amount of information exposed by a transport network provider and the
Bryskin, et al. Expires January 12, 2021 [Page 28]
Internet-Draft TE Topology and Tunnel Modeling July 2020
amount of path computations required to keep said information up-to-
date, the provider may present the TE network domain as an arbitrary
abstract TE topology comprised of any number of abstract TE nodes
interconnected by abstract TE links (see Figure 13). Each of the
abstract TE nodes can represent a single or several interconnected TE
nodes from the domain's underlay (native or lower level abstract) TE
topology, or a fraction of an underlay TE node. [Note that each of
the abstract TE nodes of the TE topology in Figure 13 is expected to
be introduced and maintained by the provider following the
instructions as described in 1.3.3; likewise, each of the abstract TE
links of the topology is expected to be computed, provisioned and
maintained as described in 1.3.2]
1.3.5. Customized Abstract TE Topologies
Figure 14. Customized Abstract TE Topology(ies)
A transport network/domain provider may serve more than one client.
In such a case, the provider "slices" the network/domain resources
and exposes a slice for each of the clients in the form of a
customized abstract TE topology. In Figure 14, the provider serves
Bryskin, et al. Expires January 12, 2021 [Page 29]
Internet-Draft TE Topology and Tunnel Modeling July 2020
two clients (Blue and Red). Client Blue is provided with the Blue
abstract TE topology supported by the blue TE tunnels or paths in the
underlay (native) TE topology (depicted in the Figure with blue
broken lines). Likewise, client Red is provided with the Red abstract
TE topology supported by the red TE tunnels or paths in the underlay
TE topology.
1.3.6. Hierarchical Abstract TE Topologies
Figure 15. Hierarchy of Abstract TE Topologies
As previously mentioned, an underlay TE topology for a given abstract
TE topology component does not have to be one of the domain's native
TE topologies - another (lower level) domain's abstract TTE topology
can be used instead. This means that abstract TE topologies are
hierarchical in nature.
Figure 15 provides an example of abstract TE topology hierarchy. In
this Figure the blue topology is a top level abstract TE topology
catered to by the provider to one of the domain's clients. One of the
TE links of the blue topology - link EF - is supported by a TE path
E'-M-P-Q-N-F' computed in the underlay TE topology (red topology),
which happens to be domain's (lower level) abstract TE topology..
Furthermore, as shown, the TE link PQ - one of the TE links
comprising the E'-M-P-Q-N-F' path - is supported by its own underlay
Bryskin, et al. Expires January 12, 2021 [Page 30]
Internet-Draft TE Topology and Tunnel Modeling July 2020
TE path, P'-X-Q' - computed on one of the domain's native TE
topologies.
Importantly, each TE link and TE node of a given abstract TE topology
has, generally speaking, its individual stack/hierarchy of underlay
TE topologies.
1.4. Merging TE Topologies Provided By Multiple Providers
A client may receive TE topologies provided by multiple providers,
each of which managing a separate domain of an interconnected multi-
domain transport network. In order to make use of said topologies,
the client is expected to merge (inter-connect) the provided TE
topologies into one or more client's native TE topologies, each of
which homogeneously representing the multi-domain transport network.
This makes it possible for the client to select end-to-end TE paths
for its TE tunnel connections traversing multiple domains.
In particular, the process of merging TE topologies includes:
o Identifying neighboring TE domains and locking their TE topologies
horizontally by connecting their inter-domain open-ended TE links;
o Renaming TE node, link, and SRLG IDs into ones allocated from a
separate name space; this is necessary because all TE topologies
are considered to be, generally speaking, independent with a
possibility of clashes among TE node, link or SRLG IDs. Original
TE node/link IDs along with the original TE topology ID are stored
in the Source attribute of the respective TE nodes/links of the
merged TE topology;
o Locking, TE topologies associated with different layer networks
vertically according to provided TE inter-layer locks; this is to
facilitate inter-layer path computations across multiple TE
topologies provided by the same topology provider.
Bryskin, et al. Expires January 12, 2021 [Page 31]
Internet-Draft TE Topology and Tunnel Modeling July 2020
Figure 16. Merging Domain TE Topologies
Figure 16 illustrates the process of merging, by the client, of TE
topologies provided by the client's providers.
In the Figure, each of the two providers caters to the client a TE
topology (abstract or native), describing the network domain under
the respective provider's control. The client, by consulting the
attributes of the open-ended inter-domain/access TE links - such as
TE inter-domain plugs or remote TE node/link IDs - is able to
determine that:
1. the two domains are adjacent and are interconnected via three
inter-domain TE links, and;
2. each domain is connected to a separate customer site, connecting
the left domain in the Figure to customer devices C-11 and C-12,
and the right domain to customer devices C-21, C-22 and C-23.
Bryskin, et al. Expires January 12, 2021 [Page 32]
Internet-Draft TE Topology and Tunnel Modeling July 2020
Therefore, the client interconnects the open-ended TE links, as shown
on the upper part of the Figure.
As mentioned, one way to interconnect the open-ended inter-
domain/access TE links of neighboring domains is to mandate the
providers to specify remote nodeID/linkID attributes in the provided
inter-domain/access TE links. This, however, may prove to be not
flexible. For example, the providers may not be aware of the
respective remote nodeID/linked values. More importantly, this option
does not allow for the client to mix-n-match multiple (more than one)
TE topologies catered by the same providers (see the next section).
Another, more flexible, option to resolve the open-ended inter-
domain/access TE links is by decorating them with the TE inter-domain
plug attribute. The attribute specifies inter-domain plug ID - a
network-wide unique value that identifies on the network connectivity
supporting a given inter-domain/access TE link. Instead of specifying
remote node ID/link ID, an inter-domain/access TE link may provide a
non-zero inert-domain plug ID. It is expected that two neighboring
domain TE topologies (provided by separate providers) will have each
at least one open-ended inter-domain/access TE link with a TE inter-
domain plug matching to one provided by its neighbor. For example,
the inter-domain TE link originating from node S5 of the Domain 1 TE
topology (Figure 8) and the inter-domain TE link coming from node S3
of Domain2 TE topology may specify matching TE inter-domain plugs
(i.e. carrying the same inter-domain plug ID). This would allow for
the client to identify adjacent nodes in the separate neighboring TE
topologies and resolve the inter-domain/access TE links connecting
them regardless of their respective nodeIDs/linkIDs (which, as
mentioned, could be allocated from independent name spaces).
Inter-domain plug IDs may be assigned and managed by a central
network authority. Alternatively, inter-domain plug IDs could be
dynamically auto-discovered (e.g. via LMP protocol).
Furthermore, the client renames the TE nodes, links and SRLGs offered
in the abstract TE topologies by assigning to them IDs allocated from
a separate name space managed by the client. Such renaming is
necessary, because the two abstract TE topologies may have their own
name spaces, generally speaking, independent one from another; hence,
ID overlaps/clashes are possible. For example, both TE topologies
have TE nodes named S7, which, after renaming, appear in the merged
TE topology as S17 and S27 respectively. IDs of the original (i.e.
abstract TE topology) TE nodes/links along with the ID of the
abstract TE topology they belong to are stored in the Source
attribute of the respective TE nodes/links of the merged TE topology.
For example, the Source attribute of S27 will contain S7 and the TE
topology ID of the abstract TE topology describing domain 2.
Bryskin, et al. Expires January 12, 2021 [Page 33]
Internet-Draft TE Topology and Tunnel Modeling July 2020
Once the merging process is complete, the client can use the merged
TE topology for path computations across both domains, for example,
to compute a TE path connecting C-11 to C-23.
1.4.1. Dealing With Multiple Abstract TE Topologies Provided By The Same
Provider
Figure 17. Multiple Abstract TE Topologies Provided By TE Topology
Providers
A given provider may expose more than one abstract TE topology to the
client. For example, one abstract TE topology could be optimized
based on a lowest-cost criterion, while another one could be based on
best possible delay metrics, while yet another one could be based on
maximum bandwidth availability for the client connections.
Furthermore, the client may request all or some providers to expose
additional abstract TE topologies, possibly of a different type
and/or optimized differently, as compared to already-provided TE
topologies. In any case, the client should be prepared for a provider
to offer to the client more than one abstract TE topology.
Bryskin, et al. Expires January 12, 2021 [Page 34]
Internet-Draft TE Topology and Tunnel Modeling July 2020
It should be up to the client to decide how to mix-and-match multiple
abstract TE topologies provided by each of the providers, as well as
how to merge them into the client's native TE topologies. The client
also decides how many such merged TE topologies it needs to produce
and maintain. For example, in addition to the merged TE topology
depicted on the upper part of Figure 16, the client may merge the
abstract TE topologies received from the two providers, as shown in
Figure 17, into the client's additional native TE topologies, as
shown in Figure 18.
[Note: allowing for the client mix-n-matching of multiple TE
topologies assumes that TE inter-domain plugs (rather than remote
nodeID/linked) option is used for identifying neighboring domains and
inter-domain/access TE link resolution.]
Figure 18. Multiple Native (Merged) Client's TE Topologies
Bryskin, et al. Expires January 12, 2021 [Page 35]
Internet-Draft TE Topology and Tunnel Modeling July 2020
It is important to keep in mind that each of the three native
(merged) TE topologies could be used by the client for computing TE
paths for any of the multi-domain connections. The choice as to which
topology to use for a given connection depends on the
connection/tunnel parameters/requirements and the topology's style
and optimization criteria.
1.5. Configuring Abstract TE Topologies
When a client receives one or more abstract TE topologies from one of
its providers, it may accept the topologies as-is and merge then into
one or more of its own native TE topologies. Alternatively, the
client may choose to request a re-configuration of one, some or all
abstract TE topologies provided by the providers. Specifically, with
respect to a given abstract TE topology, some of its TE nodes/links
may be requested to be removed, while additional ones may be
requested to be added. It is also possible that existing TE
nodes/links may be asked to be re-configured. For example, a set of
TE links may be requested to be disjoint from each other by
configuring the same Non Sharing Risk Link Group (NSRLG) attribute
for all links from the set. Such a configuration would force the
provider to place TE tunnels supporting the TE links from the set
onto sufficiently disjoint TE paths computed in the tunnels underlay
TE topology. Furthermore, the topology-wide optimization criteria may
be requested to be changed. For example, underlay TE paths supporting
the abstract TE links, currently optimized to be shortest (least-
cost) paths, may be requested to be re-optimized based on the minimal
delay criteria. Additionally, the client may request the providers to
configure entirely new abstract TE topologies and/or to remove
existing ones. Furthermore, future periodic or one time additions,
removals and/or re-configurations of abstract TE topology elements
and/or their attributes could be (re-)scheduled by the client ahead
of time.
It is the responsibility of the client to implement the logic behind
the above-described abstract TE topology negotiation. It is expected
that the logic is influenced by the client's local
configuration/templates, policies conveyed by client's clients, input
from the network planning process, telemetry processor, analytics
systems and/or direct human operator commands. Figure 19 exemplifies
the abstract TE topology negotiation process. As shown in the Figure,
the original abstract TE topology exposed by a provider was requested
to be re-configured. Specifically, one of the abstract TE links was
asked to be removed, while three new ones were asked to be added to
the abstract TE topology.
Bryskin, et al. Expires January 12, 2021 [Page 36]
Internet-Draft TE Topology and Tunnel Modeling July 2020
Figure 19. Provider. Client Abstract TE Topology Negotiation
1.6. TE Tunnel Model
The TE Tunnel Model is written in YANG modeling language. It is
defined and developed by the IETF TEAS WG and is documented as "YANG
Data Model for Traffic Engineering Tunnels and Interfaces" [I-D.ietf-
teas-yang-te]. Among other things the model describes a TE network
provider's TE Tunnel data store as it is seen and influenced by a
client.
The TE Tunnel Model allows for the provider to convey to each of its
clients:
o information on TE tunnels provided to the client that are fully
contained within the controlled network domain,
o information on multi-domain TE tunnel segments across the network
domain controlled by the provider;
o information on connections/LSPs, supporting TE tunnels and TE
tunnel segments;
o updates in response to changes to the client's active TE
tunnels/segments and the connections supporting them,
Bryskin, et al. Expires January 12, 2021 [Page 37]
Internet-Draft TE Topology and Tunnel Modeling July 2020
o updates in response to the TE tunnel/segment telemetry/state
information the client has expressed an interest in.
The TE Tunnel Model allows for a TE network client to:
o Issue configuration requests to set up, tear down, replace, modify
and manipulate end-to-end TE tunnels, as well as segments of
multi-domain TE tunnels across the network controlled by the
provider;
o Request and obtain information on active TE tunnels/segments and
connections supporting them;
o Subscribe to and configure with the provider triggers, pace and
contents of the TE tunnel/segment change update notifications;
o Subscribe to and configure with the provider triggers, pace and
contents of the TE tunnel/segment event notifications, such as
detected alarms, faults, protection/restoration actions, etc..
o Subscribe to and configure with the provider triggers, pace and
contents of TE tunnel/segment telemetry (e.g. statistics counters)
update notifications.
Bryskin, et al. Expires January 12, 2021 [Page 38]
Internet-Draft TE Topology and Tunnel Modeling July 2020
1.7. TE Tunnel/Transport Service Modeling Constructs
Figure 20. TE tunnel
o TE tunnel - a connection-oriented service provided by a layer
network of delivery of a client's data between source and
destination tunnel termination points. A TE tunnel in a server
layer network may support a link in a client layer network (e.g.
OCh layer TE tunnel supporting ODU4 link). In Figure 20, a TE
tunnel interconnects tunnel termination points resident on
switches C-R2 and C-R3. A TE tunnel is realized via (supported by,
mapped onto) one or more layer network connections/LSPs
_____________________________________________________________________
/* TE tunnel */
| +--rw tunnel* [name]
| | +--rw name leafref
Bryskin, et al. Expires January 12, 2021 [Page 39]
Internet-Draft TE Topology and Tunnel Modeling July 2020
| | +--rw identifier? leafref
/* TE tunnel configuration parameters */
| | +--rw config
| | | +--rw name? string
| | | +--rw type? identityref
| | | +--rw identifier? uint16
| | | +--rw description? string
| | | +--rw switchcap? identityref
| | | +--rw encoding? identityref
| | | +--rw protection-type? identityref
| | | +--rw admin-status? identityref
| | | +--rw preference? uint8
| | | +--rw reoptimize-timer? uint16
| | | +--rw source? inet:ip-address
| | | +--rw destination? inet:ip-address
| | | +--rw src-tp-id? binary
| | | +--rw dst-tp-id? binary
| | | +--rw topology-id? te-types:te-topology-
id
| | | +--rw ignore-overload? boolean
| | | +--rw bandwidth-generic? te-types:te-bandwidth
| | | +--rw disjointness? te-types:te-path-
disjointness
| | | +--rw setup-priority? uint8
| | | +--rw hold-priority? uint8
| | | +--rw signaling-type? identityref
/* Hierarchy TE tunnel parameters */
| | | +--rw hierarchical-link-id
| | | | +--rw local-te-node-id? te-types:te-node-id
| | | | +--rw local-te-link-tp-id? te-types:te-tp-id
| | | | +--rw remote-te-node-id? te-types:te-node-id
| | | | +--rw te-topology-id? te-types:te-
topology-id
/* Bidirectional TE tunnel parameters */
| | | +--rw bidirectional
| | | +--rw association
| | | +--rw id? uint16
| | | +--rw source? inet:ip-address
| | | +--rw global-source? inet:ip-address
| | | +--rw type? identityref
| | | +--rw provisioing? identityref
/* TE tunnel state */
| | +--ro state
| | | +--ro name? string
| | | +--ro type? identityref
| | | +--ro identifier? uint16
..............................................................
Bryskin, et al. Expires January 12, 2021 [Page 40]
Internet-Draft TE Topology and Tunnel Modeling July 2020
| | | +--ro oper-status? identityref
/* TE tunnel primary path and LSP container */
| | +--rw p2p-primary-paths
| | | +--rw p2p-primary-path* [name]
| | | +--rw name
/* Configuration */
leafref
| | | +--rw config
| | | | +--rw name? string
| | | | +--rw preference? uint8
| | | | +--rw path-setup-protocol? identityref
| | | | +--rw path-computation-method? identityref
| | | | +--rw path-computation-server? inet:ip-
address
| | | | +--rw compute-only? empty
| | | | +--rw use-cspf? boolean
| | | | +--rw verbatim? empty
| | | | +--rw lockdown? empty
| | | | +--rw named-explicit-path? leafref
| | | | +--rw named-path-constraint? leafref {te-
types:named-path-constraints}?
/* state */
| | | +--ro state
| | | | +--ro name? string
| | | | +--ro preference? uint8
| | | | +--ro path-setup-protocol? identityref
| | | | +--ro path-computation-method? identityref
| | | | +--ro path-computation-server? inet:ip-
address
| | | | +--ro compute-only? empty
| | | | +--ro use-cspf? boolean
| | | | +--ro verbatim? empty
| | | | +--ro lockdown? empty
| | | | +--ro named-explicit-path? leafref
| | | | +--ro named-path-constraint? leafref
{te-types:named-path-constraints}?
/* Computed path */
/* Computed path properties/metrics /
| | | | +--ro computed-path-properties
| | | | | +--ro path-metric* [metric-type]
| | | | | | +--ro metric-type identityref
| | | | | | +--ro accumulative-value? uint64
/* Computed path affinities */
| | | | | +--ro path-affinities
| | | | | | +--ro constraints* [usage]
| | | | | | | +--ro usage?
identityref
Bryskin, et al. Expires January 12, 2021 [Page 41]
Internet-Draft TE Topology and Tunnel Modeling July 2020
| | | | | | | +--ro (style)?
| | | | | | | +--:(value)
| | | | | | | | +--ro value? te-
types:admin-groups
| | | | | | | +--:(named)
| | | | | | | +--ro affinity-names*
[name]
| | | | | | | +--ro name string
/* Computed path SRLGs */
| | | | | +--ro path-srlgs
| | | | | | +--ro (style)?
| | | | | | +--:(values)
| | | | | | | +--ro usage? identityref
| | | | | | | +--ro values* te-
types:srlg
| | | | | | +--:(named)
| | | | | | +--ro constraints* [usage]
| | | | | | +--ro usage
identityref
| | | | | | +--ro constraint
| | | | | | +--ro srlg-names* [name]
| | | | | | +--ro name string
/* Computed path sub-objects */
| | | | | +--ro path-computed-route-objects
..............................................................
/* LSP (provisioned path) */
| | | | +--ro lsp* [source destination tunnel-id
lsp-id extended-tunnel-id type]
/* LSP parameters */
| | | | +--ro source leafref
| | | | +--ro destination leafref
| | | | +--ro tunnel-id leafref
| | | | +--ro lsp-id leafref
| | | | +--ro extended-tunnel-id leafref
| | | | +--ro type leafref
| | | | +--ro signaling-type? identityref
| | | +--rw candidate-p2p-secondary-paths
| | | +--rw candidate-p2p-secondary-path*
[secondary-path]
| | | +--rw secondary-path leafref
| | | +--rw config
| | | | +--rw secondary-path? leafref
| | | | +--rw priority? uint16
| | | | +--rw path-setup-protocol?
identityref
| | | +--ro state
| | | +--ro secondary-path? leafref
Bryskin, et al. Expires January 12, 2021 [Page 42]
Internet-Draft TE Topology and Tunnel Modeling July 2020
| | | +--ro priority? uint16
| | | +--ro path-setup-protocol?
identityref
| | | +--ro active? boolean
/* TE tunnel secondary path and LSP container */
| | +--rw p2p-secondary-paths
| | | +--rw p2p-secondary-path* [name]
......................................................
| | | +--rw name leafref
| | | +--rw config (same as for primary path )
.....................................................
| | | +--ro state (same as for primary, except for
disjointedness_state )
| | +--ro disjointness_state? te-types:te-path-
disjointness.....................................................
| | | +--ro computed-path-properties (same as for
primary path)
..........................................................
| | | | +--ro path-affinities (same as for primary
path)
..........................................................
| | | | +--ro path-srlgs (same as for primary
path)
..........................................................
| | | | +--ro path-computed-route-objects
.........................................................
/* LSP (provisioned path) */
| | | +--ro lsp (same as for the primary LSP)
........................................................
_____________________________________________________________________
Bryskin, et al. Expires January 12, 2021 [Page 43]
Internet-Draft TE Topology and Tunnel Modeling July 2020
o Tunnel termination point (TTP) - a physical device inside a given
node/switch realizing a TE tunnel termination function in a given
layer network, as well as the TE tunnel's adaptation function
provided for client layer network(s). One example of tunnel
termination point is an OCh layer transponder. [Note: Tunnel
termination points are not to be confused with TE tunnel
termination points, which are TE representations of physical
tunnel termination points. Similar to physical switches and links
of the network, such as depicted in Figure 20, being represented
on a TE topology describing the network as TE nodes and TE links,
(physical) tunnel termination points (TTPs) are represented as TE
tunnel termination points (TE TTPs, see 1.2) hosted by the TE
nodes. For example, a provisioned connection/LSP starts on a
source TTP, goes through a chain of physical links and stops on a
destination TTP. In contrast, TE path (e.g. result of a path
computation) starts on a source TE TTP, goes through a chain of TE
links and stops on a destination TE TTP.]
_____________________________________________________________________
| | | +--rw source? inet:ip-address
| | | +--rw destination? inet:ip-address
| | | +--rw src-tp-id? binary
| | | +--rw dst-tp-id? binary
_____________________________________________________________________
o TE tunnel hand-off point - an access link or inter-domain link by
which a multi-domain TE tunnel enters or exits a given network
domain, in conjunction with a layer network resource (such as a
wavelength channel or ODUk container) allocated on the
access/inter-domain link for the TE tunnel.
o TE tunnel segment - a part of a multi-domain TE tunnel that spans
a given network domain and is directly and fully controlled by the
domain's controller, DC. TE tunnel segment is a fragment of a
multi-domain TE tunnel between
1. the source tunnel termination point and the TE tunnel hand-off
point outbound from the TE tunnel's first domain (head TE tunnel
segment);
2. inbound and outbound TE tunnel hand-off points into/from a given
domain (transit TE tunnel segment);
Bryskin, et al. Expires January 12, 2021 [Page 44]
Internet-Draft TE Topology and Tunnel Modeling July 2020
3. inbound TE tunnel hand-off point into the TE tunnel's last
domain and the destination tunnel termination point (tail TE
tunnel segment);
o Transport service - the same as TE tunnel segment
o Hierarchy TE tunnel - a server layer TE tunnel that supports a
dynamically created TE link in the client layer network topology
(e.g. see 1.2)
_____________________________________________________________________
/* Hierarchy TE tunnel parameters */
| | | +--rw hierarchical-link-id
| | | | +--rw local-te-node-id? te-types:te-node-id
| | | | +--rw local-te-link-tp-id? te-types:te-tp-id
| | | | +--rw remote-te-node-id? te-types:te-node-id
| | | | +--rw te-topology-id? te-types:te-
topology-id
_____________________________________________________________________
o Hierarchy transport service - the first or the last segment of a
multi-domain hierarchy TE tunnel
o Dependency TE tunnel - a hierarchical TE tunnel provisioned or to
be provisioned in an immediayely adjacent server layer a given
client layer TE tunnel depends on (i.e. carried or to be carried
within)
o Potential TE tunnel/segment - a TE tunnel/segment configured in
COMPUTE_ONLY mode. For such a TE tunnel/segment TE paths to be
taken by supporting connection(s) is/are computed and monitored,
but the connection(s) are not provisioned
_____________________________________________________________________
| | | | +--rw path-computation-method? identityref
| | | | +--rw path-computation-server? inet:ip-
address
| | | | +--rw compute-only? empty
| | | | +--rw use-cspf? Boolean
_____________________________________________________________________
Bryskin, et al. Expires January 12, 2021 [Page 45]
Internet-Draft TE Topology and Tunnel Modeling July 2020
Figure 20a. TE Tunnel Connections/LSPs
o Layer network connection/connection/LSP - a layer network path
supporting a TE tunnel by realizing its implied forwarding
function. Said path is provisioned in a given layer network's data
plane over a chain of links and cross-connected over switches
terminating the links. It interconnects the supported TE tunnel's
source and destination termination points (in the case of end-to-
end connection) or TE tunnel's hand-off points (in the case of
transport service connection) or the TE tunnel's two split-merge
points (in the case of segment protection connection.
Example: ODU2 connection supporting an ODU2 TE tunnel.
_____________________________________________________________________
Bryskin, et al. Expires January 12, 2021 [Page 46]
Internet-Draft TE Topology and Tunnel Modeling July 2020
/* LSP (provisioned path) */
| | | | +--ro lsp* [source destination tunnel-id
lsp-id extended-tunnel-id type]
/* LSP parameters */
| | | | +--ro source leafref
| | | | +--ro destination leafref
| | | | +--ro tunnel-id leafref
| | | | +--ro lsp-id leafref
| | | | +--ro extended-tunnel-id leafref
| | | | +--ro type leafref
| | | | +--ro signaling-type? identityref
..................................................................
| | | +--ro priority? uint16
| | | +--ro path-setup-protocol?
identityref
| | | +--ro active? Boolean
_____________________________________________________________________
o Working connection - the primary connection of the supported TE
tunnel or transport service (see Figure 20a).
o End-to-end protection connection - a secondary end-to-end
connection of the supported TE tunnel (e.g. end-to-end 1+1
protection connection, see Figure 20a).
o Segment protection connection - a secondary connection of the
supported transport service protecting the service over a given
network domain (e.g. 1+1 segment protection connection, see Figure
20a)
o Restored connection - a connection after successful network
failure restorationrestoration procedures
o Current connection - the same as restored connection
o Nominal connection - a connection as (re-)provisioned upon a
client configuration request (i.e. a connection before any
automatic network failure restoration re-configurations are
carroed out, also a connection after restoration reversion
procedures are successfully completed)
o Unprotected TE tunnel/transport service - TE tunnel/transport
service supported by a single (working/primary) connection/LSP
Bryskin, et al. Expires January 12, 2021 [Page 47]
Internet-Draft TE Topology and Tunnel Modeling July 2020
o Protected TE tunnel/transport service - TE tunnel/transport
service supported by one working connection/LSP and at least one
protection/secondary connection/LSP
o Restorable TE tunnel/transport service - TE tunnel/transport
service with pre-configured automatic network failure restoration
capabilities
o TE tunnel/transport service automatic protection switchover - a
process of switching of carrying user payload from the
tunnel's/service's affected by a network failure working
connection onto one of the tunnel's/service's healthy protection
connection
o TE tunnel/transport service automatic protection reversion - a
process of switching of carrying user payload from the
tunnel's/service's protection connection back onto the
tunnel's/service's working connection after the latter was
repaired from network failure
o TE tunnel/transport service protection external command - a
command, typically issued by an operator, which influences the
automatic protection switchover and reversion.
External commands are defined in [ITU-T G.800] and [RFC 4427]:
. Freeze: A temporary configuration action that prevents any
switch action to be taken and as such freezes the current
state.
. Clear Freeze: An action that clears the active Freeze state.
. Lockout of Normal: A temporary configuration action that
ensures that the normal traffic is not allowed to use the
protection transport entity.
As described in [ITU-T G.808], this command should be issued
at both ends.
. Clear Lockout of Normal: An action that clears the active
Lockout of Normal state.
. Lockout of Protection: A temporary configuration action that
ensures that the protection transport entity is temporarily
not available to transport a traffic signal (either normal or
extra traffic).
Bryskin, et al. Expires January 12, 2021 [Page 48]
Internet-Draft TE Topology and Tunnel Modeling July 2020
. Forced Switch: A switch action that swithes the extra traffic
signal, the normal traffic signal, or the null signal to the
protection transport entity, unless an equal or higher
priority switch command is in effect.
. Manual Switch: A switch action that switches the extra
traffic signal, the normal traffic signal #i, or the null
signal to the protection transport entity, unless a fault
condition exists on other transport entities or an equal or
higher priority switch command is in effect.
. Exercise: An action to start testing if the APS communication
is operating correctly. It is lower priority than any other
state or command.
. Clear: An action that clears the active near-end lockout of
protection, forced switch, manual switch, WTR state, or
exercise command
o TE tunnel/transport service protection Hold-off time - a
configured period of time to expire between the moment of
detecting of the first network failure affecting the
tunnel's/service's working connection and the begining of the
tunnel's/service's automatic protection switchover procedures
o TE tunnel/transport service protection WTR time - a configured
period of time to expire between the moment of repairing the last
network failure affecting the tunnel's/service's working
connection and the begining of the tunnel's/service's automatic
protection reversion procedures
o TE tunnel/transport service automatic network failure restoration
- a process of replacing of the tunnel's/service's connection(s)
affected by one or more network failures away from the point(s) of
failue
o TE tunnel/transport service restoration reversion- a process of
replacing of the tunnel's/service's connection(s) back onto the
nominal connection paths after all network failures affecting the
tunnel's/service's nominal connection(s) are repaired
o TE tunnel/transport service restoration Hold-off time - a
configured period of time to expire between the moment of
detecting of the first network failure affecting the
tunnel's/service's nominal or current connection and the beginning
of the automatic connection restoration procedures
Bryskin, et al. Expires January 12, 2021 [Page 49]
Internet-Draft TE Topology and Tunnel Modeling July 2020
o TE tunnel/transport service restoration WTR time - a configured
period of time to expire between the moment of repairing the last
network failure affecting the tunnel's/service's nominal
connection and the begining of the connection automatic
restoration reversion procedures
o Configured restoration path - a TE path specified by the client to
be used during the automatic network failure restoration operation
on one of the TE tunnel's/transport service's nominal or current
connections
o Pre-computed restoration path - a configured restoration path to
be validated by a path computer during the TE tunnel/transport
service setup or client triggered modification
o Pre-provisioned restoration path - a pre-computed restoration path
to be pre-provisioned/pre-signaled in the network (with all
associated network resources allocated but not necessarily bound
into cross-connects) during the TE tunnel/transport service setup
or client triggered modification
o Connection configured path - a TE path (see 1.2) over a TE
topology describing a layer network/domain that specifies (loosely
or strictly) the client's requirements with respect to an ordered
list of network nodes, links and resources on the links a given
connection should go through
_____________________________________________________________________
| | +--rw explicit-route-object* [index]
| | +--rw index leafref
| | +--rw explicit-route-usage? identityref
(INCLUDE/EXCLUDE)
| | | +--rw index? uint32
| | | +--rw (type)?
| | | +--:(numbered)
| | | | +--rw numbered-hop
| | | | +--rw address? te-types:te-tp-
id
| | | | +--rw hop-type? te-hop-type
| | | +--:(as-number)
| | | | +--rw as-number-hop
| | | | +--rw as-number? binary
| | | | +--rw hop-type? te-hop-type
| | | +--:(unnumbered)
| | | | +--rw unnumbered-hop
Bryskin, et al. Expires January 12, 2021 [Page 50]
Internet-Draft TE Topology and Tunnel Modeling July 2020
| | | | +--rw node-id? te-types:te-
node-id
| | | | +--rw link-tp-id? te-types:te-
tp-id
| | | | +--rw hop-type? te-hop-type
| | | +--:(label)
| | | | +--rw label-hop
| | | | +--rw value? rt-
types:generalized-label
| | | +--:(sid)
| | | +--rw sid-hop
| | | +--rw sid? rt-
types:generalized-label
_____________________________________________________________________
o Connection exclusion path - a TE path over a TE topology
describing a layer network/domain that specifies the client's
requirements with respect to an unordered list of network nodes,
links and resources on the links to be avoided by a given
connection
_____________________________________________________________________
| | +--rw route-object-exclude-always* [index]
| | | +--rw index leafref
| | | | +--rw index? uint32
| | | | +--rw (type)?
| | | | +--:(numbered)
| | | | | +--rw numbered-hop
| | | | | +--rw address? te-types:te-tp-
id
| | | | +--:(as-number)
| | | | | +--rw as-number-hop
| | | | | +--rw as-number? binary
| | | | +--:(unnumbered)
| | | | | +--rw unnumbered-hop
| | | | | +--rw node-id? te-types:te-
node-id
| | | | | +--rw link-tp-id? te-types:te-
tp-id
| | | | +--:(label)
| | | | | +--rw label-hop
| | | | | +--rw value? rt-
types:generalized-label
Bryskin, et al. Expires January 12, 2021 [Page 51]
Internet-Draft TE Topology and Tunnel Modeling July 2020
| | | | +--:(sid)
| | | | +--rw sid-hop
| | | | +--rw sid? rt-
types:generalized-label
_____________________________________________________________________
o Connection computed path - a TE path over a TE topology describing
a layer network/domain as computed (subject to all configured
constraints and optimization criteria) for a given connection to
take. Computed connection path could be thought as the TE path
intended to be taken by the connection
_____________________________________________________________________
/* Computed path */
/* Computed path properties/metrics /
| | | | +--ro computed-path-properties
| | | | | +--ro path-metric* [metric-type]
| | | | | | +--ro metric-type identityref
| | | | | | +--ro accumulative-value? uint64
/* Computed path affinities */
| | | | | +--ro path-affinities
| | | | | | +--ro constraints* [usage]
| | | | | | | +--ro usage?
identityref
| | | | | | | +--ro (style)?
| | | | | | | +--:(value)
| | | | | | | | +--ro value? te-
types:admin-groups
| | | | | | | +--:(named)
| | | | | | | +--ro affinity-names*
[name]
| | | | | | | +--ro name string
/* Computed path SRLGs */
| | | | | +--ro path-srlgs
| | | | | | +--ro (style)?
| | | | | | +--:(values)
| | | | | | | +--ro usage? identityref
| | | | | | | +--ro values* te-
types:srlg
| | | | | | +--:(named)
| | | | | | +--ro constraints* [usage]
| | | | | | +--ro usage
identityref
Bryskin, et al. Expires January 12, 2021 [Page 52]
Internet-Draft TE Topology and Tunnel Modeling July 2020
| | | | | | +--ro constraint
| | | | | | +--ro srlg-names* [name]
| | | | | | +--ro name string
/* Computed path sub-objects */
| | | | | +--ro path-computed-route-objects
..............................................................
_____________________________________________________________________
o Connection actual path - an active connection's path as
provisioned in the layer network's data plane in the form of a TE
path over a TE topology describing the layer network/domain
1.7.1. Bidirectional Tunnels
The TE Tunnel model supports the setup of unidirectional connections
as well as multiple types of bidirectional connections.
The bidirectional flag is used to indicate whether the TE Tunnel is
unidirectional or bidirectional. In case of bidirectional TE Tunnels,
the p2p-reverse-primary-path presense container is used to indicate
whether the bidirectional TE Tunnel is native or not. This presense
container cannot be instantiated for unidirectional TE Tunnels.
Unidirectional TE Tunnel: the bidirectional flag is set to "False".
The unidirectional path constraints are configured in the p2p-
primary-path container (the p2p-reverse-primary-path presense
container is not created).
The server computes one unidirectional path and report it and its
properties within the p2p-primary-path container.
The server setup unidirectional LSPs and reports them under the p2p-
primary-path container.
Native bidirectional TE Tunnel: the bidirectional flag is set to
"True" and the p2p-reverse-primary-path container is not created.
The path constraints, applicable to both directions, are configured
in the p2p-primary-path container.
The server computes one bidirectional path and report it and its
properties within the p2p-primary-path container.
Bryskin, et al. Expires January 12, 2021 [Page 53]
Internet-Draft TE Topology and Tunnel Modeling July 2020
The server setup bidirectional LSPs and reports them under the p2p-
primary-path container.
Note that asymmetric bandwdith configuration is not supported with
native bidirectional tunnels.
Bidirectional (non-courouted) TE Tunnel: the bidirectional flag is
set to "True" and the p2p-reverse-primary-path container is created.
The path constraints, applicable to the forward direction, are
configured in the p2p-primary-path container, while the path
constraints applicable to the reverse direction are configured in the
p2p-reverse-primary-path container. It is therefore possible to
configure different set of path constraints, including different
bandwdith, in the two directions. If there are no path constraints
applicable to the backward direction, the p2p-reverse-primary-path
container can be empty (but it shall be present).
The server computes two indepedent paths in the forward and reverse
direction: the computed path in the forward direction and its
properties are reported within the p2p-primary-path container, while
the computed path in the reverse direction and its properties
reported within the p2p-reverse-primary-path container.
The server setup associated unidirectional LSPs in both directions:
unidirectional LSPs setup in the forward direction are reported
within the p2p-primary-path container, while unidirectional LSPs
setup in the backward direction are reported within the p2p-reverse-
primary-path container.
Bidirectional courouted TE Tunnel with asymmetric constraints: the
bidirectional flag is set to "True" and the p2p-reverse-primary-path
container is created.
The path constraints, applicable to the forward direction, are
configured in the p2p-primary-path container. The p2p-reverse-
primary-path container is configured with use-path-computation flag
set to False and an empty route-object-exclude-always container (to
indicate that the directions should be corouted). It is possible to
configure different bandwdiths in the two directions but no different
path constraints.
Note that in case of a bidirectional (non-courouted) TE Tunnel it is
also possible to configure the p2p-reverse-primary-path container
with the use-path-computation flag set to False, when the reverse
path is configured by the client and not computed by the server: in
Bryskin, et al. Expires January 12, 2021 [Page 54]
Internet-Draft TE Topology and Tunnel Modeling July 2020
this case route-object-exclude-always container is not empty but
specifies the complete explicit-path within the.
The server computes one bidirectional path and report it and its
properties within the p2p-primary-path container. No path properties
are reported within the p2p-reverse-primary-path container.
The server setup associated unidirectional LSPs in both directions:
unidirectional LSPs setup in the forward direction are reported
within the p2p-primary-path container, while unidirectional LSPs
setup in the backward direction are reported within the p2p-reverse-
primary-path container.
The label hops used in bidirectional routers (either for path
constraints or for path routes or for LSP routes) should report the
labels used in the two directions (forward and backward):
o in case the same label is used in both direction, there will be
only one label hop with an empty direction leaf;
o in case different labels are used in the two directions, there
will be two label hops, one specifying the label in the forward
direction and another for the label in the reverse direction.
Associated unidirectional TE Tunnels: two unidirectional TE Tunnels
(with the bidirectional flag is set to "False") are configured in the
forward and reverse direction and associated for bidirectionality
using the association container.
1.8. Transport Service Mapping
Figure 21. Transport Service Mapping
Let's assume that a provider has exposed to a client its network
domain in the form of an abstract TE topology, as shown on the left
Bryskin, et al. Expires January 12, 2021 [Page 55]
Internet-Draft TE Topology and Tunnel Modeling July 2020
side of Figure 21. From then on, the provider should be prepared to
receive from the client, a request to set up or manipulate a
transport service with TE path(s) computed for the service
connection(s) based on and expressed in terms of the provided
abstract TE topology (as, for example, displayed in red broken line
on the right side of Figure 21). When this happens, the provider is
expected to set up the TE tunnels supporting all yet uncommitted
abstract TE links (e. g, TE link S3'-S8' in the Figure).
Furthermore, it is the responsibility of the provider to:
o Perform all the necessary abstract-to-native translations for the
specified TE paths (i.e. the transport service connection
configured paths);
o Provision working and protection connections supporting the
transport service; as well as replace/modify/delete them in
accordance with subsequent client's configuration requests;
o Perform all the requested recovery operations upon detecting
network failures affecting the transport service;
o Notify the client about all parameter changes, events and other
telemetry information the client has expressed an interest in,
with respect to the transport service in question.
1.9. Multi-Domain Transport Service Coordination
A client of multiple TE network domains may need to
orchestrate/coordinate its transport service setup/manipulation
across some or all the domains. One example of such a client is a
Hierarchical T-SDN Controller, HC, managing a connected multi-domain
transport network where each of the domains is controlled by a
separate Domain T-SDN Controller, DC. Said DCs are expected to expose
TE Topology and TE Tunnel North Bound Interfaces, NBIs,, supported
respectively by IETF TE Topology and TE Tunnel models (and their
network layer specific augmentations). HC is assumed to establish
client-provider relationship with each of the DCs and make use of
said NBIs to extract from the domains various information (such as TE
topologies and telemetry), as well as to convey instructions to
coordinate across multiple domains its transport services set up and
manipulation.
Bryskin, et al. Expires January 12, 2021 [Page 56]
Internet-Draft TE Topology and Tunnel Modeling July 2020
Figure 22. Two-Domain Transport Network
Let's consider, for example, a two-domain transport network as
represented in Figure 22. Suppose that HC is requested to set up an
unprotected transport service to provide connectivity between
customer network elements C-R1 and C-R6. It is assumed that by the
time the request has arrived, the two DCs have already provided
abstract TE topologies describing their respective domains, and that
HC has merged the provided TE topologies into one that homogeneously
describes the entire transport network (as shown in Figure 23).
Bryskin, et al. Expires January 12, 2021 [Page 57]
Internet-Draft TE Topology and Tunnel Modeling July 2020
Figure 23. Two-Domain Transport Network (Abstracted View)
Consider that HC, using the merged TE topology, selected a TE path to
be taken by the requested transport service connection as shown on
the upper part of Figure 24.
The multi-domain transport service set up coordination includes:
o Splitting selected for the transport service TE path(s) into
segments - one set of segments per each domain involved in the
service setup;
o Issuing a configuration request to each of the involved DCs to set
up the transport service across the respective domain. Note that
the connection configured paths are required to be expressed in
terms of respective abstract TE topologies as exposed to HC by DCs
(see lower part of Figure 24).
Bryskin, et al. Expires January 12, 2021 [Page 58]
Internet-Draft TE Topology and Tunnel Modeling July 2020
o Waiting for the set up complete confirmation from each of the
involved DCs. In case one of the DCs reports a failure, HC is
responsible to carry out the cleanup/rollback procedures by
requesting all involved DCs to tear down the successfully created
segments
Figure 24. Transport Service Placement Based on Abstract TE Topology
While processing the received from HC configuration request to set up
the transport service, each DC is expected to carry out the transport
service mapping procedures (as described in 1.8) resulting in the set
up of all the necessary underlay TE tunnels, as well as one or more
connections supporting the transport service. As a result, the
requested transport service will be provisioned as shown in Figure
25.
Bryskin, et al. Expires January 12, 2021 [Page 59]
Internet-Draft TE Topology and Tunnel Modeling July 2020
o In the example above the TE tunnel segments that each DC has to
set up are the head TE tunnel segment (for domain 1) and the tail
TE tunnel segment (for domain 2). For head TE tunnel segment HC
can specify in the configuration request only the source TTP
(located in node s3 in the example), but not the tunnel's
destination TTP, because it is outside of the domain controlled by
the DC.
Therefore, the outbound hand-off point (in the form of outbound
inter-domain TE link ID/label pair) of each connection segment
supporting a TE tunnel non-tail segment (such as head or transit
tunnel segment) is expected to be found at the end of the route-
object-include-exclude list of the explicit-route-objects
configured for that connection segment.
o Likewise, the inbound hand-off point (in the form of inbound
inter-domain TE link ID/label pair) of each connection segment
supporting a TE tunnel non-head segment (such as tail or transit
tunnel segment) is expected to be found at the beginning of the
route-object-include-exclude list of the explicit-route-objects
configured for that connection segments.
o For example, in the figure above the HC can specify the outbound
hand-off point of the primary path supporting the head TE tunnel
segment. The configuration is to be the in the form of the pair of
the TE link ID, identifying the inter domain link terminating on
node s7, and of the TE label used on that link.
o In case (not present in this example) we need to setup a Transit
Tunnel Segment since the endpoints of the E2E Tunnel are both
outside the domain controlled by that DC, the HC would not specify
any source or destination TTP (i.e., it would leave the source,
destination, src-tp-id and dst-tp-id attributes empty)and it would
use the the route-object-include-exclude list of the explicit-
route-objects to specify the inbound and outbound hand-off points
of each connection segment supporting the Transit Tunnel Segment.
The multi-domain transport service tear down coordination entails
issuing to each of the involved DCs a configuration request to delete
the transport service in the controlled by the DC domain. DCs are
expected in this case to release all network resources allocated for
the transport service.
Bryskin, et al. Expires January 12, 2021 [Page 60]
Internet-Draft TE Topology and Tunnel Modeling July 2020
The multi-domain transport service modify coordination implies
issuing to each of the involved DCs a configuration request to
replace the transport service connections according to the newly
provided paths and/or modify the connection parameters according to
the newly provided configuration.
Figure 25. Multi-domain transport service is provisioned
2. Use Cases
2.1. Use Case 1. Transport service control on a single layer multi-
domain transport network
Configuration (Figure 26):
o Three-domain multi-vendor ODUk/Och transport network;
o The domains are interconnected via ODUk inter-domain links;
Bryskin, et al. Expires January 12, 2021 [Page 61]
Internet-Draft TE Topology and Tunnel Modeling July 2020
o Each of the domains is comprised of ODUk/Och network elements
(switches) from a separate vendor and is controlled by a single
(vendor specific) T-SDN Domain Controller (DC);
o All DCs expose IETF TE Topology and TE Tunnel model based NBIs;
o The transport network as a whole is controlled by a single
hierarchical T-SDN controller (HC);
o HC makes use of the NBIs to set up client-provider relationship
with each of the DCs and controls via the DCs their respective
network domains;
o Three customer IP/MPLS sites are connected to the transport
network via ODUk access links;
o The customer IP/MPLS routers and the router transport ports
connecting the routers to the transport network are managed
autonomously and independently from the transport network.
Bryskin, et al. Expires January 12, 2021 [Page 62]
Internet-Draft TE Topology and Tunnel Modeling July 2020
Figure 26 Three-domain ODUk/Och transport network with ODUk access
and inter-domain links
Objective: Set up/manipulate/delete a shortest delay unprotected or
protected transport service to provide connectivity between customer
network elements C-R2 and C-R5
1) TE Topology discovery
All DCs provide to HC respective domain ODUk layer abstract TE
topologies. Let's assume that each such topology is a single-node TE
topology (as described in 1.3.1, abstract TE topology of this type
represents the entire domain as a single asymmetrical/blocking TE
node). Let's further assume that the abstract TE nodes representing
the domains are attributed with detailed connectivity matrices
optimized according to the shortest delay criterion. [Note: single-
node abstract TE topologies are assumed for simplicity sake.
Alternatively, any DC could have provided an abstract TE topology of
any type described in 1.3].
Bryskin, et al. Expires January 12, 2021 [Page 63]
Internet-Draft TE Topology and Tunnel Modeling July 2020
HC merges the provided TE topologies into its own native TE topology
(the TE topology merging procedures are discussed in 1.4). The merged
TE topology, as well as the TE topologies provided by DCs, are
depicted in Figure 27. The merged TE topology homogeneously describes
the entire transport network and hence is suitable for path
computations across the network. Note that the dotted lines in the
Figure connecting the topology access TE links with customer devices
illustrate that HC in this use case has neither control nor
information on the customer devices/ports and, therefore, can only
provide a connectivity between the requested transport service
ingress and egress access links (on assumption that the customer
transport ports are provisioned independently)
Figure 27. Three-domain single layer transport network abstract TE
topology
Bryskin, et al. Expires January 12, 2021 [Page 64]
Internet-Draft TE Topology and Tunnel Modeling July 2020
2) Transport service path computation
Using the merged TE topology (Figure 27, upper part) HC selects one
or more optimal and sufficiently disjoint from each other TE path(s)
for the requested transport service connection(s). Resulting TE paths
for the requested end-to-end protected transport service, for
example, could be as marked on the upper part of Figure 28.
It is important to keep in mind that HC's path computer is capable of
performing the necessary path selection only as long as the merged TE
topology provides the necessary TE visibility for the path selection,
both intra-domain (e.g. by virtue of provided by the abstract TE
nodes detailed connectivity matrices) and inter-domain (because of
provided inter-domain TE link attributes). In case one or more DCs
is/are not capable of or willing to provide the detailed connectivity
matrices (that is, DCs expose the respective domains as black boxes -
unconstrained TE nodes terminating the inter-domain TE links), HC
will not be able to select the end-to-end TE path(s) for the
requested transport service on its own. In such a case HC may opt for
making use of the Path Computation NBI, exposed by the DCs to
explore/evaluate intra-domain TE path availability in real time. IETF
TE Tunnel model supports the Path Computation NBI by allowing for the
configuration of transport services in COMPUTE_ONLY mode. In this
mode the provider is expected to compute TE paths for a requested
transport service connections and return the paths in the request's
response without triggering the connection provisioning in the
network.
Consider, for example, the case when none of the DCs has provided the
detailed connectivity matrix attribute for the abstract TE nodes
representing the respective domain. In such a case HC may:
1. Request the ingress domain DC (i.e. DC1) to compute intra-domain
TE paths connecting the ingress access TE link (i.e. the link
facing C-R2) with each of the inter-domain TE links (i.e. links
connecting Domain 1 to Domain 2 and Domain 3 respectively);
2. Grow the TE paths returned by DC1 in (1) over the respective
outbound inter-domain TE links;
3. Request the neighboring DC(s) (e.g. DC3) to compute all intra-
domain TE paths connecting across the domain all inbound into
the domain inter-domain TE links reached by the path growing
process in (2) with all other (outbound) domain's inter-domain
TE links;
Bryskin, et al. Expires January 12, 2021 [Page 65]
Internet-Draft TE Topology and Tunnel Modeling July 2020
4. Augment the TE paths produced in step (2) with the TE paths
determined in step (3);
5. Repeat steps (2), (3) and (4) until the resulting TE paths reach
the egress domain (i.e. Domain 2);
6. Request the egress domain DC (i.e. DC2) to grow each of the TE
paths across the domain to connect them to the egress access TE
link (i.e. the link facing C-R5);
7. Select one (or more) most optimal and sufficiently disjoint from
each other TE path(s) from the list produced in step (6).
[Note: The transport service path selection method based on Path
Computation NBIs exposed by DCs does not scale well and the more
domains comprise the network and the more inter-domain links
interconnect them, the worse the method works. Realistically, this
approach will not work sufficiently well for the networks with more
than 3 domains]
Bryskin, et al. Expires January 12, 2021 [Page 66]
Internet-Draft TE Topology and Tunnel Modeling July 2020
Figure 28. TE paths computed for the protected transport service
3) Transport service setup coordination
HC carries out the multi-domain transport service setup coordination
as described in 1.9. In particular, HC splits the computed TE path(s)
into 3 sets of TE path segments - one set per domain (as shown on the
lower part of Figure 28), and issues a TE tunnel configuration
request to each of the DCs to set up the requested transport service
across the domain under the DC's control. The primary (and
secondary) connection explicit path(s) is/are specified in the
requests in terms of respective domain abstract TE topologies.
While processing the configuration request, each DC performs the
transport service mapping (as described in 1.8). In particular, the
DC translates the specified explicit path(s) from abstract into
native TE topology terms, sets up supporting underlay TE tunnels
Bryskin, et al. Expires January 12, 2021 [Page 67]
Internet-Draft TE Topology and Tunnel Modeling July 2020
(e.g. Och TE tunnels), and, then, allocates required ODUk containers
on the selected links and provisions the ODUk cross-connects on the
switches terminating the links.
If the setup is successfully completed in all three domains, the
transport service connection(s) will be provisioned as depicted in
Figure 29. If one of the DCs fails to set up its part, all
successfully provisioned segments will be asked by HC to be released.
4) Transport service teardown coordination
HC issues to each of DCs a configuration request to release the
transport service over the controlled domain, as well as the server
layer TE tunnels supporting dynamically created links.
Figure 29. Transport service is provisioned
Bryskin, et al. Expires January 12, 2021 [Page 68]
Internet-Draft TE Topology and Tunnel Modeling July 2020
2.2. Use Case 2. End-to-end TE tunnel control on a single layer multi-
domain transport network
Configuration (Figure 26): the same as in use case 1, except that HC
in this use case controls customer devices/ports by extracting
information from and pushing configuration to the customer site SDN
controller(s) managing the customer devices directly.
Objective: Set up//delete an unprotected shortest delay TE tunnel
interconnecting end-to-end C-R2 and C-R5
1) TE Topology discovery
As in use case 1 all DCs provide to HC domain ODUk layer abstract TE
topologies. Additionally in this use the three customer site
controllers expose the TE Topology and Tunnel model based NBIs to HC.
Using the TE Topology NBI each customer controller provides to HC the
respective customer site domain abstract TE topology. Customer site
abstract TE topologies contain abstract TE nodes representing the
devices which are directly connected to the transport network. Said
abstract TE nodes host TE tunnel termination points, TTPs,
representing the ports over which the customer devices are connected
to the transport network, and terminate access TE links the TTPs are
accessible from (see Figure 30).
Bryskin, et al. Expires January 12, 2021 [Page 69]
Internet-Draft TE Topology and Tunnel Modeling July 2020
Figure 30. Abstract TE topologies provided by all network domains and
customer sites
Bryskin, et al. Expires January 12, 2021 [Page 70]
Internet-Draft TE Topology and Tunnel Modeling July 2020
HC merges the provided topologies into its own native TE Topology
(the TE topology merging procedures are discussed in 1.4). The merged
TE topology is depicted in Figure 31. It homogeneously describes end-
to-end not only the entire transport network, but also the customer
sites connected to the network and hence is suitable for TE tunnel
end to end path computations.
Figure 31. Abstract TE topology describing transport network and
connected to it customer sites
2) TE tunnel path computation
Using the merged TE topology (Figure 31) HC selects an optimal TE
path for the requested TE tunnel connecting end-to-end the specified
TE tunnel termination points, TTPs. The resulting TE path, for
example, could be as marked on the upper part of Figure 32.
Bryskin, et al. Expires January 12, 2021 [Page 71]
Internet-Draft TE Topology and Tunnel Modeling July 2020
Figure 32. TE path computed for the TE tunnel
3) TE tunnel setup coordination
HC carries out the multi-domain TE tunnel setup coordination as
described for use case 1, except that in this use case HC
additionally initiates and controls the setup of the TE tunnel's head
and tail segments on the respective customer sites. Note that the
customer site controllers behave exactly as transport network domain
DCs. In particular, they receive issued by HC configuration requests
to set up the TE tunnel's head and tail segments respectively. While
processing the requests the customer site controllers perform the
necessary provisioning of the TE tunnel's source and destination
termination points, as well as of the local sides of the selected
Bryskin, et al. Expires January 12, 2021 [Page 72]
Internet-Draft TE Topology and Tunnel Modeling July 2020
access links. If all segments are successfully provisioned on
customer sites and network domains, the TE tunnel connection will be
provisioned as marked in Figure 33.
4) TE tunnel teardown coordination
HC issues to each of DCs and customer site controllers a
configuration request to release respective segments of the TE
tunnel, as well as the server layer TE tunnels supporting dynamically
created links.
Figure 33. TE tunnel is provisioned
2.3. Use Case 3. Transport service control on a ODUk/Och multi-domain
transport network with Ethernet access links
Configuration (Figure 34): the same as in use case 1, except that all
access links in this use case are Ethernet layer links (depicted as
Bryskin, et al. Expires January 12, 2021 [Page 73]
Internet-Draft TE Topology and Tunnel Modeling July 2020
blue lines in the Figure), while all inter-domain links remain to be
ODUk layer links.
Figure 34. Three-domain ODUk/Och transport network with Ethernet
layer access links
Objective: Set up//delete an unprotected shortest delay transport
service supporting connectivity between C-R2 and C-R5
1) TE Topology discovery
In order to make possible for the necessary in this use case multi-
layer path computation, each DC exposes to HC two (ODUk layer and
Ethernet layer) abstract TE topologies, Additionally, the lower
layer (ODUk) TE nodes announce hosted by them TE tunnel termination
points, TTPs, capable of adopting the payload carried over the
Ethernet layer access links, From the TE Topology model point of view
this means that said TTPs are attributed with TE inter-layer locks
Bryskin, et al. Expires January 12, 2021 [Page 74]
Internet-Draft TE Topology and Tunnel Modeling July 2020
matching ones attributed to Ethernet TE links (i.e. TE links provided
within Ethernet layer abstract TE topologies).
Ethernet and ODUk layer single node abstract TE topologies catered to
HC by each of the DCs are presented in Figure 35.
HC merges the provided TE topologies into its own native TE Topology
(the merging procedures are described in 1.4). Importantly in this
case HC locks the provided TE topologies not only horizontally, but
vertically as well, thus producing a two-layer TE topology
homogenously describing both layers of the entire transport network,
as well as the client-server layer adaptation relationships between
the two layers. This makes the merged TE topology suitable for multi-
layer/inter-layer multi-domain transport service path computations.
The merged TE topology is presented in Figure 36.
Figure 35. ODUk and Ethernet layer abstract TE topologies exposed by
DCs
Bryskin, et al. Expires January 12, 2021 [Page 75]
Internet-Draft TE Topology and Tunnel Modeling July 2020
Figure 36. Two-layer three-domain transport network abstract TE
topology
2) Transport service path computation
Using the merged TE topology (Figure 36) HC selects an optimal TE
path for the requested transport service.
Note that if HC's path computer considered only Ethernet layer TE
nodes and links, the path computation would .fail. This is because
the Ethernet layer TE nodes (i.e. D1-e, D2-e and D3-e in the Figure)
are disconnected from each other. However, the inter-layer
associations (in the form of the TE inter-layer locks) make possible
for the path computer to select TE path(s) in the lower (ODUk) layer
that can be used to set up hierarchy TE tunnel(s) supporting
additional dynamic TE link(s) in the upper (Ethernet ) layer in order
for the requested transport service path computation to succeed.
Bryskin, et al. Expires January 12, 2021 [Page 76]
Internet-Draft TE Topology and Tunnel Modeling July 2020
Let's sssume that the resulting TE path is as marked in Figure 37.
The red line in the Figure marks the TE path selected for the ODUk
layer hierarchy TE tunnel supporting the required Ethernet layer
dynamic TE link.
Figure 37. Multi-layer TE path computed for the transport service
Bryskin, et al. Expires January 12, 2021 [Page 77]
Internet-Draft TE Topology and Tunnel Modeling July 2020
3) Transport service setup coordination
HC sets up the requested Ethernet layer transport service in two
stages. First, it coordinates the end-to-end setup of the ODUk layer
hierarchy TE tunnel between the selected TTPs. If this operation
succeeds, a new Ethernet layer dynamic TE link (blue line connecting
TE nodes D1-e and D2-e in Figure 38) is automatically added to the
merged abstract TE topology. Importantly, as a part of the hierarchy
transport service setup both DC1 and DC 2 add a new open-ended
Ethernet layer inter-domain dynamic TE link to their respective
abstract TE topologies. Second, HC coordinates the setup of the
requested (Ethernet layer) transport service. The required TE path
for the second stage is marked as fat blue line in the Figure. Note
that DC3 controlling domain 3 is only involved in the first stage,
but is oblivious to the second stage.
Figure 38. A new Ethernet layer TE link supported by ODUk layer TE
tunnel is added to the provided and merged abstract TE topologies
Bryskin, et al. Expires January 12, 2021 [Page 78]
Internet-Draft TE Topology and Tunnel Modeling July 2020
IF all involved DCs confirm successful setup completion, the
requested transport service, as well as the supporting server layer
hierarchy TE tunnel, will be provisioned as depicted in Figure 39. If
one of the DCs fails to set up its segment in either of the layers,
all successfully provisioned segments will be requested by HC to be
released.
Figure 39. Ethernet transport service and supporting ODUk TE tunnel
are provisioned
4) Transport service teardown coordination
First, HC issues to DC1 and DC2 a configuration request to release
the Ethernet layer transport service in the respective domains. After
that, all three DCs are requested to release the segments of the
supporting ODUk layer hierarchy TE tunnel. While processing the
request DC1 and DC2 also remove the dynamic Ethernet layer TE links
supported by the respective hierarchy TE tunnel's segments, thus the
Bryskin, et al. Expires January 12, 2021 [Page 79]
Internet-Draft TE Topology and Tunnel Modeling July 2020
network's abstract TE topologies are reverted back to the state as
shown in Figures 35 and 36.
2.4. Use Case 4. Transport service control on a ODUk/Och multi-domain
transport network with multi-function access links
Configuration (Figure 40): the same as in use case 3, except that all
access links in this use case are multi-function links (depicted in
the Figure as blue compound lines). Let's assume that, depending on
configuration, the multi-function access links in this use case can
carry either Ethernet or SDH/STM16 layer payload.
Objective: Set up//delete an unprotected shortest delay SDH/STM16
layer transport service interconnecting C-R2 and C-R5
Figure 40. Three-domain ODUk/Och transport network with multi-
function access links
Bryskin, et al. Expires January 12, 2021 [Page 80]
Internet-Draft TE Topology and Tunnel Modeling July 2020
1) TE Topology discovery
The TE Topology model considers multi-function links as parallel
mutually exclusive TE links each belonging to a separate layer
network. For this use case each DC exposes to HC three (ODUk-,
Ethernet- and SDH/STM16-layer) abstract TE topologies (generally
speaking, one abstract TE topology per each layer network supported
by at least one access or inter-domain link). Like in use case 3,
the lower layer (ODUk) TE nodes announce hosted by them TE tunnel
termination points, TTPs, capable in this case of adopting Ethernet,
SDH/STM16 or both layer payloads, The TTPs are attributed with TE
inter-layer locks matching ones specified for Ethernet and/or
SDH/STM16 TE links.
Ethernet, SDH/STM16 and ODUk layer single-node abstract TE topologies
catered to HC by each of the DCs are presented in Figure 41.
HC merges the provided topologies into its own native TE Topology
(the merging procedures are described in 1.4). As in use case 3 HC
locks the provided TE topologies not only horizontally (i.e. between
domains), but vertically (between layers) as well, thus producing a
three-layer TE topology homogenously describing the three layers of
the entire transport network, as well as the client-server layer
adaptation relationships between the layers. This makes the merged TE
topology suitable for multi-layer/inter-layer multi-domain transport
service path computations. The merged TE topology is presented in
Figure 42.
Figure 41. ODUk, Ethernet and SDH/STM16 layer abstract TE topologies
exposed by DCs
Bryskin, et al. Expires January 12, 2021 [Page 81]
Internet-Draft TE Topology and Tunnel Modeling July 2020
Figure 42. Three-layer three-domain transport network abstract TE
topology
2) Transport service path computation
Using the merged TE topology (Figure 42) HC's path computer selects a
TE path for the requested transport service. For example, for the
SDH/STM16 layer unprotected transport service the resulting TE path
could be determined as marked in Figure 43.
Bryskin, et al. Expires January 12, 2021 [Page 82]
Internet-Draft TE Topology and Tunnel Modeling July 2020
Figure 43. Multi-layer TE path computed for SDH/STM16 layer transport
service
3) Transport service setup coordination
Same as in use case 3.
4) Transport service teardown coordination
Same as in use case 3.
2.5. Use Case 5. Real time updates of IP/MPLS layer TE link attributes
that depend on supporting transport connectivity (e.g. transport
SRLGs, propagation delay, etc.)
Configuration (Figure 26): the same as in use case 1,
Objective: A transport service interconnecting transport ports of two
IP routers across a transport network is likely to serve a link in
IP/MPLS layer network, which is usually controlled by a client of the
Bryskin, et al. Expires January 12, 2021 [Page 83]
Internet-Draft TE Topology and Tunnel Modeling July 2020
transport network, such as IP/MPLS Controller. Performance of TE
applications (e.g. path computer) running on the IP/MPLS Controller
depends on the accuracy of IP/MPLS layer TE link attributes. Some of
these attributes can change over time and are known real-time only to
a transport network controller, such as HC. Examples of said
attributes are transport SRLGs, propagation delay metric, protection
capacities and status, etc. The objective of this use case is to
ensure up-to-date state of said attributes in the IP/MPLS
Controller's internal TED via necessary updates provided in a timely
manner by the controller (e.g. HC) managing transport connectivity
supporting IP/MPLS layer links.
Realization:
o HC exposes and supports IETF TE Topology and TE Tunnel model based
NBIs (the same NBIs that are exposed by DCs serving HC);
o IP/MPLS Controller makes use of the exposed NBIs to set up the
respective client-provider relationships with HC;
o IP/MPLS Controller uses the TE Tunnel NBI to configure with HC a
transport service interconnecting transport ports of a pair of IP
routers desired to be adjacent in the IP/MPLS layer network. The
TE Tunnel model allows for specifying in the transport service
configuration request the TE topology and link IDs of the IP/MPLS
TE link the requested transport service will be serving;
o IP/MPLS Controller uses the TE Topology NBI to subscribe with HC
on the IP/MPLS TE link notifications with respect to changes in
the TE link's attributes, such as SRLGs, propagation delay,
protection capabilities/status, etc.;
o HC uses the TE Topology NBI to convey the requested notifications
when HC learns the attributes IP/MPLS has expressed interest in or
detects any changes since previous notifications (for example, due
to network failure restoration/reversion procedures happened to
the transport connectivity that supports the failure affected
IP/MPLS links)
2.6. Use Case 6. Virtual Network Service
Configuration (Figure 26): the same as in use case 1,
Objective: Set up two Virtual Networks for the client, with Virtual
Network 1 interconnecting customer IP routers C-R1, C-R7 and C-R4
over a single-node abstract TE topology, and Virtual Network 2
Bryskin, et al. Expires January 12, 2021 [Page 84]
Internet-Draft TE Topology and Tunnel Modeling July 2020
interconnecting customer IP routers C-R2, C-R3, C-R8, C-R5 and C-R6
over a full mesh link abstract TE topology as depicted in Figure 44.
[Note: A client of a transport network may want to limit the
transport network connectivity of a particular type and quality
within distinct subsets of its network elements interconnected across
the transport network. Furthermore, a given transport network may
serve more than one client. In this case some or all clients may want
to ensure the availability of transport network resources in case
dynamic (re-)connecting of their network elements across the
transport network is envisioned. In all such cases a client may want
to set up one or more Virtual Networks over provided transport
network]
1) Virtual Network setup
From the client's point of view a Virtual Network setup includes the
following procedures:
o Identifying the Virtual Network membership - a subset of the
client's network elements/ports to be interconnected over the
abstract TE topology configured for the Virtual Network. Note that
from the transport network provider's point of view this
effectively determines the list of abstract TE topology's open-
ended access TE links;
o Deciding on the Virtual Network's abstract TE topology type (e.g.
single-node vs. link mesh), optimization criterion (e.g. shortest
delay vs. smallest cost), bandwidth, link disjointedness,
adaptation capabilities and other requirements/constraints, as
well as, whether the TE tunnels supporting the abstract TE
topology need to be pre-established or established on demand (i.e.
when respective abstract TE topology elements are selected for a
client transport service);
o Using the IETF TE Topology model based NBI exposed by the
transport network controller (i.e. HC), configure the Virtual
Network's abstract TE topology. Let's assume that in this use case
the abstract TE topology for Virtual Network 1 is configured as a
single-node abstract TE topology (see section 1.3.1) with the
abstract TE node's detailed connectivity matrix optimized
according to the shortest delay criteria. Likewise, the abstract
TE topology for Virtual Network 2 is configured as a full-mesh
link abstract TE topology (see section 1.3.2) optimized according
to the smallest cost criteria with each of the abstract TE links
to be supported by pre-established end-to-end protected TE
tunnels.
Bryskin, et al. Expires January 12, 2021 [Page 85]
Internet-Draft TE Topology and Tunnel Modeling July 2020
[Note: Virtual Network's abstract TE topology (re-
)configuration/negotiation process is no different from one that
happens, for example, between HC and its providers, DCs, and is
described in section 1.5]
Figure 44. Virtual Networks provided for a transport network client
Bryskin, et al. Expires January 12, 2021 [Page 86]
Internet-Draft TE Topology and Tunnel Modeling July 2020
2) Using Virtual Network
Recall that use case 1 was about setting up a transport service
interconnecting customer network elements C-R2 and C-R5 across the
transport network. With the Virtual Network 2 in place, the client
could have used the Virtual Network's TE topology to select a TE path
for the service. The TE Tunnel model based NBI allows for the client
to specify the Virtual Network's TE topology ID, as well, as the
selected TE path (for example, as marked in Figure 45) as a
configured path attribute in the transport service configuration
request to ensure that the intended transport network resources are
used for the service.
Figure 45. Transport service TE path is selected on Virtual Network's
TE topology
3. Security Considerations
This document does not define networking protocols and data, hence
are not directly responsible for security risks.
4. IANA Considerations
This document has no actions for IANA.
Bryskin, et al. Expires January 12, 2021 [Page 87]
Internet-Draft TE Topology and Tunnel Modeling July 2020
5. References
5.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.ietf-teas-yang-te-topo]
Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
O. Dios, "YANG Data Model for TE Topologies", draft-ietf-
teas-yang-te-topo-15 (work in progress), February 2018.
[I-D.ietf-teas-yang-te]
Saad, T., Gandhi, R., Liu, X., Beeram, V., Shah, H., and I.
Bryskin, "A YANG Data Model for Traffic Engineering Tunnels
and Interfaces", draft-ietf-teas-yang-te-13 (work in
progress), March 2018.
5.2. Informative References
[RFC2702] Awduche, D., "Requirements for Traffic Engineering Over
MPLS", RFC 2702, September 1999.
6. Acknowledgments
TBD.
Bryskin, et al. Expires January 12, 2021 [Page 88]
Internet-Draft TE Topology and Tunnel Modeling July 2020
Appendix A. Data Examples
This section contains examples of an instance data in the JSON
encoding [RFC7951].
A.1. Use Case 1
In the use case described in Section 2.1. , there are three provider
network domains, each of them is represented as an abstract TE
topology. The JSON encoded example data configurations for the three
domains are:
A.1.1. Domain 1
{
"networks": {
"network": [
{
"network-types": {
"te-topology": {}
},
"network-id": "otn-domain1-abs",
"provider-id": 201,
"client-id": 300,
"te-topology-id": "te-topology:otn-domain1-abs",
"node": [
{
"node-id": "D1",
"te-node-id": "2.0.1.1",
"te": {
"te-node-attributes": {
"domain-id" : 1,
"is-abstract": [null],
"underlay-topology": "domain1-och",
"connectivity-matrices": {
"is-allowed": true,
"path-constraints": {
"bandwidth-generic": {
"te-bandwidth": {
"otn": [
{
"rate-type": "odu1",
"counter": 2
Bryskin, et al. Expires January 12, 2021 [Page 89]
Internet-Draft TE Topology and Tunnel Modeling July 2020
}
]
}
}
}
"connectivity-matrix": [
{
"id": 10302,
"from": "1-0-3",
"to": "1-2-0"
},
{
"id": 10203,
"from": "1-0-2",
"to": "1-3-0"
},
{
"id": 10311,
"from": "1-0-3",
"to": "1-11-0"
},
{
"id": 11103,
"from": "1-0-11",
"to": "1-3-0"
},
{
"id": 10903,
"from": "1-0-9",
"to": "1-3-0"
},
{
"id": 10309,
"from": "1-0-3",
"to": "1-9-0"
},
{
"id": 10910,
"from": "1-0-9",
"to": "1-10-0"
},
Bryskin, et al. Expires January 12, 2021 [Page 90]
Internet-Draft TE Topology and Tunnel Modeling July 2020
{
"id": 11009,
"from": "1-0-10",
"to": "1-9-0"
},
{
"id": 20910,
"from": "1-1-9",
"to": "1-10-0"
},
{
"id": 21009,
"from": "1-0-10",
"to": "1-9-1"
},
{
"id": 20911,
"from": "1-1-9",
"to": "1-11-0"
},
{
"id": 21109,
"from": "1-0-11",
"to": "1-9-1"
}
]
}
}
},
"termination-point": [
{
"tp-id": "1-0-3",
"te-tp-id": 10003
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
Bryskin, et al. Expires January 12, 2021 [Page 91]
Internet-Draft TE Topology and Tunnel Modeling July 2020
},
{
"tp-id": "1-3-0",
"te-tp-id": 10300
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "1-0-9",
"te-tp-id": 10009
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "1-9-0",
"te-tp-id": 10900
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "1-1-9",
"te-tp-id": 10109
"te": {
Bryskin, et al. Expires January 12, 2021 [Page 92]
Internet-Draft TE Topology and Tunnel Modeling July 2020
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "1-9-1",
"te-tp-id": 10901
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "1-0-2",
"te-tp-id": 10002
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "1-2-0",
"te-tp-id": 10200
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
Bryskin, et al. Expires January 12, 2021 [Page 93]
Internet-Draft TE Topology and Tunnel Modeling July 2020
]
}
},
{
"tp-id": "1-0-10",
"te-tp-id": 10010
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "1-10-0",
"te-tp-id": 11000
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "1-0-11",
"te-tp-id": 10011
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "1-11-0",
Bryskin, et al. Expires January 12, 2021 [Page 94]
Internet-Draft TE Topology and Tunnel Modeling July 2020
"te-tp-id": 11100
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "1-1-11",
"te-tp-id": 10111
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "1-11-1",
"te-tp-id": 11101
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
}
]
}
]
}
]
}
}
Bryskin, et al. Expires January 12, 2021 [Page 95]
Internet-Draft TE Topology and Tunnel Modeling July 2020
A.1.2. Domain 2
{
"networks": {
"network": [
{
"network-types": {
"te-topology": {}
},
"network-id": "otn-domain2-abs",
"provider-id": 202,
"client-id": 300,
"te-topology-id": "te-topology:otn-domain2-abs",
"node": [
{
"node-id": "D2",
"te-node-id": "2.0.2.2",
"te": {
"te-node-attributes": {
"is-abstract": [null],
"underlay-topology": "domain2-och",
"connectivity-matrices": {
"is-allowed": true,
"path-constraints": {
"bandwidth-generic": {
"te-bandwidth": {
"otn": [
{
"rate-type": "odu1",
"counter": 2
}
]
}
}
}
"connectivity-matrix": [
{
"id": 12125,
"from": "1-0-21",
"to": "1-25-0"
},
Bryskin, et al. Expires January 12, 2021 [Page 96]
Internet-Draft TE Topology and Tunnel Modeling July 2020
{
"id": 12521,
"from": "1-0-25",
"to": "1-21-0"
},
{
"id": 12128,
"from": "1-0-21",
"to": "1-28-0"
},
{
"id": 12821,
"from": "1-0-28",
"to": "1-21-0"
},
{
"id": 12231,
"from": "1-0-22",
"to": "1-31-0"
},
{
"id": 13122,
"from": "1-0-31",
"to": "1-22-0"
},
{
"id": 22228,
"from": "1-1-22",
"to": "1-28-0"
},
{
"id": 22822,
"from": "1-0-28",
"to": "1-22-1"
},
{
"id": 12528,
"from": "1-0-25",
"to": "1-28-0"
},
{
Bryskin, et al. Expires January 12, 2021 [Page 97]
Internet-Draft TE Topology and Tunnel Modeling July 2020
"id": 12825,
"from": "1-0-28",
"to": "1-25-0"
}
]
}
}
},
"termination-point": [
{
"tp-id": "1-0-21",
"te-tp-id": 10021
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "1-21-0",
"te-tp-id": 12100
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "1-0-22",
"te-tp-id": 10022
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
Bryskin, et al. Expires January 12, 2021 [Page 98]
Internet-Draft TE Topology and Tunnel Modeling July 2020
}
]
}
},
{
"tp-id": "1-22-0",
"te-tp-id": 12200
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "1-1-22",
"te-tp-id": 10122
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "1-22-1",
"te-tp-id": 12201
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
Bryskin, et al. Expires January 12, 2021 [Page 99]
Internet-Draft TE Topology and Tunnel Modeling July 2020
"tp-id": "1-0-25",
"te-tp-id": 10025
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "1-25-0",
"te-tp-id": 12500
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "1-1-25",
"te-tp-id": 10125
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "1-25-1",
"te-tp-id": 12501
"te": {
"interface-switching-capability": [
{
Bryskin, et al. Expires January 12, 2021 [Page 100]
Internet-Draft TE Topology and Tunnel Modeling July 2020
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "1-0-28",
"te-tp-id": 10028
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "1-28-0",
"te-tp-id": 12800
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "1-0-31",
"te-tp-id": 10031
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
Bryskin, et al. Expires January 12, 2021 [Page 101]
Internet-Draft TE Topology and Tunnel Modeling July 2020
},
{
"tp-id": "1-31-0",
"te-tp-id": 13100
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
}
]
}
]
}
]
}
}
A.1.3. Domain 3
{
"networks": {
"network": [
{
"network-types": {
"te-topology": {}
},
"network-id": "otn-domain3-abs",
"provider-id": 203,
"client-id": 300,
"te-topology-id": "te-topology:otn-domain3-abs",
"node": [
{
"node-id": "D3",
"te-node-id": "2.0.3.3",
"te": {
"te-node-attributes": {
"is-abstract": [null],
Bryskin, et al. Expires January 12, 2021 [Page 102]
Internet-Draft TE Topology and Tunnel Modeling July 2020
"underlay-topology": "domain3-och",
"connectivity-matrices": {
"is-allowed": true,
"path-constraints": {
"bandwidth-generic": {
"te-bandwidth": {
"otn": [
{
"rate-type": "odu1",
"counter": 2
}
]
}
}
}
"connectivity-matrix": [
{
"id": 13638,
"from": "1-0-38",
"to": "1-38-0"
},
{
"id": 13836,
"from": "1-0-38",
"to": "1-36-0"
},
{
"id": 13639,
"from": "1-0-36",
"to": "1-39-0"
},
{
"id": 13936,
"from": "1-0-39",
"to": "1-36-0"
},
{
"id": 23636,
"from": "1-0-36",
"to": "1-36-1"
},
Bryskin, et al. Expires January 12, 2021 [Page 103]
Internet-Draft TE Topology and Tunnel Modeling July 2020
{
"id": 33636,
"from": "1-1-36",
"to": "1-36-0"
},
{
"id": 13739,
"from": "1-0-37",
"to": "1-39-0"
},
{
"id": 13937,
"from": "1-0-39",
"to": "1-37-0"
},
{
"id": 23737,
"from": "1-0-37",
"to": "1-37-1"
},
{
"id": 33737,
"from": "1-1-37",
"to": "1-37-0"
}
]
}
}
},
"termination-point": [
{
"tp-id": "1-0-36",
"te-tp-id": 10036
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
Bryskin, et al. Expires January 12, 2021 [Page 104]
Internet-Draft TE Topology and Tunnel Modeling July 2020
},
{
"tp-id": "1-36-0",
"te-tp-id": 13600
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "1-0-37",
"te-tp-id": 10037
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "1-37-0",
"te-tp-id": 13700
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "1-1-37",
"te-tp-id": 10137
"te": {
Bryskin, et al. Expires January 12, 2021 [Page 105]
Internet-Draft TE Topology and Tunnel Modeling July 2020
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "1-37-1",
"te-tp-id": 13701
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "1-0-39",
"te-tp-id": 10039
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "1-39-0",
"te-tp-id": 13900
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
Bryskin, et al. Expires January 12, 2021 [Page 106]
Internet-Draft TE Topology and Tunnel Modeling July 2020
]
}
},
{
"tp-id": "1-0-36",
"te-tp-id": 10036
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "1-36-0",
"te-tp-id": 13600
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "1-0-38",
"te-tp-id": 10038
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "1-38-0",
Bryskin, et al. Expires January 12, 2021 [Page 107]
Internet-Draft TE Topology and Tunnel Modeling July 2020
"te-tp-id": 13800
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
}
]
}
]
}
]
}
}
Contributors
Italo Busi
Huawei
Email: italo.busi@huawei.com
Sergio Belotti
Nokia
Email: sergio.belotti@nokia.com
Authors' Addresses
Igor Bryskin
Individual
Email: i_bryskin@yahoo.com
Vishnu Pavan Beeram
Juniper Networks
Email: vbeeram@juniper.net
Tarek Saad
Juniper Networks
Email: tsaad@juniper.net
Bryskin, et al. Expires January 12, 2021 [Page 108]
Internet-Draft TE Topology and Tunnel Modeling July 2020
Xufeng Liu
Volta Networks
Email: xufeng.liu.ietf@gmail.com
Bryskin, et al. Expires January 12, 2021 [Page 109]
