| Internet-Draft | Service Path Computation | July 2024 |
| Yu, et al. | Expires 9 January 2025 | [Page] |
This document defines a YANG data model for client signal service's path computation and path management.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://YuChaode.github.io/draft-ybb-ccamp-service-path-computation/draft-ybb-ccamp-service-path-computation.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ybb-ccamp-service-path-computation/.¶
Discussion of this document takes place on the Common Control and Measurement Plane Working Group mailing list (mailto:ccamp@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ccamp/. Subscribe at https://www.ietf.org/mailman/listinfo/ccamp/.¶
Source for this draft and an issue tracker can be found at https://github.com/YuChaode/draft-ybb-ccamp-service-path-computation.¶
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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
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."¶
This Internet-Draft will expire on 9 January 2025.¶
Copyright (c) 2024 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
For transport technology, the service's path is hierarchical, including OTN-layer trails and WDM-layer trails. According to the funcational structure defined by ITU-T, the OTN-layer trails include lower-order ODUk, high-order ODUk and OTUk trails. The WDM-lay trails include OTS, OMS and OCh trail. These trails and the configuration of client-side port configuration form an end-to-end client signal service.¶
Path computation is a common network management funcation. For traditional transport services, OTS and OMS trails are automatically generated once the fibers are connected and they don't require any path computation. The path computation is performed on the OCh layer trails and above. Traditionally, the path computation is performed from OCh to low-order ODUk trail layer by layer. This is called bottom-up approach.¶
One disavantage of bottom-up approach is that the client and server need to interact with each other multiple times. And sometimes, the client layer trail cannot be computed until the server layer trail is setup. This doea not comply with the intention of path computation which will not introduce actual configuration on the network.¶
In addition, the client prefers to transfer intent-based configuration instead of complex network configuration to achieve path computation and obtain all the layers' path computation result at one time. The server, usually it is played by the domain controller, can help to deal with the complex network configuration computation. This is called top-down approach.¶
This document focuses on the top-down path computation for transparent client signal service and non-transparent client signal service (Ethernet service).¶
We also focus on addressing some undiscussed requirements, such as how to ultize a generic structure to display path information for all the layers' path at once, and how to specify some parameters on the server layer's trail in the service path computation request, and how to support more complex path constraints, and how to manage the path computation results and how to reference them in service provisioning request.¶
The following terms are defined in [RFC7950] and are not redefined here:¶
The terminology for describing YANG data models is found in [RFC7950].¶
A simplified graphical representation of the data model is used in Section 4 of this document. The meaning of the symbols in this diagram is defined in [RFC8340].¶
In this document, names of data nodes and other data model objects are prefixed using the standard prefix associated with the corresponding YANG imported modules, as shown in the following table.¶
| Prefix | Yang Module | Reference |
|---|---|---|
| clnt-svc | ietf-trans-client-service | [RFCYYYY] |
| clnt-svc-pc | ietf-trans-client-path-computation | RFC XXXX |
RFC Editor Note: Please replace XXXX with the number assigned to the RFC once this draft becomes an RFC. Please replace YYYY with the RFC numbers assigned to [I-D.ietf-ccamp-client-signal-yang]. Please remove this note.¶
The hierarchical relationship of transport client signal service can reference to Figure 1: (Please note that, the OTN tunnels in this figure and subsequent figures include lower order OTN tunnels, higher order OTN tunnels, and OTU tunnels. The supporting relationship should comply with ITU-T G.XXXX definition. WDM tunnel also include the WDM, flexi-grid scenario and Media channel scenario. The hierarchical relationship should comply with ITU-T G.XXXX definition.)¶
|<----------Transparent client signal---------->|
|<--------------OTN Tunnel---------->|
|<------------WDM Tunnel-------->|
For Ethernet client signal service, the client signal can be encapsulated into multiple approach. For example, it can be encapsulated into OTN tunnel directly, or it can be encapsulated into MPLS-TP/SDH tunnels and then into OTN tunnels. Note that the SDH tunnel is considered as an outdated technology and lacks standardization. Therefore, the scenario where Ethernet client signals are encapsulated into the SDH tunnel is not described in this document. The Figure 2 shows the hierarchical relationship of Ethernet service:¶
|<----------Ethernet client signal---------->|
|<----MPLS-TP Tunnel (Optional) ----->|
|<-----------OTN Tunnel----------->|
|<---------WDM Tunnel--------->|
The reference method is defined in the [I-D.ietf-ccamp-client-signal-yang]. The supporting relationship between the tunnels can be also found by the dependency-tunnel structure define by the [I-D.ietf-teas-yang-te].¶
For the Top-down approach, the path computation request should be based on client signal service. It is needed to specify the source and destination access port of in the request. In addition, some common parameters, such as number of path to be calculated, protection and restoration capabities, path computation policy and path constraint (see Section 3.3).etc. And then the domain controller will trigger the computation on all the layers. The path computation result should contain all the layers' path information. For the OTN tunnel and WDM tunnel in the service path computation result, they can be non-existing before service path compuation and can be totally designed by the domain controller or control plane. The tunnels can also be existing before the service computation request. The domain controller can design to reuse some existing tunnels based on the consideration of maximum resource utilization. Similar to TE tunnel path computation, service path computation should not create any tunnels on the network during the whole computation process, and will not introduce any other changes on the network.¶
module: ietf-trans-client-service-path-computation
rpcs:
+---x client-service-precompute
+--ro input
| +--ro request* [request-id]
| +--ro request-id string
| +--ro path-count? uint8
| +--ro te-topology-identifier
| +--ro src-access-ports
| +--ro dst-access-ports
| +--ro tunnel-policy
| | +--ro protection
| | +--ro restoration
| | +--ro optimizations
| +--ro explicit-route-exclude-objects
| | +--ro route-object-exclude-object* [index]
| +--ro explicit-route-include-objects
| +--ro route-object-include-object* [index]
+--ro output
+--ro result* [request-id]
+--ro request-id string
+--ro result-code? enumeration
+--ro (result-detail)?
+--:(failure)
| +--ro failure-reason? uint32
| +--ro error-message? string
+--:(success)
+--ro computed-paths* [path-id]
| +--ro path-id yang:uuid
| +--ro path-number? uint8
+--ro te-topology-identifier
+--ro src-access-ports
+--ro dst-access-ports
+--ro underlay-tunnels
+--ro underlay-tunnel* [index]
+--ro index uint8
+--ro tunnel-name? leafref
+--ro te-topology-identifier
+--ro computed-lsp* [lsp-id]
+--ro lsp-id uint8
+--ro lsp-type? enumeration
+--ro lsp-metrics
| +--ro lsp-metric* [metric-type]
+--ro lsp-route-objects* [index]
¶
For the MDSC, if it wants to show the whole information of computed path, the path computation result provided by the domain controller must contain tunnels at all the layers. The number of these tunnels is not fixed. For example, for OTN tunnel, the client signal can be encapsulated into a low order OTN tunnel at first, and then be multiplexed into a higher OTN tunnel. The client signal can be encapsulated into a high order OTN tunnel directly without the multiplexing scenario. There is another common scenario that an OTN tunnel is supported by multiple WDM tunnels. This document provides a generic structure in a list to present the actual path information regardless which layer it is. The tunnels will be ordered by index from 0 for the topmost tunnel. The correlation with server tunnel will be provided by the "server-tunnel" attribute in the LSP hop.¶
............................
+--ro underlay-tunnels
+--ro underlay-tunnel* [index]
+--ro index uint8
+--ro tunnel-name? leafref
+--ro te-topology-identifier
| +--ro provider-id? te-types:te-global-id
| +--ro client-id? te-types:te-global-id
| +--ro topology-id? te-types:te-topology-id
+--ro computed-lsp* [lsp-id]
+--ro lsp-id uint8
+--ro lsp-type? enumeration
+--ro lsp-metrics
| +--ro lsp-metric* [metric-type]
| +--ro metric-type identityref
| +--ro metric-value? uint32
| +--ro metric-unit? string
+--ro lsp-route-objects* [index]
+--ro index uint8
+--ro node-id? te-types:te-node-id
+--ro node-uri-id? yang:uuid
+--ro link-tp-id? te-types:te-tp-id
+--ro ltp-uri-id? yang:uuid
+--ro te-label
| +--ro (technology)?
| | +--:(wson)
| | | +--ro (grid-type)?
| | | +--:(dwdm)
| | | | +--ro (single-or-super-channel)?
| | | | +--:(single)
| | | | | +--ro dwdm-n?
l0-types:dwdm-n
| | | | +--:(super)
| | | | +--ro subcarrier-dwdm-n*
l0-types:dwdm-n
| | | +--:(cwdm)
| | | +--ro cwdm-n? l0-types:cwdm-n
| | +--:(otn)
| | +--ro otn
| | +--ro tpn? otn-tpn
| | +--ro tsg? identityref
| | +--ro ts-list? string
| +--ro direction? te-types:te-label-direction
+--ro server-tunnel? leafref
¶
It is common for service path computation request to specify path constrain like node/link-tp inclusion/exclusion like TE tunnel path computation. And service path computation needs to support some more kind of path constraint, such as to specify service/tunnel/path included/excluded. There are also scenarios to specify path constrain across layers. For example, some people would like to specify a WDM node included/excluded or wavelength in the service path computation.¶
................................ +--ro route-object-include-object* [index] +--ro index uint8 +--ro node-id? te-types:te-node-id +--ro node-uri-id? yang:uuid +--ro link-tp-id? te-types:te-tp-id +--ro ltp-uri-id? yang:uuid +--ro te-label | +--ro (technology)? | | +--:(wson) | | | +--ro (grid-type)? | | | +--:(dwdm) | | | | +--ro (single-or-super-channel)? | | | | +--:(single) | | | | | +--ro dwdm-n? l0-types:dwdm-n | | | | +--:(super) | | | | +--ro subcarrier-dwdm-n* l0-types:dwdm-n | | | +--:(cwdm) | | | +--ro cwdm-n? l0-types:cwdm-n | | +--:(otn) | | +--ro otn | | +--ro tpn? otn-tpn | | +--ro tsg? identityref | | +--ro ts-list? string | +--ro direction? te-types:te-label-direction +--ro server-tunnel-name? leafref +--ro lsp-type? enumeration¶
### Storage of Path Computation Result It is useful to save the path computation results after they are return. Sometimes, people from operators will make the decision on the results in a short time. If the path is not saved in the domain controller, the MDSC needs to send the full path in the service creation request which is complex. So in this document, we recommend that the domain controller should be capable of saving path computation results to make it possible that the MDSC can reference the path computation result in service creation request. The path information in the path management structure should be same with the output of service path computation RPC. Once there is a RPC succeed in operating, the path management structure will add one more item. It is noted that the path computation result is not required to be saved forever in the domain controller. How long could it be saved is implementation-specific. But if the path has been adopted by a service creation request, including path inclusion/exclusion, the path can not be deleted from data store.¶
Note: the service path computation request is defined as an RPC, which is stateless. According to the requirement of RESTCONF, RPC should not generate any impact on the data model. So it is recommended to discuss with RESTCONF protocol expert to find a workaround solution.¶
module: ietf-trans-client-service-path-computation
+--rw path-management
+--rw path* [path-id]
+--rw path-id yang:uuid
+--rw creation-time? yang:date-and-time
+--rw validity-period? uint8
+--rw underlay-tunnels
+--rw underlay-tunnel* [index]
+--rw index uint8
+--rw tunnel-name? leafref
+--rw te-topology-identifier
| +--rw provider-id? te-types:te-global-id
| +--rw client-id? te-types:te-global-id
| +--rw topology-id? te-types:te-topology-id
+--rw computed-lsp* [lsp-id]
+--rw lsp-id uint8
+--rw lsp-type? enumeration
+--rw lsp-metrics
| +--rw lsp-metric* [metric-type]
| +--rw metric-type identityref
| +--rw metric-value? uint32
| +--rw metric-unit? string
+--rw lsp-route-objects* [index]
+--rw index uint8
+--rw node-id? te-types:te-node-id
+--rw node-uri-id? yang:uuid
+--rw link-tp-id? te-types:te-tp-id
+--rw ltp-uri-id? yang:uuid
+--rw te-label
| +--rw (technology)?
| | +--:(wson)
| | | +--rw (grid-type)?
| | | +--:(dwdm)
| | | | +--rw (single-or-super-channel)?
| | | | +--:(single)
| | | | | +--rw dwdm-n?
l0-types:dwdm-n
| | | | +--:(super)
| | | | +--rw subcarrier-dwdm-n*
l0-types:dwdm-n
| | | +--:(cwdm)
| | | +--rw cwdm-n?
l0-types:cwdm-n
| | +--:(otn)
| | +--rw otn
| | +--rw tpn? otn-tpn
| | +--rw tsg? identityref
| | +--rw ts-list? string
| +--rw direction?
te-types:te-label-direction
+--rw server-tunnel? leafref
¶
In the current service provisioning approach, the MDSC needs to specify the correlation of tunnel underlay. If the path computation result is saved in the domain controller. It is much easier to reference the path computation result instead of specifying tunnel underlay to do the provisioning.¶
To be added¶
module: ietf-trans-client-service-path-computation
+--rw path-management
+--rw path* [path-id]
+--rw path-id yang:uuid
+--rw creation-time? yang:date-and-time
+--rw validity-period? uint8
+--rw underlay-tunnels
+--rw underlay-tunnel* [index]
+--rw index uint8
+--rw tunnel-name?
| -> /te:te/tunnels/tunnel/name
+--rw te-topology-identifier
| +--rw provider-id? te-global-id
| +--rw client-id? te-global-id
| +--rw topology-id? te-topology-id
+--rw computed-lsp* [lsp-id]
+--rw lsp-id uint8
+--rw lsp-type? enumeration
+--rw lsp-metrics
| +--rw lsp-metric* [metric-type]
| +--rw metric-type identityref
| +--rw metric-value? uint32
| +--rw metric-unit? string
+--rw lsp-route-objects* [index]
+--rw index uint8
+--rw node-id? te-types:te-node-id
+--rw node-uri-id? yang:uuid
+--rw link-tp-id? te-types:te-tp-id
+--rw ltp-uri-id? yang:uuid
+--rw te-label
| +--rw (technology)?
| | +--:(wson)
| | | +--rw (grid-type)?
| | | +--:(dwdm)
| | | | +--rw (single-or-super-channel)?
| | | | +--:(single)
| | | | | +--rw dwdm-n?
| | | | | l0-types:dwdm-n
| | | | +--:(super)
| | | | +--rw subcarrier-dwdm-n*
| | | | l0-types:dwdm-n
| | | +--:(cwdm)
| | | +--rw cwdm-n?
| | | l0-types:cwdm-n
| | +--:(otn)
| | +--rw otn-label
| | +--rw tpn? otn-tpn
| | +--rw tsg? identityref
| | +--rw ts-list? string
| +--rw direction?
| te-types:te-label-direction
+--rw server-tunnel? -> ../../../index
rpcs:
+---x client-service-precompute
+---w input
| +---w request* [request-id]
| +---w request-id string
| +---w path-count? uint8
| +---w te-topology-identifier
| | +---w provider-id? te-global-id
| | +---w client-id? te-global-id
| | +---w topology-id? te-topology-id
| +---w src-access-ports
| | +---w access-node-id? te-types:te-node-id
| | +---w access-node-uri? nw:node-id
| | +---w access-ltp-id? te-types:te-tp-id
| | +---w access-ltp-uri? nt:tp-id
| | +---w client-signal? identityref
| +---w dst-access-ports
| | +---w access-node-id? te-types:te-node-id
| | +---w access-node-uri? nw:node-id
| | +---w access-ltp-id? te-types:te-tp-id
| | +---w access-ltp-uri? nt:tp-id
| | +---w client-signal? identityref
| +---w tunnel-policy
| | +---w protection
| | | +---w protection-type? identityref
| | | +---w protection-reversion-disable? boolean
| | | +---w hold-off-time? uint32
| | | +---w wait-to-revert? uint16
| | | +---w aps-signal-id? uint8
| | +---w restoration
| | | +---w restoration-type? identityref
| | | +---w restoration-scheme? identityref
| | | +---w restoration-reversion-disable? boolean
| | | +---w hold-off-time? uint32
| | | +---w wait-to-restore? uint16
| | | +---w wait-to-revert? uint16
| | +---w share-timeslot? boolean
| | +---w optimizations
| | +---w (algorithm)?
| | | +--:(metric)
| | | +---w optimization-metric* [metric-type]
| | | +---w metric-type identityref
| | | +---w weight? uint8
| | +---w lsp-type? enumeration
| | +---w path-metric-bounds
| | +---w path-metric-bound* [metric-type]
| | +---w metric-type identityref
| | +---w upper-bound? uint64
| +---w explicit-route-exclude-objects
| | +---w route-object-exclude-object* [index]
| | +---w index uint8
| | +---w node-id? te-types:te-node-id
| | +---w node-uri-id? yang:uuid
| | +---w link-tp-id? te-types:te-tp-id
| | +---w ltp-uri-id? yang:uuid
| | +---w te-label
| | | +---w (technology)?
| | | | +--:(wson)
| | | | | +---w (grid-type)?
| | | | | +--:(dwdm)
| | | | | | +---w (single-or-super-channel)?
| | | | | | +--:(single)
| | | | | | | +---w dwdm-n?
| | | | | | | l0-types:dwdm-n
| | | | | | +--:(super)
| | | | | | +---w subcarrier-dwdm-n*
| | | | | | l0-types:dwdm-n
| | | | | +--:(cwdm)
| | | | | +---w cwdm-n?
| | | | | l0-types:cwdm-n
| | | | +--:(otn)
| | | | +---w otn-label
| | | | +---w tpn? otn-tpn
| | | | +---w tsg? identityref
| | | | +---w ts-list? string
| | | +---w direction?
| | | te-types:te-label-direction
| | +---w server-tunnel-name?
| | | -> /te:te/tunnels/tunnel/name
| | +---w lsp-type? enumeration
| +---w explicit-route-include-objects
| +---w route-object-include-object* [index]
| +---w index uint8
| +---w node-id? te-types:te-node-id
| +---w node-uri-id? yang:uuid
| +---w link-tp-id? te-types:te-tp-id
| +---w ltp-uri-id? yang:uuid
| +---w te-label
| | +---w (technology)?
| | | +--:(wson)
| | | | +---w (grid-type)?
| | | | +--:(dwdm)
| | | | | +---w (single-or-super-channel)?
| | | | | +--:(single)
| | | | | | +---w dwdm-n?
| | | | | | l0-types:dwdm-n
| | | | | +--:(super)
| | | | | +---w subcarrier-dwdm-n*
| | | | | l0-types:dwdm-n
| | | | +--:(cwdm)
| | | | +---w cwdm-n?
| | | | l0-types:cwdm-n
| | | +--:(otn)
| | | +---w otn-label
| | | +---w tpn? otn-tpn
| | | +---w tsg? identityref
| | | +---w ts-list? string
| | +---w direction?
| | te-types:te-label-direction
| +---w server-tunnel-name?
| | -> /te:te/tunnels/tunnel/name
| +---w lsp-type? enumeration
+--ro output
+--ro result* [request-id]
+--ro request-id string
+--ro result-code? enumeration
+--ro (result-detail)?
+--:(failure)
| +--ro failure-reason? uint32
| +--ro error-message? string
+--:(success)
+--ro computed-paths* [path-id]
| +--ro path-id yang:uuid
| +--ro path-number? uint8
+--ro te-topology-identifier
| +--ro provider-id? te-global-id
| +--ro client-id? te-global-id
| +--ro topology-id? te-topology-id
+--ro src-access-ports
| +--ro access-node-id? te-types:te-node-id
| +--ro access-node-uri? nw:node-id
| +--ro access-ltp-id? te-types:te-tp-id
| +--ro access-ltp-uri? nt:tp-id
| +--ro client-signal? identityref
+--ro dst-access-ports
| +--ro access-node-id? te-types:te-node-id
| +--ro access-node-uri? nw:node-id
| +--ro access-ltp-id? te-types:te-tp-id
| +--ro access-ltp-uri? nt:tp-id
| +--ro client-signal? identityref
+--ro underlay-tunnels
+--ro underlay-tunnel* [index]
+--ro index uint8
+--ro tunnel-name?
| -> /te:te/tunnels/tunnel/name
+--ro te-topology-identifier
| +--ro provider-id? te-global-id
| +--ro client-id? te-global-id
| +--ro topology-id? te-topology-id
+--ro computed-lsp* [lsp-id]
+--ro lsp-id uint8
+--ro lsp-type? enumeration
+--ro lsp-metrics
| +--ro lsp-metric* [metric-type]
| +--ro metric-type identityref
| +--ro metric-value? uint32
| +--ro metric-unit? string
+--ro lsp-route-objects* [index]
+--ro index uint8
+--ro node-id?
| te-types:te-node-id
+--ro node-uri-id? yang:uuid
+--ro link-tp-id?
| te-types:te-tp-id
+--ro ltp-uri-id? yang:uuid
+--ro te-label
| +--ro (technology)?
| | +--:(wson)
| | | +--ro (grid-type)?
| | | +--:(dwdm)
| | | | +--ro (single-or-super-channel)?
| | | | +--:(single)
| | | | | +--ro dwdm-n?
| | | | | l0-types:dwdm-n
| | | | +--:(super)
| | | | +--ro subcarrier-dwdm-n*
| | | | l0-types:dwdm-n
| | | +--:(cwdm)
| | | +--ro cwdm-n?
| | | l0-types:cwdm-n
| | +--:(otn)
| | +--ro otn-label
| | +--ro tpn? otn-tpn
| | +--ro tsg?
| | | identityref
| | +--ro ts-list? string
| +--ro direction?
| te-types:te-label-direction
+--ro server-tunnel?
-> ../../../index
<CODE BEGINS> file "ietf-trans-client-service-path-computation@2024-07-07.yang"
module ietf-trans-client-service-path-computation {
/* TODO: FIXME */
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-trans-client-service-path-computation";
prefix "clntsvc-cpt";
import ietf-trans-client-service {
prefix "clntsvc";
reference "draft-ietf-ccamp-client-signal-yang";
}
import ietf-te-types {
prefix "te-types";
reference "RFC 8776 - Traffic Engineering Common YANG Types";
}
import ietf-yang-types {
prefix "yang";
reference "RFC 6991 - Common YANG Data Types";
}
import ietf-layer1-types {
prefix l1-types;
reference "RFC ZZZZ - A YANG Data Model for Layer 1 Types";
}
import ietf-layer0-types {
prefix l0-types;
}
import ietf-te {
prefix "te";
}
organization
"Internet Engineering Task Force (IETF) CCAMP WG";
contact
"
ID-draft editor:
Chaode Yu (yuchaode@huawei.com);
Sergio Belotti (sergio.belotti@nokia.com);
Italo Busi (italo.busi@huawei.com);
Aihua Guo (aihuaguo.ietf@gmail.com);
Dieter Beller (dieter.beller@nokia.com);
";
description
"This module defines a YANG data model for describing
transport network client services. The model fully conforms
to the Network Management Datastore Architecture (NMDA).
Copyright (c) 2021 IETF Trust and the persons
identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
revision 2024-07-07 {
description
"initial version";
reference
"draft-ybb-ccamp-service-path-computation";
}
container path-management {
list path {
key path-id;
leaf path-id {
type yang:uuid;
}
leaf creation-time {
type yang:date-and-time;
}
leaf validity-period {
type uint8;
units "minute";
}
container underlay-tunnels {
list underlay-tunnel {
key index;
leaf index {
description
"The tunnels underlay should be ordered by their
supproting relationship. The client layer tunnels
should use smaller index.";
type uint8;
}
leaf tunnel-name {
type leafref {
path "/te:te/te:tunnels/te:tunnel/te:name";
}
description
"the computed result can route with some existing
TE tunnels. The tunnel-name is the identifier of
tunnel. If the tunnel is not created, this
parameter is not needed to provide.";
}
uses te-types:te-topology-identifier;
list computed-lsp {
key lsp-id;
leaf lsp-id {
type uint8;
}
leaf lsp-type {
type enumeration {
enum forwarding-working;
enum forwarding-protection;
enum reverse-working;
enum reverse-protection;
}
}
container lsp-metrics {
list lsp-metric {
key metric-type;
leaf metric-type {
type identityref {
base te-types:path-metric-type;
}
}
leaf metric-value {
type uint32;
}
leaf metric-unit {
type string;
}
}
}
list lsp-route-objects {
key index;
leaf index {
type uint8;
}
uses hop-infomation;
leaf server-tunnel {
type leafref {
path "../../../index";
}
}
}
}
}
}
}
}
rpc client-service-precompute {
input {
list request {
key "request-id";
leaf request-id {
type string;
}
leaf path-count {
type uint8 {
range "1..10";
}
}
uses te-types:te-topology-identifier;
container src-access-ports {
description
"Source access port of a client service.";
uses clntsvc:client-svc-access-parameters;
}
container dst-access-ports {
description
"Destination access port of a client service.";
uses clntsvc:client-svc-access-parameters;
}
uses tunnel-policy-grouping;
uses path-constraints;
}
}
output {
list result {
key "request-id";
leaf request-id {
type string;
}
leaf result-code {
type enumeration {
enum success {
}
enum failure {
}
}
}
choice result-detail {
case failure {
uses failure-info-grouping;
}
case success {
list computed-paths {
key path-id;
leaf path-id {
type yang:uuid;
}
leaf path-number {
type uint8;
description
"when the client requestes to compute multiple paths
for a service, this path-number can be used to rank
the path result, based on the path computation
policy. The path-number starts with 0 and 0
indicates the best option. The better path's
path-number should be in lower number.";
}
}
uses te-types:te-topology-identifier;
container src-access-ports {
description
"Source access port of a client service.";
uses clntsvc:client-svc-access-parameters;
}
container dst-access-ports {
description
"Destination access port of a client service.";
uses clntsvc:client-svc-access-parameters;
}
container underlay-tunnels {
list underlay-tunnel {
key index;
description
"The server could support all the layers of tunnels
under the client signal service. If it cannot
support that, it should return its topmost layer
tunnel's path infomation";
leaf index {
description
"The tunnels underlay should be ordered by their
supproting relationship. The client layer tunnels
should use smaller index.";
type uint8;
}
leaf tunnel-name {
type leafref {
path "/te:te/te:tunnels/te:tunnel/te:name";
}
description
"the computed result can route with some existing
TE tunnels. The tunnel-name is the identifier of
tunnel. If the tunnel is not created, this
parameter is not needed to provide.";
}
uses te-types:te-topology-identifier;
list computed-lsp {
key lsp-id;
leaf lsp-id {
type uint8;
}
leaf lsp-type {
type enumeration {
enum forwarding-working;
enum forwarding-protection;
enum reverse-working;
enum reverse-protection;
}
}
container lsp-metrics {
list lsp-metric {
key metric-type;
leaf metric-type {
type identityref {
base te-types:path-metric-type;
}
}
leaf metric-value {
type uint32;
}
leaf metric-unit {
type string;
}
}
}
list lsp-route-objects {
key index;
leaf index {
type uint8;
}
uses hop-infomation;
leaf server-tunnel {
type leafref {
path "../../../index";
}
}
}
}
}
}
}
}
}
}
}
grouping hop-infomation {
leaf node-id {
type te-types:te-node-id;
description
"The identifier of a node in the TE topology.";
}
leaf node-uri-id {
type yang:uuid;
description
"Another identifier of TE node. This uuid of node may be acquired by inventory.";
}
leaf link-tp-id {
type te-types:te-tp-id;
description
"TE link termination point identifier, used
together with te-node-id to identify the
link termination point";
}
leaf ltp-uri-id {
type yang:uuid;
description
"another identifier of link TP. This uuid of TP may be acquired by inventory.";
}
container te-label {
description
"Container that specifies TE label.";
choice technology {
description
"Data plane technology type.";
case wson {
uses l0-types:wson-label-hop;
}
case otn {
uses l1-types:otn-label-hop;
}
}
leaf direction {
type te-types:te-label-direction;
description "Label direction";
}
}
}
grouping tunnel-policy-grouping {
description "Tunnel creation policy which can be also inherited by client service.";
container tunnel-policy {
uses te:protection-restoration-properties;
leaf share-timeslot {
type boolean;
}
uses path-policy;
}
}
grouping failure-info-grouping {
leaf failure-reason {
type uint32;
}
leaf error-message {
type string;
}
}
grouping path-constraints {
description "";
container explicit-route-exclude-objects {
list route-object-exclude-object {
key index;
uses hop-include-or-exclude-grouping;
}
}
container explicit-route-include-objects {
list route-object-include-object {
key index;
uses hop-include-or-exclude-grouping;
}
}
}
grouping hop-include-or-exclude-grouping {
leaf index {
type uint8;
}
uses hop-infomation;
leaf server-tunnel-name {
type leafref {
path "/te:te/te:tunnels/te:tunnel/te:name";
}
}
leaf lsp-type {
type enumeration {
enum all-paths;
enum forwarding-working;
enum forwarding-protection;
enum reverse-working;
enum reverse-protection;
}
}
}
grouping path-policy {
container optimizations {
choice algorithm {
case metric {
list optimization-metric {
key "metric-type";
leaf metric-type {
type identityref {
base te-types:path-metric-type;
}
description "TE path metric type";
}
leaf weight {
type uint8;
description "TE path metric normalization weight";
}
}
}
}
leaf lsp-type {
type enumeration {
enum all-paths;
enum forwarding-working;
enum forwarding-protection;
enum reverse-working;
enum reverse-protection;
}
}
uses te-types:generic-path-metric-bounds;
}
}
}
<CODE ENDS>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
TODO Security¶
This document has no IANA actions.¶
This document was prepared using kramdown.¶