]> Huawei Technologies

H1, Huawei Xiliu Beipo Village, Songshan Lake Dongguan Guangdong 523808 China zhenghaomian@huawei.com

Huawei Technologies

Milan Italy italo.busi@huawei.com

Routing CCAMP Working Group This document defines a collection of common data types, identities, and groupings in the YANG data modeling language. These derived 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. 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 CCAMP Working Group Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction This document specifies common data types, groupings, and identities for use in YANG data models of Layer 1 networks. The derived types and groupings apply to Traffic Engineered (TE) Layer 1 networks. The Layer 1 (L1) Optical Transport Network (OTN) is specified in . The corresponding routing and signaling protocols are specified in and . The types and groupings defined in this document are consistent with those documents, and can be imported into other Layer 1 data models, including but not limited to, , , and . The document is consistent with other specifications, including for Layer 1 service attributes, and for OTN data plane definitions.

Terminology and Notations 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. Specific terms used within this document are as follows:

OTN:

Optical Transport Network.

ODU:

Optical Data Unit. An ODU has the frame structure and overhead, as defined in Figure 12-1 of . ODUs can be formed in two ways: a) by encapsulating a single non-OTN client, such as SONET/SDH (Synchronous Optical Network / Synchronous Digital Hierarchy) or Ethernet, or b) by multiplexing lower-rate ODUs. In general, the ODU layer represents the path layer in OTN. The only exception is the ODUCn signal (defined below), which is defined to be a section-layer signal. In the classification based on bitrates of the ODU signals, ODUs are of two types: fixed rate and flexible rate. Flexible-rate ODUs, called "ODUflex", have a rate that is 239/238 times the bitrate of the client signal they encapsulate.

ODUCn:

Optical Data Unit-C. This signal has a bandwidth of approximately 100 Gbit/s and is of a slightly higher bitrate than the fixed rate ODU4 signal. This signal has the format defined in Figure 12-1 of . This signal represents the building block for constructing a higher-rate signal called "ODUCn".

ODUk:

Optical Data Unit-k, where k is one of {0, 1, 2, 2e, 3, 4}. The term "ODUk" refers to an ODU whose bitrate is fully specified by the index k. The bitrates of the ODUk signal for k = {0, 1, 2, 2e, 3, 4} are approximately 1.25 Gbit/s, 2.5 Gbit/s, 10 Gbit/s, 10.3 Gbit/s, 40 Gbit/s, and 100 Gbit/s, respectively.

LO ODU:

Lower Order ODU. The LO ODUj (j can be 0, 1, 2, 2e, 3, 4, or flex) represents the container transporting a client of the OTN that is either directly mapped into an OTUk (k = j) or multiplexed into a server HO ODUk (k > j) container.

HO ODU:

Higher Order ODU. The HO ODUk (k can be 1, 2, 2e, 3, or 4) represents the entity transporting a multiplex of LO ODUj tributary signals in its OPUk area.

The reader may also refer to and for other key terms used in this document. The terminology for describing YANG data models can be found in .

Prefix in Data Node Names In this document, the 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 . Prefixes and Corresponding YANG Modules

Prefix	YANG module	Reference
rt-types	ietf-routing-types
l1-types	ietf-layer1-types	RFC XXXX

• RFC Editor Note: Please replace XXXX with the number assigned to the RFC once this draft becomes an RFC.

Layer 1 Types Overview

Relationship with other Modules This document defines one YANG module for common Layer 1 types. The aim is to specify common Layer 1 TE types (i.e., typedef, identity, grouping) that can be imported by layer 1 specific technology, for example, layer 1 OTN, in its technology-specific modules, such as topology and tunnels. It is worth noting that the generic traffic-engineering (TE) types module is specified as ietf-te-types in , and both YANG modules, ietf-te-types and ietf-layer1-types, will need importing when the OTN is configured. Generic attributes such as te-bandwidth and te-label, which are specified as ietf-te-types in , need to be augmented with the OTN-specific attributes, such as odu-type, which are specified as ietf-layer1-types in this document, when OTN is configured.

Content in Layer 1 Type Module The module ietf-layer1-types contains the following YANG reusable types and groupings:

tributary-slot-granularity:

This specifies the granularity levels for tributary slots utilized by the server layer Optical Data Unit (ODU). Specifically, it addresses how ODU links, including both Higher Order Optical Data Unit-k (HO ODUk) and Optical Data Unit-Cn (ODUCn), accommodate client layer ODUs within Label Switched Paths (LSPs). These client layer ODUs could be Lower Order Optical Data Unit-j (LO ODUj) or ODUk, respectively. The specified granularity levels for these configurations are 1.25G, 2.5G, and 5G.

odu-type:

This specifies the type of ODUk LSP, including the types specified in and .

Since, as described in , does not guarantee interoperability in the data plane for these containers, the type of ODUk LSPs defined in and can be defined in vendor-specific YANG modules using the odu-type identity, defined in this document, as the base.

client-signal:

This specifies the common Layer 1 client signal types, including ETH , STM-n , OC and Fiber Channel . The input was based on the G-PID types specified in .

otn-label-range-type:

The label range type of OTN is represented in one of two ways, tributary slots (TS) and tributary port number (TPN), as specified in . Two representations are enumerated in the otn-label-range-type.

otn-link-bandwidth:

This grouping defines the link bandwidth information, usually as the number of ODUs that can be supported by the link for each ODU type: for example an OTN link with 100G bandwidth can support either 1xODU4, 10xODU2 or 80xODU0.

It is also used to represent the ODUflex resources available on a link, as described in .

This grouping could be used in the OTN topology model for link bandwidth representation. In general, all the bandwidth-related sections, which are defined in a generic module, e.g., using the groupings defined in , need to be augmented with this grouping when used to represent the bandwidth of an OTN link.

otn-path-bandwidth:

This grouping defines the path bandwidth information, usually as the type of ODU (e.g., ODU0, ODU2, ODU4) being set up along the path.

In the case of ODUflex paths, more information about the bandwidth of the ODUflex needs to be provided, as described in .

This grouping could be used in the OTN topology model for path bandwidth representation as well as when setting up the OTN tunnel. In general, all the bandwidth-related sections, which are defined in a generic module, e.g., using the groupings defined in , need to be augmented with this grouping when used to represent the bandwidth of an OTN tunnel or path.

otn-label-range-info:

This grouping is used to augment the label-restriction list, defined in , with OTN technology-specific attributes, as defined in .

otn-label-start-end:

This grouping is used to augment the label-start and label-end containers within the label-restriction list, defined in , with OTN technology-specific attributes, as defined in .

otn-label-step:

This grouping is used to augment the label-step container within the label-restriction list, defined in , with OTN technology-specific attributes, as defined in .

otn-label-hop:

This grouping is used to augment the label-hop container, defined in , with OTN technology-specific attributes, as defined in .

optical-interface-func:

The optical interface function is specified in . Identities that describe the functionality are specified to encode bits for transmission and to decode bits upon reception.

OTN Label and Label Range As described in , the OTN label usually represents the Tributary Port Number (TPN) and the related set of Tributary Slots (TS) assigned to a client layer ODU LSP (LO ODUj or ODUk) on a given server layer ODU (HO-ODU or ODUCn, respectively) Link (e.g., ODU2 LSP over ODU3 Link). Some special OTN label values are also defined for an ODUk LSP being set up over an OTUk Link. The same OTN label MUST be assigned to the same ODUk LSP at the two ends of an OTN Link. As described in , TPN can be a number from 1 to 4095 and TS are numbered from 1 to 4095, although the actual maximum values depend on the type of server layer ODU. For example, a server layer ODU4 provides 80 tributary slots (numbered from 1 to 80), and the TPN values can be any number from 1 to 80. The OTN Label Range specifies the available values for the Tributary Port Number (TPN) and Tributary Slots (TS) for setting up ODUk Label Switched Paths (LSPs) over an OTN Link, with priorities as defined in . This range is established according to the guidelines in . The OTN Label Range is defined by the label-restriction list, defined in , which, for OTN, SHOULD be augmented using the otn-label-range-info grouping. Each entry in the label-restriction list represents either the range of the available TPN values or the range of the available TS values: the range-type attribute in the otn-label-range-info grouping defines the type of range for each list entry. Each entry of the label-restriction list, as defined in , defines a label-start, a label-end, a label-step, and a range-bitmap. The label-start and label-end definitions for OTN SHOULD be augmented using the otn-label-start-end grouping. The label-step definition for OTN SHOULD be augmented using the otn-label-step grouping. It is expected that the otn-label-step will always be equal to its default value (i.e., 1), which is defined in . As described in , in some cases, the TPN assignment rules are flexible (e.g., ODU4 Link) while in other cases the TPN assignment rules are fixed (e.g., ODU1 Link). In the former case, both TPN and TS ranges are reported, while in the latter case, the TPN range is not reported which indicates that the TPN SHALL be set equal to the TS number assigned to the ODUk LSP. As described in , in some cases, the TPN assignment rules depend on the TS Granularity (e.g., ODU2 or ODU3 Links). Different entries in the label-restriction list will report different TPN ranges for each TS granularity supported by the link, as indicated by the tsg attribute in the otn-label-range-info grouping. As described in , in some cases the TPN ranges are different for different types of ODUk LSPs. For example, on an ODU2 Link with 1.25G TS granularity, the TPN range is 1-4 for ODU1 but 1-8 for ODU0 and ODUflex. Therefore, different entries in the label-restriction list will report different TPN ranges for a different set of ODUk types, as indicated by the odu-type-list in the otn-label-range-info grouping. Appendix A provides some examples of how the TPN and TS label ranges described in Table 3 and Table 4 of can be represented in YANG using the groupings defined in this document.

ODUflex ODUflex is a type of ODU with a flexible bit rate which is configured when setting up an ODUflex LSP. defines six types of ODUflex: ODUflex(CBR), ODUflex(GFP), ODUflex(GFP,n,k), ODUflex(IMP), ODUflex(IMP,s), and ODUflex(FlexE-aware). The main difference between these types of ODUflex is the formula used to calculate the nominal bit rate of the ODUflex, as described in Table 7-2 of . A YANG choice has been defined to describe these cases: The OPUflex payload rate can be expressed either in a floating point notation or a scientific notation, as defined in and . The 'generic' case has been added to allow the ODUflex nominal bit rate to be defined independently of the type of ODUflex. This could be useful for forward compatibility in the transit domain/nodes where the set up of ODUflex LSPs does not depend on the ODUflex type. In order to simplify interoperability the 'generic' case SHOULD be used only when needed; the ODUflex type-specific case SHOULD be used whenever possible. The 'cbr' case is used for Constant Bit Rate (CBR) client signals. The client-type indicates which CBR client signal is carried by the ODUflex and, implicitly, the client signal bit rate, which is then used to calculate the ODUflex(CBR) nominal bit rate as described in Table 7-2 of . The 'gfp-n-k' case is used for GFP-F mapped client signals based on ODUk.ts and 'n' 1.25G tributary slots. 'gfp-k' defines the nominal bit-rate of the ODUk.ts which, together with the value of 'gfp-n', is used to calculate the ODUflex(GFP,n,k) nominal bit rate as described in Table 7-8 and Table L-7 of . With a few exceptions, shown in Table L-7 of , the nominal bit-rate of the ODUk.ts could be inferred from the value of 'n', as shown in Table 7-8 of and therefore the 'gfp-k' is optional. The 'flexe-client' case is used for Idle Mapping Procedure (IMP) mapped FlexE client signals, The 'flexe-client' represents the type of FlexE client carried by the ODUflex which implicitly defines the value of 's' used to calculate the ODUflex(s) nominal bit rate as described in Table 7-2 of . The '10G' and '40G' enumeration values are used for 10G and 40G FlexE clients to implicitly define the values of s=2 and s=8. For the 'n x 25G' FlexE Clients the value of 'n' is used to define the value of s=5 x n. The 'flexe-aware' case is used for FlexE-aware client signals. The flexe-aware-n represents the value n (n = n1 + n2 + ... + np) which is used to calculate the ODUflex(FlexE-aware) nominal bit rate as described in Table 7-2 of . The 'packet' case is used for both the GFP-F mapped client signals and the IMP mapped client signals. The opuflex-payload-rate is either the GFP-F encapsulated-packet client nominal bit rate or the 64b/66b encoded-packet client nominal bit rate. The calculation of ODUflex(GFP) nominal bit rate is defined in Section 12.2.5 of , and the calculation of ODUflex(IMP) nominal bit rate is defined in Section 12.2.6 of . The same formula is used in both cases. Sections 5.1 and 5.2 of defines two rules to compute the number of tributary slots to be allocated to ODUflex(CBR) and ODUflex(GFP) LSPs when carried over a HO-ODUk link. According to Section 19.6 of , the rules in Section 5.2 apply only to ODUflex(GFP,n,k) while the rules defined in Section 5.1 apply to any other ODUflex type, including, but not limited, to ODUflex(CBR). Section 20.5 of defines the rules for computing the number of tributary slots to be allocated to ODUflex LSPs when carried over an ODUCn link. In order to compute the number of tributary slots required to set up an ODUflex LSP, or ODUflex LSPs, the type of Optical channel Data Tributary Unit (ODTU) is reported for the OTN Links or the OTN LTPs (Link Termination Points). Following the definitions, the rules defined for ODUflex(GFP,n,k) are used only when the 'gfp-n-k' case is used. In all the other cases, including the (generic) case, the rules defined for any other ODUflex type are used. The number of available ODUs, defined for each ODUk type, including ODUflex, does not provide sufficient information to infer the OTN link bandwidth availability for ODUflex LSPs. The OTN link bandwidth definitions for ODUflex LSPs also depend on the number of tributary slots (TS) and on the type of ODTU used to compute the number of TS required to set up an ODUflex LSP, according to the rules defined in Section 19.6 and Section 20.5 of , as described above. Similarly, bandwidth constraints for ODUflex LSPs of the OTN connectivity matrix and of the OTN local link connectivity entries depend also on the number of tributary slots (TS) and on the type of ODTU used to compute the number of TS required to set up an ODUflex LSP along the underlay path, according to the rules defined in Section 19.6 and Section 20.5 of , as described above. For example, with reference to Figure 1 of , the connectivity matrix entry or the local link connectivity entry corresponding to the A-C underlay path, would report 2 Tributary Slots (TS) with ODTU4.ts ODTU type.

Resizable ODUflex Resizable ODUflex is a special type of ODUflex that supports the procedures defined in for hitless resizing of the ODUflex nominal bit rate. Two odu-type identities have been defined for ODUflex:

• The ODUflex identity, which is used with any type of non-resizable ODUflex, as defined in Table 7-2 of .
• The ODUflex-resizable identity, which is used only with resizable ODUflex(GFP,n,k).

These two identities are used to identify whether an ODUflex(GFP,n,k) LSP does or does not support the hitless resizing procedures. They also identify whether an OTN link only supports the set up of non-resizable ODUflex LSPs or also supports the set up of resizable ODUflex(GFP,n,k) LSP but with different capabilities (e.g., a lower number of LSPs).

YANG Tree for Layer1 Types

YANG Code for Layer1 Types WG List: Editor: Haomian Zheng Editor: Italo Busi "; description "This module defines Layer 1 YANG types. Copyright (c) 2026 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 Revised 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. 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 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; revision 2026-06-12 { description "Initial Version"; reference "RFC XXXX: A YANG Data Model for Layer 1 Types"; // RFC Editor: replace RFC XXXX with actual RFC number, // update date information and remove this note. } /* * Identities */ identity tributary-slot-granularity { description "Tributary Slot Granularity (TSG)."; reference "ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN)"; } identity tsg-1.25G { base tributary-slot-granularity; description "1.25G tributary slot granularity."; } identity tsg-2.5G { base tributary-slot-granularity; description "2.5G tributary slot granularity."; } identity tsg-5G { base tributary-slot-granularity; description "5G tributary slot granularity."; } identity odu-type { description "Base identity from which specific Optical Data Unit (ODU) type is derived."; reference "RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN)"; } identity ODU0 { base odu-type; description "ODU0 type (1.24Gb/s)."; reference "RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN)"; } identity ODU1 { base odu-type; description "ODU1 type (2.49Gb/s)."; reference "RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN)"; } identity ODU2 { base odu-type; description "ODU2 type (10.03Gb/s)."; reference "RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN)"; } identity ODU2e { base odu-type; description "ODU2e type (10.39Gb/s)."; reference "RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN)"; } identity ODU3 { base odu-type; description "ODU3 type (40.31Gb/s)."; reference "RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN)"; } identity ODU4 { base odu-type; description "ODU4 type (104.79Gb/s)."; reference "RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN)"; } identity ODUflex { base odu-type; description "ODUflex type (flexible bit rate, not resizable). It could be used for any type of ODUflex, including ODUflex(CBR), ODUflex(GFP), ODUflex(GFP,n,k), ODUflex(IMP,s), ODUflex(IMP) and ODUflex(FlexE-aware)."; reference "RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN)"; } identity ODUflex-resizable { base odu-type; description "ODUflex protocol (flexible bit rate, resizable). It could be used only for ODUflex(GFP,n,k)."; reference "RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN)"; } identity protocol { description "Base identity from which specific protocol is derived."; reference "MEF 63: Subscriber Layer 1 Service Attributes"; } identity Ethernet { base protocol; description "Ethernet protocol."; reference "MEF 63: Subscriber Layer 1 Service Attributes"; } identity Fibre-Channel { base protocol; description "Fibre-Channel (FC) protocol."; reference "MEF 63: Subscriber Layer 1 Service Attributes"; } identity SDH { base protocol; description "SDH protocol."; reference "MEF 63: Subscriber Layer 1 Service Attributes"; } identity SONET { base protocol; description "SONET protocol."; reference "MEF 63: Subscriber Layer 1 Service Attributes"; } identity client-signal { description "Base identity from which specific Constant Bit Rate (CBR) client signal is derived"; } identity coding-func { description "Base identity from which specific coding function is derived."; reference "MEF 63: Subscriber Layer 1 Service Attributes"; } identity ETH-1Gb { base client-signal; description "Client signal type of 1GbE."; reference "IEEE Std 802.3-2022: IEEE Standard for Ethernet, Clause 36 RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN)"; } identity ETH-10Gb-LAN { base client-signal; description "Client signal type of ETH-10Gb-LAN (10.3 Gb/s)."; reference "IEEE Std 802.3-2022: IEEE Standard for Ethernet, Clause 49 RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN)"; } identity ETH-10Gb-WAN { base client-signal; description "Client signal type of ETH-10Gb-WAN (9.95 Gb/s)."; reference "IEEE Std 802.3-2022: IEEE Standard for Ethernet, Clause 50 RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN)"; } identity ETH-40Gb { base client-signal; description "Client signal type of 40GbE."; reference "IEEE Std 802.3-2022: IEEE Standard for Ethernet, Clause 82 RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN)"; } identity ETH-100Gb { base client-signal; description "Client signal type of 100GbE."; reference "IEEE Std 802.3-2022: IEEE Standard for Ethernet, Clause 82 RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN)"; } identity STM-1 { base client-signal; base coding-func; description "Client signal type of STM-1; STM-1 G.707 (N=1) coding function."; reference "ITU-T G.707 v7.0 (01/2007): Network node interface for the synchronous digital hierarchy (SDH) RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN) MEF 63: Subscriber Layer 1 Service Attributes"; } identity STM-4 { base client-signal; base coding-func; description "Client signal type of STM-4; STM-4 G.707 (N=4) coding function."; reference "ITU-T G.707 v7.0 (01/2007): Network node interface for the synchronous digital hierarchy (SDH) RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN) MEF 63: Subscriber Layer 1 Service Attributes"; } identity STM-16 { base client-signal; base coding-func; description "Client signal type of STM-16; STM-16 G.707 (N=16) coding function."; reference "ITU-T G.707 v7.0 (01/2007): Network node interface for the synchronous digital hierarchy (SDH) RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN) MEF 63: Subscriber Layer 1 Service Attributes"; } identity STM-64 { base client-signal; base coding-func; description "Client signal type of STM-64; STM-64 G.707 (N=64) coding function."; reference "ITU-T G.707 v7.0 (01/2007): Network node interface for the synchronous digital hierarchy (SDH) RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN) MEF 63: Subscriber Layer 1 Service Attributes"; } identity STM-256 { base client-signal; base coding-func; description "Client signal type of STM-256; STM-256 G.707 (N=256) coding function."; reference "ITU-T G.707 v7.0 (01/2007): Network node interface for the synchronous digital hierarchy (SDH) RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN) MEF 63: Subscriber Layer 1 Service Attributes"; } identity OC-3 { base client-signal; base coding-func; description "Client signal type of OC3; OC-3 GR-253-CORE (N=3) coding function."; reference "ANSI T1.105-2001: Synchronous Optical Network (SONET) Basic Description including Multiplex Structure, Rates, and Formats MEF 63: Subscriber Layer 1 Service Attributes"; } identity OC-12 { base client-signal; base coding-func; description "Client signal type of OC12; OC-12 GR-253-CORE (N=12) coding function."; reference "ANSI T1.105-2001: Synchronous Optical Network (SONET) Basic Description including Multiplex Structure, Rates, and Formats MEF 63: Subscriber Layer 1 Service Attributes"; } identity OC-48 { base client-signal; base coding-func; description "Client signal type of OC48; OC-48 GR-253-CORE (N=48) coding function."; reference "ANSI T1.105-2001: Synchronous Optical Network (SONET) Basic Description including Multiplex Structure, Rates, and Formats MEF 63: Subscriber Layer 1 Service Attributes"; } identity OC-192 { base client-signal; base coding-func; description "Client signal type of OC192; OC-192 GR-253-CORE (N=192) coding function."; reference "ANSI T1.105-2001: Synchronous Optical Network (SONET) Basic Description including Multiplex Structure, Rates, and Formats MEF 63: Subscriber Layer 1 Service Attributes"; } identity OC-768 { base client-signal; base coding-func; description "Client signal type of OC768; OC-768 GR-253-CORE (N=768) coding function."; reference "ANSI T1.105-2001: Synchronous Optical Network (SONET) Basic Description including Multiplex Structure, Rates, and Formats MEF 63: Subscriber Layer 1 Service Attributes"; } identity FC-100 { base client-signal; base coding-func; description "Client signal type of Fibre Channel FC-100; FC-100 FC-FS-2 (1.0625 Gb/s) coding function."; reference "ANSI INCITS 230-1994 (R1999): Information Technology - Fibre Channel - Physical and Signaling Interface (FC-PH) RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN) MEF 63: Subscriber Layer 1 Service Attributes"; } identity FC-200 { base client-signal; base coding-func; description "Client signal type of Fibre Channel FC-200; FC-200 FC-FS-2 (2.125 Gb/s) coding function."; reference "ANSI INCITS 230-1994 (R1999): Information Technology - Fibre Channel - Physical and Signaling Interface (FC-PH) RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN) MEF 63: Subscriber Layer 1 Service Attributes"; } identity FC-400 { base client-signal; base coding-func; description "Client signal type of Fibre Channel FC-400; FC-400 FC-FS-2 (4.250 Gb/s) coding function."; reference "ANSI INCITS 230-1994 (R1999): Information Technology - Fibre Channel - Physical and Signaling Interface (FC-PH) RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN) MEF 63: Subscriber Layer 1 Service Attributes"; } identity FC-800 { base client-signal; base coding-func; description "Client signal type of Fibre Channel FC-800; FC-800 FC-FS-2 (8.500 Gb/s) coding function."; reference "ANSI INCITS 230-1994 (R1999): Information Technology - Fibre Channel - Physical and Signaling Interface (FC-PH) RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN) MEF 63: Subscriber Layer 1 Service Attributes"; } identity FC-1200 { base client-signal; base coding-func; description "Client signal type of Fibre Channel FC-1200; FC-1200 FC-10GFC (10.51875 Gb/s) coding function."; reference "ANSI INCITS 230-1994 (R1999): Information Technology - Fibre Channel - Physical and Signaling Interface (FC-PH) RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN) MEF 63: Subscriber Layer 1 Service Attributes"; } identity FC-1600 { base client-signal; base coding-func; description "Client signal type of Fibre Channel FC-1600; FC-1600 FC-FS-3 (14.025 Gb/s) coding function."; reference "ANSI INCITS 230-1994 (R1999): Information Technology - Fibre Channel - Physical and Signaling Interface (FC-PH) RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN) MEF 63: Subscriber Layer 1 Service Attributes"; } identity FC-3200 { base client-signal; base coding-func; description "Client signal type of Fibre Channel FC-3200; FC-3200 FC-FS-4 (28.05 Gb/s) coding function."; reference "ANSI INCITS 230-1994 (R1999): Information Technology - Fibre Channel - Physical and Signaling Interface (FC-PH) RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN) MEF 63: Subscriber Layer 1 Service Attributes"; } identity ETH-1000X { base coding-func; description "1000BASE-X PCS clause 36 coding function."; reference "IEEE Std 802.3-2022: IEEE Standard for Ethernet, Clause 36 MEF 63: Subscriber Layer 1 Service Attributes"; } identity ETH-10GW { base coding-func; description "IEEE Std 802.3-2022: IEEE Standard for Ethernet, Clause 50 10GBASE-W (WAN PHY) PCS clause 49 and WIS clause 50 coding function."; reference "MEF 63: Subscriber Layer 1 Service Attributes"; } identity ETH-10GR { base coding-func; description "10GBASE-R (LAN PHY) PCS clause 49 coding function."; reference "IEEE Std 802.3-2022: IEEE Standard for Ethernet, Clause 49 MEF 63: Subscriber Layer 1 Service Attributes"; } identity ETH-40GR { base coding-func; description "40GBASE-R PCS clause 82 coding function."; reference "IEEE Std 802.3-2022: IEEE Standard for Ethernet, Clause 82 MEF 63: Subscriber Layer 1 Service Attributes"; } identity ETH-100GR { base coding-func; description "100GBASE-R PCS clause 82 coding function."; reference "IEEE Std 802.3-2022: IEEE Standard for Ethernet, Clause 82 MEF 63: Subscriber Layer 1 Service Attributes"; } identity optical-interface-func { description "Base identity from which optical-interface-function is derived."; reference "MEF 63: Subscriber Layer 1 Service Attributes"; } identity SX-PMD-1000 { base optical-interface-func; description "SX-PMD-clause-38 Optical Interface function for 1000BASE-X PCS-36."; reference "IEEE Std 802.3-2022: IEEE Standard for Ethernet, Clause 38 MEF 63: Subscriber Layer 1 Service Attributes"; } identity LX-PMD-1000 { base optical-interface-func; description "LX-PMD-clause-38 Optical Interface function for 1000BASE-X PCS-36."; reference "IEEE Std 802.3-2022: IEEE Standard for Ethernet, Clause 38 MEF 63: Subscriber Layer 1 Service Attributes"; } identity LX10-PMD-1000 { base optical-interface-func; description "LX10-PMD-clause-59 Optical Interface function for 1000BASE-X PCS-36."; reference "IEEE Std 802.3-2022: IEEE Standard for Ethernet, Clause 59 MEF 63: Subscriber Layer 1 Service Attributes"; } identity BX10-PMD-1000 { base optical-interface-func; description "BX10-PMD-clause-59 Optical Interface function for 1000BASE-X PCS-36."; reference "IEEE Std 802.3-2022: IEEE Standard for Ethernet, Clause 59 MEF 63: Subscriber Layer 1 Service Attributes"; } identity LW-PMD-10G { base optical-interface-func; description "LW-PMD-clause-52 Optical Interface function for 10GBASE-W PCS-49-WIS-50."; reference "IEEE Std 802.3-2022: IEEE Standard for Ethernet, Clause 52 MEF 63: Subscriber Layer 1 Service Attributes"; } identity EW-PMD-10G { base optical-interface-func; description "EW-PMD-clause-52 Optical Interface function for 10GBASE-W PCS-49-WIS-50."; reference "IEEE Std 802.3-2022: IEEE Standard for Ethernet, Clause 52 MEF 63: Subscriber Layer 1 Service Attributes"; } identity LR-PMD-10G { base optical-interface-func; description "LR-PMD-clause-52 Optical Interface function for 10GBASE-R PCS-49."; reference "IEEE Std 802.3-2022: IEEE Standard for Ethernet, Clause 52 MEF 63: Subscriber Layer 1 Service Attributes"; } identity ER-PMD-10G { base optical-interface-func; description "ER-PMD-clause-52 Optical Interface function for 10GBASE-R PCS-49."; reference "IEEE Std 802.3-2022: IEEE Standard for Ethernet, Clause 52 MEF 63: Subscriber Layer 1 Service Attributes"; } identity LR4-PMD-40G { base optical-interface-func; description "LR4-PMD-clause-87 Optical Interface function for 40GBASE-R PCS-82."; reference "IEEE Std 802.3-2022: IEEE Standard for Ethernet, Clause 87 MEF 63: Subscriber Layer 1 Service Attributes"; } identity ER4-PMD-40G { base optical-interface-func; description "ER4-PMD-clause-87 Optical Interface function for 40GBASE-R PCS-82."; reference "IEEE Std 802.3-2022: IEEE Standard for Ethernet, Clause 87 MEF 63: Subscriber Layer 1 Service Attributes"; } identity FR-PMD-40G { base optical-interface-func; description "FR-PMD-clause-89 Optical Interface function for 40GBASE-R PCS-82."; reference "IEEE Std 802.3-2022: IEEE Standard for Ethernet, Clause 89 MEF 63: Subscriber Layer 1 Service Attributes"; } identity LR4-PMD-100G { base optical-interface-func; description "LR4-PMD-clause-88 Optical Interface function for 100GBASE-R PCS-82."; reference "IEEE Std 802.3-2022: IEEE Standard for Ethernet, Clause 88 MEF 63: Subscriber Layer 1 Service Attributes"; } identity ER4-PMD-100G { base optical-interface-func; description "ER4-PMD-clause-88 Optical Interface function for 100GBASE-R PCS-82."; reference "IEEE Std 802.3-2022: IEEE Standard for Ethernet, Clause 88 MEF 63: Subscriber Layer 1 Service Attributes"; } /* * Typedefs */ typedef otn-tpn { type uint16 { range "1..4095"; } description "Tributary Port Number (TPN) for OTN."; reference "RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks."; } typedef otn-ts { type uint16 { range "1..4095"; } description "Tributary Slot (TS) for OTN."; reference "RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks."; } typedef otn-label-range-type { type enumeration { enum trib-slot { description "Defines a range of OTN tributary slots (TS)."; } enum trib-port { description "Defines a range of OTN tributary ports (TPN)."; } } description "Defines the type of OTN label range: TS or TPN."; } typedef gfp-k { type enumeration { enum 2 { description "The ODU2.ts rate (1,249,177.230 kbit/s) is used to compute the rate of an ODUflex(GFP,n,2)."; } enum 3 { description "The ODU3.ts rate (1,254,470.354 kbit/s) is used to compute the rate of an ODUflex(GFP,n,3)."; } enum 4 { description "The ODU4.ts rate (1,301,467.133 kbit/s) is used to compute the rate of an ODUflex(GFP,n,4)."; } } description "The ODUk.ts used to compute the rate of an ODUflex(GFP,n,k)."; reference "ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN), Tables 7-8 and L.7"; } typedef flexe-client-rate { type union { type uint16; type enumeration { enum 10G { description "Represents a 10G FlexE Client signal (s=2)."; } enum 40G { description "Represents a 40G FlexE Client signal (s=8)."; } } } description "The FlexE Client signal rate (s x 5,156,250.000 kbit/s) used to compute the rate of an ODUflex(IMP, s). Valid values for s are s=2 (10G), s=4 (40G) and s=5 x n (n x 25G). In the first two cases an enumeration value (either 10G or 40G) is used, while in the latter case the value of n is used."; reference "ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN), Table 7-2"; } typedef odtu-flex-type { type enumeration { enum 2 { description "The ODTU2.ts ODTU type."; } enum 3 { description "The ODTU3.ts ODTU type."; } enum 4 { description "The ODTU4.ts ODTU type."; } enum Cn { description "The ODTUCn.ts ODTU type."; } } description "The type of Optical Data Tributary Unit (ODTU), whose nominal bitrate is used to compute the number of Tributary Slots (TS) required by an ODUflex LSP, according to the (19-1a) and (20-1a) formulas defined in G.709."; reference "ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN), clauses 19.6 and 20.5, and Table 7-7"; } typedef bandwidth-scientific-notation { type string { pattern '0(\.0?)?([eE](\+)?0?)?|' + '[1-9](\.[0-9]{0,6})?[eE](\+)?(9[0-6]|[1-8][0-9]|0?[0-9])?'; } units "bps"; description "Bandwidth values, expressed using the scientific notation in bits per second. The encoding format is the external decimal-significant character sequences specified in IEEE 754 and ISO/IEC 9899 for 32-bit decimal floating-point numbers: (-1)**(S) * 10**(Exponent) * (Significant), where Significant uses 7 digits. An implementation for this representation MAY use decimal32 or binary32. The range of the Exponent is from -95 to +96 for decimal32, and from -38 to +38 for binary32. As a bandwidth value, the format is restricted to be normalized, non-negative, and non-fraction: n.dddddde{+}dd, N.DDDDDDE{+}DD, 0e0 or 0E0, where 'd' and 'D' are decimal digits; 'n' and 'N' are non-zero decimal digits; 'e' and 'E' indicate a power of ten. Some examples are 0e0, 1e10, and 9.953e9."; reference "IEEE Std 754-2019: IEEE Standard for Floating-Point Arithmetic ISO/IEC 9899:2024: Information technology - Programming Languages - C"; } /* * Groupings */ grouping otn-link-bandwidth { description "Bandwidth attributes for OTN links."; container otn-bandwidth { description "Bandwidth attributes for OTN links."; list odulist { key "odu-type"; description "OTN bandwidth definition"; leaf odu-type { type identityref { base odu-type; } description "ODU type"; } leaf number { type uint16; description "Number of ODUs."; } leaf ts-number { when "derived-from-or-self(../odu-type,'l1-types:ODUflex') or derived-from-or-self(../odu-type, 'l1-types:ODUflex-resizable')" { description "Applicable when odu-type is ODUflex or ODUflex-resizable."; } type uint16 { range "1..4095"; } description "The number of Tributary Slots (TS) that could be used by all the ODUflex LSPs."; } } } } grouping otn-path-bandwidth { description "Bandwidth attributes for OTN paths."; container otn-bandwidth { description "Bandwidth attributes for OTN paths."; leaf odu-type { type identityref { base odu-type; } description "ODU type"; } choice oduflex-type { when "derived-from-or-self(./odu-type,'l1-types:ODUflex') or derived-from-or-self(./odu-type, 'l1-types:ODUflex-resizable')" { description "Applicable when odu-type is ODUflex or ODUflex-resizable."; } description "Types of ODUflex used to compute the ODUflex nominal bit rate."; reference "ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN), Table 7-2"; case generic { leaf nominal-bit-rate { type union { type l1-types:bandwidth-scientific-notation; type rt-types:bandwidth-ieee-float32; } mandatory true; description "Nominal ODUflex bit rate."; } } case cbr { leaf client-type { type identityref { base client-signal; } mandatory true; description "The type of Constant Bit Rate (CBR) client signal of an ODUflex(CBR)."; } } case gfp-n-k { leaf gfp-n { type uint8 { range "1..80"; } mandatory true; description "The value of n for an ODUflex(GFP,n,k)."; reference "ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN), Tables 7-8 and L.7"; } leaf gfp-k { type gfp-k; description "The value of k for an ODUflex(GFP,n,k). If omitted, it is calculated from the value of gfp-n as described in Table 7-8 of G.709."; reference "ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN), Tables 7-8 and L.7"; } } case flexe-client { leaf flexe-client { type flexe-client-rate; mandatory true; description "The rate of the FlexE-client for an ODUflex(IMP,s)."; } } case flexe-aware { leaf flexe-aware-n { type uint16; mandatory true; description "The rate of FlexE-aware client signal for ODUflex(FlexE-aware)"; } } case packet { leaf opuflex-payload-rate { type union { type l1-types:bandwidth-scientific-notation; type rt-types:bandwidth-ieee-float32; } mandatory true; description "Either the GFP-F encapsulated packet client nominal bit rate for an ODUflex(GFP) or the 64b/66b encoded packet client nominal bit rate for an ODUflex(IMP)."; } } } } } grouping otn-max-path-bandwidth { description "Maximum bandwidth attributes for OTN paths."; container otn-bandwidth { description "Maximum bandwidth attributes for OTN paths."; leaf odu-type { type identityref { base odu-type; } description "ODU type."; } leaf max-ts-number { when "derived-from-or-self(../odu-type,'l1-types:ODUflex') or derived-from-or-self(../odu-type, 'l1-types:ODUflex-resizable')" { description "Applicable when odu-type is ODUflex or ODUflex-resizable."; } type uint16 { range "1..4095"; } description "The maximum number of Tributary Slots (TS) that could be used by an ODUflex LSP."; } } } grouping otn-label-range-info { description "Label range information for OTN. This grouping SHOULD be used together with the otn-label-start-end and otn-label-step groupings to provide OTN technology-specific label information to the models which use the label-restriction-info grouping defined in the module ietf-te-types."; container otn-label-range { description "Label range information for OTN."; leaf range-type { type otn-label-range-type; description "The type of range (e.g., TPN or TS) to which the label range applies"; } leaf tsg { type identityref { base tributary-slot-granularity; } description "Tributary slot granularity (TSG) to which the label range applies. This leaf MUST be present when the range-type is TS. This leaf MAY be omitted when mapping an ODUk over an OTUk Link. In this case the range-type is tpn, with only one entry (ODUk), and the tpn range has only one value (1)."; reference "ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN)"; } leaf-list odu-type-list { type identityref { base odu-type; } description "List of ODU types to which the label range applies. An Empty odu-type-list means that the label range applies to all the supported ODU types."; } leaf priority { type uint8 { range "0..7"; } description "Priority in Interface Switching Capability Descriptor (ISCD)."; reference "RFC 4203: OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)"; } } } grouping otn-label-start-end { description "The OTN label-start or label-end used to specify an OTN label range. This grouping is dependent on the range-type defined in the otn-label-range-info grouping. This grouping SHOULD be used together with the otn-label-range-info and otn-label-step groupings to provide OTN technology-specific label information to the models which use the label-restriction-info grouping defined in the module ietf-te-types."; container otn-label { description "Label start or label end for OTN. It is either a TPN or a TS depending on the OTN label range type specified in the 'range-type' leaf defined in the otn-label-range-info grouping."; leaf tpn { when "../../../../otn-label-range/range-type = 'trib-port'" { description "Valid only when range-type represented by trib-port."; } type otn-tpn; description "Tributary Port Number (TPN)."; reference "RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks"; } leaf ts { when "../../../../otn-label-range/range-type = 'trib-slot'" { description "Valid only when range-type represented by trib-slot."; } type otn-ts; description "Tributary Slot (TS) number."; reference "RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks"; } } } grouping otn-label-hop { description "OTN Label"; reference "RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks, section 6"; container otn-label { description "Label hop for OTN."; leaf tpn { type otn-tpn; description "Tributary Port Number (TPN)."; reference "RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks"; } leaf tsg { type identityref { base tributary-slot-granularity; } description "Tributary Slot Granularity (TSG)."; reference "ITU-T G.709 v6.0 (06/2020): Interfaces for the Optical Transport Network (OTN)"; } leaf ts-list { type string { pattern '([1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?' + '(,[1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?)*)'; } description "A list of available Tributary Slots (TS) ranging between 1 and 4095. If multiple values or ranges are given, they all MUST be disjoint and MUST be in ascending order. For example 1-20,25,50-1000."; reference "RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks"; } } } grouping otn-label-step { description "Label step for OTN. This grouping is dependent on the range-type defined in the otn-label-range-info grouping. This grouping SHOULD be used together with the otn-label-range-info and otn-label-start-end groupings to provide OTN technology-specific label information to the models which use the label-restriction-info grouping defined in the module ietf-te-types."; container otn-label-step { description "Label step for OTN. It is either a TPN or a TS depending on the OTN label range type specified in the 'range-type' leaf defined in the otn-label-range-info grouping."; leaf tpn { when "../../../otn-label-range/range-type = 'trib-port'" { description "Valid only when range-type represented by trib-port."; } type otn-tpn; description "Label step which represents possible increments for Tributary Port Number (TPN)."; reference "RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks"; } leaf ts { when "../../../otn-label-range/range-type = 'trib-slot'" { description "Valid only when range-type represented by trib-slot"; } type otn-ts; description "Label step which represents possible increments for Tributary Slot (TS) number."; reference "RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks"; } } } } ]]>

Security Considerations The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF or RESTCONF . The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) . The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS . If using secure channels, such as SSH for NETCONF or TLS for RESTCONF, an array of secure validation methods are availible. These methods range from public key and password authentication to host identity verification. It is strongly advised to not use options that require no authentication. However, it is important to acknowledge that not all authentication methods offer the same level of security. For instance, password-based authentication is notably susceptible to security threats such as phishing attacks and password reuse. The NETCONF access control model provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. The YANG module in this document defines layer 1 type definitions (i.e., typedef, identity and grouping statements) in YANG data modeling language to be imported and used by other layer 1 technology-specific modules. When imported and used, the resultant schema will have data nodes that can be writable, or readable. The access to such data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. The security considerations spelled out in the YANG 1.1 specification apply for this document as well.

IANA Considerations It is proposed that IANA should assign new URIs from the "IETF XML Registry" as follows: This document registers following YANG modules in the YANG Module Names registry .

• RFC Editor Note: Please replace XXXX with the number assigned to the RFC once this draft becomes an RFC.

References Normative References American National Standards Institute American National Standards Institute Institute of Electrical and Electronics Engineers Institute of Electrical and Electronics Engineers International Organization for Standardization International Telecommunication Union International Telecommunication Union International Telecommunication Union Metro Ethernet Forum 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). ITU-T Recommendation G.709 [G709-2012] introduced new Optical channel Data Unit (ODU) containers (ODU0, ODU4, ODU2e, and ODUflex) and enhanced Optical Transport Network (OTN) flexibility. This document updates the ODU-related portions of RFC 4328 to provide extensions to GMPLS signaling to control the full set of OTN features, including ODU0, ODU4, ODU2e, and ODUflex. 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 defines a collection of common data types using the YANG data modeling language. These derived common types are designed to be imported by other modules defined in the routing area. Huawei Futurewei Technologies Individual Cisco Systems Inc. Individual This document defines a collection of commonly used Traffic Engineering (TE) specific data types, identities, and groupings in YANG data modeling language. These derived common data types, identities, and groupings are intended to be imported by other modules that model configuration and state for TE constructs, such as TE Topologies, TE Tunnels, TE Policies, TE Paths, TE Label Switched Paths (LSPs), and TE interfaces. This document obsoletes RFC 8776. This document specifies encoding of extensions to the OSPF routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK] 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] This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK] This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas. Informative References International Telecommunication Union This document provides a framework to allow the development of protocol extensions to support Generalized Multi-Protocol Label Switching (GMPLS) and Path Computation Element (PCE) control of Optical Transport Networks (OTNs) as specified in ITU-T Recommendation G.709 as published in 2012. This document describes Open Shortest Path First - Traffic Engineering (OSPF-TE) routing protocol extensions to support GMPLS control of Optical Transport Networks (OTNs) specified in ITU-T Recommendation G.709 as published in 2012. It extends mechanisms defined in RFC 4203. Huawei Technologies Huawei Technologies Alef Edge 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 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. Samsung Korea Telecom Huawei Technologies Telefonica Cisco This document provides a YANG Layer 1 Connectivity Service Model (L1CSM). This model can be utilized by a customer network controller to initiate a connectivity service request as well as to retrieve service states for a Layer 1 network controller communicating with its customer network controller. This YANG model is in compliance of Network Management Datastore Architecture (NMDA). This document examines the applicability of using existing GMPLS routing and signaling mechanisms to set up Optical Data Unit-k (ODUk) Label Switched Paths (LSPs) over Optical Data Unit-Cn (ODUCn) links as defined in the 2020 version of ITU-T Recommendation G.709. RFCs 4328 and 7139 provide signaling extensions in Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) to control the full set of Optical Transport Network (OTN) features. However, these specifications do not cover the additional Optical channel Data Unit (ODU) containers defined in G.Sup43 (ODU1e, ODU3e1, and ODU3e2). This document defines new Signal Types for these additional containers. Huawei Old Dog Consulting Huawei CAICT This document provides an analysis of the applicability of the YANG models defined by the IETF (in particular in the Traffic Engineering Architecture and Signaling (TEAS) and Common Control and Measurement Plane (CCAMP) working groups) to support ODU transit services, transparent client services, and Ethernet Private Line/Ethernet Virtual Private Line (EPL/EVPL) services over Optical Transport Network (OTN) in single and multi-domain network scenarios. This document also describes how existing YANG models can be used through several worked examples and JSON fragments. This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content.

Examples of OTN Label Ranges This appendix provides some examples of how the TPN and TS label ranges described in Table 3 and Table 4 of can be represented in YANG using the groupings defined in this document. It also considers the OTUk links in addition to HO-ODUk links. The JSON code examples provided in this appendix provides some embedded comments following the conventions in Section 3.2 of and have been folded using the tool in .

• Note that this JSON example has been simplified for readability and therefore cannot be validated against the reference YANG model.

Acknowledgments The authors and the working group give their sincere thanks to Robert Wilton for the YANG doctor review, to Tom Petch for his comments during the model and document development, and to Deborah Brungard for her support in addressing IESG review comments on the scope of this document.

Contributors Nokia

dieter.beller@nokia.com

Nokia

sergio.belotti@nokia.com

China Unicom

zhengyanlei@chinaunicom.cn

Futurewei

aihuaguo.ietf@gmail.com

CRU

younglee.tx@gmail.com

China Mobile

wangleiyj@chinamobile.com

Telefonica

oscar.gonzalezdedios@telefonica.com

Individual

xufeng.liu.ietf@gmail.com

CAICT

xuyunbin@caict.ac.cn

Google

ansha@google.com

Infinera

rrao@infinera.com

Nokia

victor.lopez@nokia.com

China Mobile

liyunbo@chinamobile.com

Old Dog Consulting

daniel@olddog.co.uk