A YANG Data Model for Layer 1 Types Huawei TechnologiesH1-1-A043S Huawei Industrial Base, SongshanhuDongguanGuangdong523808Chinazhenghaomian@huawei.comHuawei TechnologiesMilanItalyItalo.Busi@huawei.comCCAMP Working Group
This document defines a collection of common data types and groupings in YANG data modeling language for layer 1 networks. These derived common types and groupings are intended to be imported by modules that specifies the OTN networks, including the topology, tunnel, client signal adaptation and service.
This document introduces a collection of common data types which would be used in Layer 1 networks. The derived types and groupings are designed to be the common types applicable for modeling Traffic Engineering (TE) features for Layer 1 optical networks.
Typical L1 network, the Optical Transport Networking, was specified in . Corresponding routing and signaling protocol have been specified in and . The types and groupings defined in this document is consistent to these document, and will be imported in other Layer 1 data models, including but not restrictive to, , and .
The data model in this draft has only types defined including groupings, typedef and identities. There is no need to include configuration and state data according to the new Network Management Datastore Architecture . The content in this draft is in consistent with .
Refer to for the key terms used in this document, and 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 objective is to specifies common Layer 1 TE types 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 the module ietf-te-types and ietf-layer1-types are needed to be imported when the OTN is configured.
The module ietf-layer1-types contains the following YANG reusable types and groupings:
tributary-slot-granularity:
This is to define 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 is to specify the type of ODUk LSP.
client-signal:
This is to specify the client signal types of OTN networks. The initial input was the G-PID specified in . Identities about a few 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 has two different representations, tributary slots (TS) and tributary port number (TPN), according to . Respective representation is specified under this same base type.
otn-link-bandwidth:
This grouping defines the link bandwidth information and could be used in OTN topology model for bandwidth representation. All the bandwidth related sections in generic topology module, ietf-te-topology, 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 bandwidth representation. All the bandwidth related sections in generic topology module, ietf-te-topology, need to be augmented with this grouping for the usage of Layer 1. This grouping is also applicable to set up the OTN tunnel.
otn-label-restriction and otn-label-step:
These groupings are used for the augmentation of OTN label in a specific way.
otn-label-start-end and otn-label-hop:
These groupings are used for the augmentation of label for OTN link and path respectively.
optical-interface-func:
The optical interface function is specified in [MEF63]. This grouping describes the functionality which encodes bits for transmission and the corresponding decode upon reception.
service-performance-metric:
The service performance metric is a quantitative characterization of Layer 1 characteristic information delivery quality 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 setup over an OTUk Link.
The same OTN label shall 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 [I-D.ietf-teas-yang-te-types], which, for OTN, should be augmented using the otn-label-restriction 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 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-link-label 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).
As described in , in some cases, the TPN assignment rules is flexible (e.g., ODU4 Link) while in other cases the TPN assignment rules are fixed (e.g., ODU1 Link). In the latter case, only the TS range is reported: not reporting the TPN range means 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.
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, there is TPN range 1-4 for ODU1 and another TPN range 1-8 in common 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 .
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 onsidered 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 .
TBD.
Dieter Beller
Nokia
Email: dieter.beller@nokia.com
Sergio Belotti
Nokia
Email: sergio.belotti@nokia.com
Yanlei Zheng
China Unicom
Email: zhengyl@dimpt.com
Aihua Guo
Huawei Technologies
Email: aihuaguo@huawei.com
Young Lee
Huawei Technologies
Email: leeyoung@huawei.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@ritt.com
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