A YANG Data Model for Service Path Computation

A YANG Data Model for Service Path Computation Huawei Technologies

yuchaode@huawei.com

Nokia

sergio.belotti@nokia.com

Huawei Technologies

italo.busi@huawei.com

Futurewei Technologies

aihuaguo.ietf@gmail.com

Nokia

dieter.beller@nokia.com

Routing Common Control and Measurement Plane next generation unicorn sparkling distributed ledger This document defines a YANG data model for client signal service's path computation and path management. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Common Control and Measurement Plane Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction 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.

Terminology and Notations The following terms are defined in and are not redefined here:

client
server
augment
data model
data node

The terminology for describing YANG data models is found in .

Tree Diagram A simplified graphical representation of the data model is used in of this document. The meaning of the symbols in this diagram is defined in .

Prefix in Data Node Names 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. Prefixes and corresponding YANG modules

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 . Please remove this note.

End to End Management of Transport Network Client Signal Service The hierarchical relationship of transport client signal service can reference to : (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 Service and its Server tunnel | |<--------------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 shows the hierarchical relationship of Ethernet service:

Ethernet Client Signal Service and its Server tunnel | |<----MPLS-TP Tunnel (Optional) ----->| |<-----------OTN Tunnel----------->| |<---------WDM Tunnel--------->| ]]> The reference method is defined in the . The supporting relationship between the tunnels can be also found by the dependency-tunnel structure define by the .

Requirements for Service Path Computation

Top-down Approach 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 ).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.

Multi-layer Path Display 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.

Path Constraint 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.

Path Management ### 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.

Path Reference in Service Provisioning 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.

Tree Diagram for Service Path Computation

YANG Data Model for Service Path Computation

Service Path Computation YANG module

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here.

Security Considerations TODO Security

IANA Considerations This document has no IANA actions.

Normative References The YANG 1.1 Data Modeling Language YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). YANG Tree Diagrams This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. A YANG Data Model for Transport Network Client Signals Huawei Technologies Futurewei Huawei Technologies Cisco Huawei Technologies A transport network is a server-layer network to provide connectivity services to its client. The topology and tunnel information in the transport layer has already been defined by generic Traffic- engineered models and technology-specific models (e.g., OTN, WSON). However, how the client signals are accessing to the network has not been described. These information is necessary to both client and provider. This draft describes how the client signals are carried over transport network and defines YANG data models which are required during configuration procedure. More specifically, several client signal (of transport network) models including ETH, STM-n, FC and so on, are defined in this draft. A YANG Data Model for Traffic Engineering Tunnels, Label Switched Paths, and Interfaces Cisco Systems Inc Cisco Systems Inc Alef Edge Juniper Networks Individual This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels, Label Switched Paths (LSPs), and interfaces. The model covers data that is independent of any technology or dataplane encapsulation and is divided into two YANG modules that cover device-specific, and device independent data. This model covers data for configuration, operational state, remote procedural calls, and event notifications. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

Acknowledgments This document was prepared using kramdown.