]> China Unicom

Beijing China tanyx11@chinaunicom.cn

China Unicom

Beijing China zhengyanlei@chinaunicom.cn

Huawei Technologies

italo.busi@huawei.com

Huawei Technologies

China yuchaode@huawei.com

CAICT

China zhaoxing@caict.ac.cn

Routing Common Control and Measurement Plane next generation unicorn sparkling distributed ledger This document defines YANG data models to describe the topology and tunnel information of a fine grain Optical Transport Network. The YANG data models defined in this document are designed to meet the requirements for efficient transmission of sub-1G client signals in transport network. 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 Optical Transport Networks (OTN) is a mainstream layer 1 technology for the transport network. Over the years, it has continued to evolve, to improve its transport functions for the emerging requirements. The topology and tunnel information in the OTN has already been defined by generic traffic-engineering models and technology-specific models, including and . In the latest version of OTN, ITU-T G.709/Y.1331 Edition 6.5 , the fine grain OTN (fgOTN) is introduced for the efficient transmission of low rate client signals (e.g., sub-1G). This document presents the control interface requirements of fgOTN, and defines two YANG data models for fgOTN topology and fgOTN tunnel. The topology model can capture topological and resource-related information pertaining to fgOTN. This model also enables clients, which interact with a transport domain controller, for fgOTN topology related operations such as obtaining the relevant topology resource information. The fgOTN tunnel YANG data model defined in this document is used for the provisioning and management of fgOTN Traffic Engineering (TE) tunnels, Label Switched Paths (LSPs), and interfaces. Furthermore, this document also imports the generic Layer 1 types defined in . The YANG data models defined in this document conform to the Network Management Datastore Architecture (NMDA) defined in .

Terminology and Notations Some of the key terms used in this document are listed as follow.

• fgTS: fine grain Tributary Slot.
• fgODUflex: fine grain Optical channel Data Unit flex

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

• client
• server
• augment
• data model
• data node

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

• configuration data
• state data

The terminology for describing YANG data models is found in .

Requirements Notation 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.

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 .

Requirements Language 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.

Prefixes in Model Names In this documents, 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
l1-types	ietf-layer1-types	[RFC YYYY]
otnt	ietf-otn-topology	[RFC ZZZZ]
te	ietf-te	[RFC KKKK]
otn-tnl	ietf-otn-tunnel	[RFC JJJJ]
fgotnt	ietf-fgotn-topology	RFC XXXX
fgotn-tnl	ietf-fgotn-tunnel	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 replace ZZZZ with the RFC numbers assigned to . Please replace KKKK with the RFC numbers assigned to . Please replace JJJJ with the RFC numbers assigned to . Please remove this note.

Model Tree Diagrams The tree diagrams extracted from the module(s) defined in this document are given in subsequent sections as per the syntax defined in .

Fine grain Optical Transport Network Scenarios Overview FgOTN layer network is a service layer network of the OTN ODU layer network. In order to provide fgOTN capabilities, this document defines two extension YANG data models augmenting to TE topology and TE tunnel YANG model. The attributes related to fgOTN are augments from OTN topology data model, and fgOTN topology is not treated as a separate hierarchy. The fgOTN tunnel is defined as a separate tunnel hierarchy, and new fgOTN tunnels need to be pre-set and created during the service provisioning process. The typical scenarios for fgOTN is to provide low bit rate private line or private network services for customers. Three scenarios that require special consideration are listed based on the characteristics of the fgOTN.

Private Line Service Provisioning Scenario of fgOTN OTN network will cover a larger scope of networks, it may include the backbone network, metro core, metro aggregation, metro access, and even the OTN CPE in the customers' networks. Figure 1 below shows an example of scenario to retrieve server tunnels. In this example, some small bandwidth fgOTN service are aggregated by the access ring (10G), and then aggregated into a bigger bandwidth in metro ring (100G). The allocation of TS maybe different in access ring and metro ring. E.g. there could be 3 timeslots allocated in the access ring while there could be 3 ODU2 are allocated in the metro ring.

The Scenario to Retrieve Server Tunnels

Service Protection Scenario of fgOTN As described in , the functional requirements of fgOTN include Support fgODUflex SNCP 1+1 protection. The protection of fgOTN service should rely on the protection of fgOTN tunnel. The server should provide all the hops of fgOTN tunnel, if the nodes cannot support fgOTN switching, the fg-ts in the LSP can be empty.

A New Protection Scenario of fgOTN

Hitless Resizing Scenario of fgOTN defines the data plane procedure to support fgODUflex hitless resizing. The support of management of hitless resizing of fgODUflex needs to be further considered. Firstly, the range of fgOTN service's Bandwidth on Demand (BoD) cannot exceed its server layer's bandwidth. Secondly, the client needs to know how many bandwidth of a link is allocated for fgOTN. From a management point of view, we only need to plan a portion of resources to support fgOTN, without having to allocate all resources for fgOTN to use. As shown in Figure 3, only resource 1 is planned for fgOTN.

The Range of fgOTN service's BOD

YANG Data Model for fine grain Optical Transport Network Overview

Fine Grain OTN Topology Data Model Overview This document aims to describe the data model for fine grain OTN topology. The YANG module presented in this document augments from OTN topology data model, i.e., the ietf-otn-topology, as specified in . In section 6 of , the guideline for augmenting OTN topology model was provided, and in this draft, we augment the OTN topology model to describe the topology characteristics of fgOTN. Common types, identities and groupings defined in is reused in this document. defines an abstract (generic, or base) YANG data model for network/service topologies and inventories, and provides the fundamental model for . OTN topology module in augments from the TE topology YANG model defined in . This work is not directly augmenting . shows the augmentation relationship.

Relationship between fgOTN topology and OTN topology model

The entities, TE attributes and OTN attributes, such as node, termination points and links, are still applicable for describing an fgOTN topology and the model presented in this document only specifies technology-specific attributes/information. The fgOTN-specific attributes including the fgTS, can be used to represent the bandwidth and label information. At the same time, it is necessary to extend the encoding and switching-capability enumeration values in to support fgOTN encapsulation and fgOTN switching.

Attributes Augmentation There are a few characteristics augmenting to the OTN topology. The fine grain tributary slot granularity (FGTSG) attribute defines the granularity, such as 10M, used by the TSs of a given OTN link. A boolean value is specified to augment the generic TE link termination point to describe whether the point can support fgOTN switching capability. The boolean value supported-fgodu-tp is used to indicate whether the termination point can support fgOTN switching capability.

Bandwidth Augmentation Based on the OTN topology model, we augment the bandwidth information of fgOTN, including the max-link-bandwidth and unreserved-bandwidth. The augmented parameter fgotn-bandwidth is used to indicate how much of the bandwidth has been allocated for the usage of fgOTN. The augmented fgotnlist structure is used to describe the unreserved TE bandwidth of fgOTN in the server ODUk. The odu-ts-number is used to indicate the index of server ODUk channel.

Label Augmentation The model augments the label-restriction list with fgOTN technology specific attributes using the otn-label-range-info grouping defined in . The fgts-range list is used to describe the availability of fgOTN timeslot in the server ODUk, including the fgts-reserved and fgts-unreserved. The odu-ts-number is used to indicate the index of server ODUk channel.

Fine Grain OTN Tunnel Data Model Overview This document aims to describe the data model for fgOTN tunnel. The fgOTN tunnel model augments to OTN tunnel with fgOTN-specific parameters, including the bandwidth information and label information. shows the augmentation relationship.

Relationship between fgOTN and OTN tunnel model

It's also worth noting that the fgOTN tunnel provisioning is usually based on the fgOTN topology. Therefore the fgOTN tunnel model is usually used together with fgOTN topology model specified in this document. The OTN tunnel model also imports a few type modules, including ietf-te-types and ietf-otn-types. A new enumeration value prot-fgoduflex in ietf-otn-types should be defined to indicate the fgotn tunnel.

Bandwidth Augmentation The model augment TE bandwidth information of fgOTN tunnel. The string value fgoduflex-bandwidth is used to indicate the bandwidth of this fgOTN tunnel.

Label Augmentation The module augments TE label-hop for the explicit route objects included or excluded by the path computation of the primary paths and secondary-paths using the fgts-numbers. The fgts-numbers is used to specify fgTS information on inter-domain ports of the routing path. We also augment the TE label-hop for the record route of the LSP using the fgts-numbers.

YANG Tree for fgOTN topology below shows the tree diagram of the YANG data model defined in module "ietf-fgotn-topology" ().

YANG Data Model for fgOTN topology

fgOTN topology YANG module

YANG Tree for fgOTN tunnel below shows the tree diagram of the YANG data model defined in module "ietf-fgotn-tunnel" ().

YANG Data Model for fgOTN tunnel

fgOTN tunnel YANG module

Manageability Considerations <Add any manageability considerations>

Security Considerations <Add any security considerations>

IANA Considerations <Add any IANA considerations>

References Normative References ITU-T Recommendation G.709 IANA n.d. Huawei Technologies Huawei Technologies IBM Corporation Nokia Telefonica This document defines a YANG data model for representing, retrieving, and manipulating Optical Transport Network (OTN) topologies. It is independent of control plane protocols and captures topological and resource-related information pertaining to OTN. Huawei Technologies Huawei Technologies Nokia Nokia CAICT This document describes the YANG data model for tunnels in OTN TE networks. The model can be used to do the configuration in order to establish the tunnel in OTN network. This work is independent with the control plane protocols. Huawei Technologies Huawei Technologies This document defines a collection of common common data types, identities, and groupings in the YANG data modeling language. These derived common common data types, identities, and groupings are intended to be imported by modules that model Layer 1 configuration and state capabilities. The Layer 1 types are representative of Layer 1 client signals applicable to transport networks, such as Optical Transport Networks (OTN). The Optical Transport Network (OTN) data structures are included in this document as Layer 1 types. Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950. 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). The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] 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. 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. 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. 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. Informative References This document defines an abstract (generic, or base) YANG data model for network/service topologies and inventories. The data model serves as a base model that is augmented with technology-specific details in other, more specific topology and inventory data models. This document defines a YANG data model for representing, retrieving, and manipulating Traffic Engineering (TE) Topologies. The model serves as a base model that other technology-specific TE topology models can augment. Huawei Futurewei Technologies IBM Corporation Juniper Networks Cisco Systems, Inc. Juniper Networks Individual This document defines few additional common data types and groupings in YANG data modeling language to be imported by modules that model Traffic Engineering (TE) configuration and state capabilities. This document updates RFC 8776 with a new revision of the module ietf-te-types.

Acknowledgments

Contributors Fiberhome Telecommunication Technologies Co.,LTD

lich@fiberhome.com