A YANG Data Model for Layer 1 Types Huawei TechnologiesH1, Huawei Xiliu Beipo Village, Songshan LakeDongguanGuangdong523808Chinazhenghaomian@huawei.comHuawei TechnologiesMilanItalyItalo.Busi@huawei.comCCAMP Working Group
This document defines a collection of common data types and groupings in the YANG data modeling language for use with layer 1 networks. These derived common types and groupings are intended to be imported by modules that specify OTN networks, such as topology, tunnel, client signal adaptation and service.
This document specifies common data types for use in YANG data models of Layer 1 networks. The derived types and groupings are types applicable to modeling Traffic Engineering (TE) for Layer 1 networks.
The Optical Transport Networking, a typical Layer 1 network, is specified in . The corresponding routing and signaling protocol are specified in and . The types and groupings defined in this document are consistent to those documents, and can be imported into other Layer 1 data models, including but not limited to, , , and .
The data model in this draft only defines groupings, typedef and identities. There is no configuration or state data as specified in the Network Management Datastore Architecture . The document is consistent with other specifications, including for Layer 1 service attributes, and for OTN data plane definitions.
Refer to for the key terms used in this document. The terminology for describing YANG data models can be found in .
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.
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 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 in as ietf-te-types, 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, are specified in ietf-te-types in , while the OTN-specific attributes, such as odu-type, are specified in ietf-layer1-types in this document.
The module ietf-layer1-types contains the following YANG reusable types and groupings:
tributary-slot-granularity:
This specifies the granularity of the server layer ODU Link (HO ODUk or ODUCn) supporting a client layer ODU LSP (LO ODUj or ODUk, respectively). Three granularities, 1.25G/2.5G/5G, have been specified.
odu-type:
This specifies the type of ODUk LSP, including the types specified in and .
client-signal:
This specifies the client signal types of OTN networks. The initial input was the G-PID specified in . Identities for some of the categories of client signal types, including ETH, STM-n, OC and Fiber Channel, have been specified.
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 and could be used in OTN topology model for link bandwidth representation. All the bandwidth related sections in generic module, , need to be augmented with this grouping for the usage of Layer 1.
otn-path-bandwidth:
This grouping defines the path bandwidth information and could be used in OTN topology model for path bandwidth representation. All the bandwidth related sections in generic module, , need to be augmented with this grouping for the usage of Layer 1. This grouping is also applicable when setting up the OTN tunnel.
otn-label-range-info and otn-label-step:
These groupings are used to augment an OTN label with type, granularity, priority and ODU types.
otn-label-start-end and otn-label-hop:
These groupings are used to augment a label for an OTN link and path respectively.
optical-interface-func:
The optical interface function is specified in . This grouping describes the functionality which encodes bits for transmission and decodes bits upon reception.
service-performance-metric:
The service performance metric is a quantitative characterization of the quality of the delivery of Layer 1 characteristic information as experienced by the Layer 1 subscriber.
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 time slots (numbered from 1 to 80) and the TPN values can be any number from 1 to 80.
The OTN Label Range represents the values for the TPN and TS that are available for ODUk LSPs to be setup over a given OTN Link.
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 entry of the list.
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 depends 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. Different entries in the label-restriction list will report different TPN ranges for different set of ODUk types, as indicated by the odu-type-list in the otn-label-range-info grouping.
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 is a type of ODU which has 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 'generic' case has been added to allow the ODUflex nominal bit rate to be defined independently from the type of ODUflex. This could be useful for forward compatibility in the transit domain/nodes where the setup of ODUflex LSPs does not depend on the ODUflex type.
In order to simplify interoperability the 'generic' case should be used only when it is 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 calculated 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 defines 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.
Section 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.
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 any other ODUflex type are used.
The number of available ODUs, defined for each ODUk type, including ODUflex, together with the number of available time-slots, reported as part of the OTN label range, provide sufficient information to infer the OTN link bandwidth availability for ODUflex LSPs. This information is independent of the ODUflex type.
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 support the hitless resizing procedures. They also identify whether an OTN link only supports the setup of non-resizable ODUflex LSPs or also supports the setup of resizable ODUflex(GFP,n,k) LSP but with different capabilities (e.g., a lower number of LSPs).
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 .
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.
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 .
The authors and the working group give their sincere thanks for Robert Wilton for the YANG doctor review, and Tom Petch for his comments during the model and document development.
Dieter Beller
Nokia
Email: dieter.beller@nokia.com
Sergio Belotti
Nokia
Email: sergio.belotti@nokia.com
Yanlei Zheng
China Unicom
Email: zhengyanlei@chinaunicom.cn
Aihua Guo
Futurewei Technologies
Email: aihuaguo@futurewei.com
Young Lee
Samsung
Email: younglee.tx@gmail.com
Lei Wang
China Mobile
Email: wangleiyj@chinamobile.com
Oscar Gonzalez de Dios
Telefonica
Email: oscar.gonzalezdedios@telefonica.com
Xufeng Liu
Volta Networks
Email: xufeng.liu.ietf@gmail.com
Yunbin Xu
CAICT
Email: xuyunbin@caict.ac.cn
Anurag Sharma
Google
Email: ansha@google.com
Rajan Rao
Infinera
Email: rrao@infinera.com
Victor Lopez
Telefonica
Email: victor.lopezalvarez@telefonica.com
Yunbo Li
China Mobile
Email: liyunbo@chinamobile.com
Subscriber Layer1 Service Attributes Technical Specification
Metro Ethernet Forum
Interfaces for the optical transport network
International Telecommunication Union
Transport of IEEE 10GBASE-R in optical transport networks (OTN)
International Telecommunication Union
Hitless adjustment of ODUflex(GFP)
International Telecommunication Union
Synchronous Optical Network Transport Systems: Common Generic Criteria, Issue 5
TelcordiaThis 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 .