CCAMP Working Group | H. Zheng |
Internet-Draft | I. Busi |
Intended status: Standards Track | Huawei Technologies |
Expires: March 12, 2020 | September 9, 2019 |
A YANG Data Model for Layer 1 Types
draft-ietf-ccamp-layer1-types-02
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 Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 12, 2020.
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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 [RFC7062]. Corresponding routing and signaling protocol have been specified in [RFC7138] and [RFC7139]. 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, [I-D.ietf-ccamp-otn-topo-yang], [I-D.ietf-ccamp-otn-tunnel-model] and [I-D.ietf-ccamp-l1csm-yang].
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 [RFC8342]. The content in this draft is in consistent with [MEF63].
Refer to [RFC7062] for the key terms used in this document, and the terminology for describing YANG data models can be found in [RFC7950].
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.
+-------------+---------------------------+----------------------+ | Prefix | YANG module | Reference | +-------------+---------------------------+----------------------+ | layer1-types| ietf-layer1-types | This Document | +-------------+---------------------------+----------------------+
This document defines one YANG module for common Layer 1 types: ietf-layer1-types for OTN specific 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 [I-D.ietf-teas-yang-te-types] 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 for ODUk or ODUCn. Three granularities, 1.25G/2.5G/5G, have been specified.
odu-type:
This is to specify the type of ODUk.
client-signal:
This is to specify the client signal types of OTN networks. The initial input was the G-PID specified in [RFC7139]. 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 [RFC7139]. 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-link-label and otn-path-label:
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.
<CODE BEGINS>file "ietf-layer1-types@2019-09-09.yang" module ietf-layer1-types { namespace "urn:ietf:params:xml:ns:yang:ietf-layer1-types"; prefix "layer1-types"; organization "IETF CCAMP Working Group"; contact "WG Web: <http://tools.ietf.org/wg/ccamp/> WG List: <mailto:ccamp@ietf.org> Editor: Haomian Zheng <mailto:zhenghaomian@huawei.com> Editor: Italo Busi <mailto:Italo.Busi@huawei.com>"; description "This module defines Layer 1 types."; revision "2019-09-09" { description "Initial Version"; reference "RFC XXXX: A YANG Data Model for Layer 1 Types"; // RFC Ed.: replace XXXX with actual RFC number, update date // information and remove this note } identity tributary-slot-granularity { description "Tributary slot granularity"; reference "G.709/Y.1331, February 2016: 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 for protocol framing used by tributary signals."; } identity ODU0 { base odu-type; description "ODU0 protocol (1.24G), RFC7139/ITU-T G.709, as standard track."; } identity ODU1 { base odu-type; description "ODU1 protocol (2.49G), RFC7139/ITU-T G.709, as standard track."; } identity ODU1e { base odu-type; description "ODU1e protocol (10.35G), RFC7963/ITU-T G.sup43, as informational."; } identity ODU2 { base odu-type; description "ODU2 protocol (10.03G), RFC7139/ITU-T G.709, as standard track."; } identity ODU2e { base odu-type; description "ODU2e protocol (10.39G), RFC7139/ITU-T G.709, as standard track."; } identity ODU3 { base odu-type; description "ODU3 protocol (40.31G), RFC7139/ITU-T G.709, as standard track."; } identity ODU3e1 { base odu-type; description "ODU3e1 protocol (41.77G), RFC7963/ITU-T G.sup43, as informational."; } identity ODU3e2 { base odu-type; description "ODU3e2 protocol (41.78G), RFC7963/ITU-T G.sup43, as informational."; } identity ODU4 { base odu-type; description "ODU4 protocol (104.79G), RFC7139/ITU-T G.709, as standard track."; } identity ODUFlex-cbr { base odu-type; description "ODU Flex CBR protocol for transporting constant bit rate signal"; } identity ODUFlex-gfp { base odu-type; description "ODU Flex GFP protocol for transporting stream of packets using Generic Framing Procedure"; } identity ODUCn { base odu-type; description "ODUCn protocol (beyond 100G)"; } identity client-signal { description "Base identity from which specific client signals for the tunnel are derived"; } // Editor Notes: may consider add the OTUk as client signal; identity ETH-1Gb { base client-signal; description "Client signal type of 1GbE"; } identity ETH-10Gb-LAN { base client-signal; description "Client signal type of 10GbE LAN"; } identity ETH-10Gb-WAN { base client-signal; description "Client signal type of 10GbE WAN"; } identity ETH-40Gb { base client-signal; description "Client signal type of 40GbE"; } identity ETH-100Gb { base client-signal; description "Client signal type of 100GbE"; } identity STM-1 { base client-signal; description "Client signal type of STM-1"; } identity STM-4 { base client-signal; description "Client signal type of STM-4"; } identity STM-16 { base client-signal; description "Client signal type of STM-16"; } identity STM-64 { base client-signal; description "Client signal type of STM-64"; } identity STM-256 { base client-signal; description "Client signal type of STM-256"; } identity OC-3 { base client-signal; description "Client signal type of OC3"; } identity OC-12 { base client-signal; description "Client signal type of OC12"; } identity OC-48 { base client-signal; description "Client signal type of OC48"; } identity OC-192 { base client-signal; description "Client signal type of OC192"; } identity OC-768 { base client-signal; description "Client signal type of OC768"; } identity FC-100 { base client-signal; description "Client signal type of Fibre Channel FC-100"; } identity FC-200 { base client-signal; description "Client signal type of Fibre Channel FC-200"; } identity FC-400 { base client-signal; description "Client signal type of Fibre Channel FC-400"; } identity FC-800 { base client-signal; description "Client signal type of Fibre Channel FC-800"; } identity FC-1200 { base client-signal; description "Client signal type of Fibre Channel FC-1200"; } identity FC-1600 { base client-signal; description "Client signal type of Fibre Channel FC-1600"; } identity FC-3200 { base client-signal; description "Client signal type of Fibre Channel FC-3200"; } identity FICON-4G { base client-signal; description "Client signal type of Fibre Connection 4G"; } identity FICON-8G { base client-signal; description "Client signal type of Fibre Connection 8G"; } identity otn-label-range-type { description "Base identity from which specific OTN label range types derived"; } identity label-range-trib-slot { base otn-label-range-type; description "Defines a range of OTN tributary slots"; } identity label-range-trib-port { base otn-label-range-type; description "Defines a range of OTN tributary ports"; } // Editor Notes: following grouping only used in otn topology model, // so suggest to move to ietf-otn-topology and remove from types. grouping otn-link-bandwidth { description "link bandwidth attributes for OTN"; list odulist { key "odu-type"; description "OTN bandwidth definition"; leaf odu-type { type identityref { base layer1-types:odu-type; } description "ODU type"; } leaf number { type uint16; description "Number of ODUs"; } } } // Editor Notes: following groupings are used in both otn topology // and tunnel model, so suggest to be kept in the types. grouping otn-path-bandwidth { description "path bandwidth attributes for OTN"; leaf odu-type { type identityref { base layer1-types:odu-type; } description "ODU type"; } } // Editor Notes: following groupings are used in both otn topology // and tunnel model, so suggest to be kept in the types. grouping otn-label-restriction { description "label restriction information for OTN"; leaf range-type { type identityref { base layer1-types:otn-label-range-type; } description "type for range"; } leaf tsg { type identityref { base layer1-types:tributary-slot-granularity; } description "Tributary slot granularity."; reference "G.709/Y.1331, February 2016: Interfaces for the Optical Transport Network (OTN)"; } leaf priority { type uint8; description "priority."; } } // Editor Notes: following groupings are used in both otn topology // and tunnel model, so suggest to be kept in the types. grouping otn-link-label { description "link label information for OTN, for label-start/end"; choice otn-label-type { description "OTN label range type, either TPN range or TS range"; case tributary-port { leaf tpn { type uint16 { range "1..4095"; } description "Tributary Port Number. Applicable in case of mux services."; reference "RFC7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks."; } } case tributary-slot { leaf ts { type uint16 { range "1..4095"; } description "Tributary Slot Number. Applicable in case of mux services."; reference "RFC7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks."; } } } } // Editor Notes: following groupings are used in both otn topology // and tunnel model, so suggest to be kept in the types. grouping otn-path-label { description "label information for OTN, for label-hop"; leaf tpn { type uint16 { range "1..4095"; } description "Tributary Port Number. Applicable in case of mux services."; reference "RFC7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks."; } leaf tsg { type identityref { base layer1-types:tributary-slot-granularity; } description "Tributary slot granularity."; reference "G.709/Y.1331, February 2016: 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 ranging between 1 and 9999. For example 1-20,25,50-1000"; reference "RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks"; } } // Editor Notes: following grouping only used in otn topology model, // so suggest to move to ietf-otn-topology and remove from types. grouping otn-label-step { description "Label step for OTN"; choice otn-label-type { description "OTN label range type, either TPN range or TS range"; case tributary-port { leaf tpn-step { type uint16 { range "1..80"; } default 1; description "Label step which represents possible increments for Tributary Port Number."; reference "RFC7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks."; } } case tributary-slot { leaf ts { type uint16 { range "1..80"; } default 1; description "Label step which represents possible increments for Tributary Slot Number."; reference "RFC7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks."; } } } } // Editor Notes: to be reviewed for the following coding functions. identity coding-func { description "base identity from which coding func is derived."; } identity ETH-1000X-PCS-36 { base "coding-func"; description "PCS clause 36 coding function that corresponds to 1000BASE-X"; reference "MEF63 & IEEE802.3"; } identity ETH-10GW-PCS-49-WIS-50 { base "coding-func"; description "PCS clause 49 and WIS clause 50 coding func that corresponds to 10GBASE-W (WAN PHY)"; reference "MEF63 & IEEE802.3"; } identity ETH-10GR-PCS-49 { base "coding-func"; description "PCS clause 49 coding function that corresponds to 10GBASE-R (LAN PHY)"; reference "MEF63 & IEEE802.3"; } identity ETH-40GR-PCS-82 { base "coding-func"; description "PCS clause 82 coding function that corresponds to 40GBASE-R"; reference "MEF63 & IEEE802.3"; } identity ETH-100GR-PCS-82 { base "coding-func"; description "PCS clause 82 coding function that corresponds to 100GBASE-R"; reference "MEF63 & IEEE802.3"; } /* coding func needs to expand for Fiber Channel, SONET, SDH */ identity optical-interface-func { description "base identity from which optical-interface-function is derived."; } identity SX-PMD-clause-38 { base "optical-interface-func"; description "SX-PMD-clause-38 Optical Interface function for 1000BASE-X PCS-36"; reference "MEF63 & IEEE802.3"; } identity LX-PMD-clause-38 { base "optical-interface-func"; description "LX-PMD-clause-38 Optical Interface function for 1000BASE-X PCS-36"; reference "MEF63 & IEEE802.3"; } identity LX10-PMD-clause-59 { base "optical-interface-func"; description "LX10-PMD-clause-59 Optical Interface function for 1000BASE-X PCS-36"; reference "MEF63 & IEEE802.3"; } identity BX10-PMD-clause-59 { base "optical-interface-func"; description "BX10-PMD-clause-59 Optical Interface function for 1000BASE-X PCS-36"; reference "MEF63 & IEEE802.3"; } identity LW-PMD-clause-52 { base "optical-interface-func"; description "LW-PMD-clause-52 Optical Interface function for 10GBASE-W PCS-49-WIS-50"; reference "MEF63 & IEEE802.3"; } identity EW-PMD-clause-52 { base "optical-interface-func"; description "EW-PMD-clause-52 Optical Interface function for 10GBASE-W PCS-49-WIS-50"; reference "MEF63 & IEEE802.3"; } identity LR-PMD-clause-52 { base "optical-interface-func"; description "LR-PMD-clause-52 Optical Interface function for 10GBASE-R PCS-49"; reference "MEF63 & IEEE802.3"; } identity ER-PMD-clause-52 { base "optical-interface-func"; description "ER-PMD-clause-52 Optical Interface function for 10GBASE-R PCS-49"; reference "MEF63 & IEEE802.3"; } identity LR4-PMD-clause-87 { base "optical-interface-func"; description "LR4-PMD-clause-87 Optical Interface function for 40GBASE-R PCS-82"; reference "MEF63 & IEEE802.3"; } identity ER4-PMD-clause-87 { base "optical-interface-func"; description "ER4-PMD-clause-87 Optical Interface function for 40GBASE-R PCS-82"; reference "MEF63 & IEEE802.3"; } identity FR-PMD-clause-89 { base "optical-interface-func"; description "FR-PMD-clause-89 Optical Interface function for 40GBASE-R PCS-82"; reference "MEF63 & IEEE802.3"; } identity LR4-PMD-clause-88 { base "optical-interface-func"; description "LR4-PMD-clause-88 Optical Interface function for 100GBASE-R PCS-82"; reference "MEF63 & IEEE802.3"; } identity ER4-PMD-clause-88 { base "optical-interface-func"; description "ER4-PMD-clause-88 Optical Interface function for 100GBASE-R PCS-82"; reference "MEF63 & IEEE802.3"; } // Editor Notes: To add the performance monitor parameters per L1CSM; identity service-performance-metric { description "list of service-specific performance metric"; } identity One-way-Delay { base "service-performance-metric"; description "one-way-delay"; } identity One-way-Errored-Second { base "service-performance-metric"; description "one-way-errored-second"; } identity One-way-Severely-Errored-Second { base "service-performance-metric"; description "one-way-severely-errored-second"; } identity One-way-Unavailable-Second { base "service-performance-metric"; description "one-way-unavailable-second"; } identity One-way-Availability { base "service-performance-metric"; description "one-way-availability"; } //Editor Notes: it's useful to separate network specific performance //monitoring with service-specific identity network-performance-metric { description "list of network-specific performance metric"; } identity pm-placeholder { base "network-performance-metric"; description "A placeholder for potential performance monitoring on L1 networks"; } } <CODE ENDS>
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 [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446].
The NETCONF access control model [RFC8341] 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 [RFC7950] apply for this document as well.
It is proposed that IANA should assign new URIs from the "IETF XML Registry" [RFC3688] as follows:
URI: urn:ietf:params:xml:ns:yang:ietf-layer1-types Registrant Contact: The IESG XML: N/A; the requested URI is an XML namespace.
This document registers following YANG modules in the YANG Module Names registry [RFC7950].
name: ietf-layer1-types namespace: urn:ietf:params:xml:ns:yang:ietf-otn-types prefix: layer1-types reference: RFC XXXX
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