CCAMP Working Group H. Zheng Internet-Draft Z. Fan Intended status: Standards Track Huawei Technologies Expires:November 12, 2017March 18, 2018 A. Sharma Google X. Liu JabilMay 11,S. Belotti Nokia Y. Xu CAICT L. Wang China Mobile O. Gonzalez de Dios Telefonica September 14, 2017 A YANG Data Model for Optical Transport Network Topologydraft-ietf-ccamp-otn-topo-yang-00draft-ietf-ccamp-otn-topo-yang-01 Abstract A transport network is a server-layer network designed to provide connectivity services for a client-layer network to carry the client traffic transparently across the server-layer network resources. A transport network can be constructed from equipments utilizing any of a number of different transport technologies such as the evolving Optical Transport Networks (OTN) or packet transport as provided by the MPLS-Transport Profile (MPLS-TP). Thisdraftdocument describes a YANG data model to describe the topologies of an Optical Transport Network (OTN). It is independent of control plane protocols and captures topological and resource related information pertaining to OTN. This model enables clients, which interact with a transport domain controller via a REST interface, for OTN topology related operations such as obtaining the relevant topology resource information.Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].Status of This Memo 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 athttp://datatracker.ietf.org/drafts/current/.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 onNovember 12, 2017.March 18, 2018. Copyright Notice Copyright (c) 2017 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(http://trustee.ietf.org/license-info)(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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology and Notations . . . . . . . . . . . . . . . . . . 3 3. YANG Data Model for OTN Topology . . . . . . . . . . . . . . 4 3.1. the YANG Tree . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Explanation of the OTN Topology Data Model . . . . . . . 5 3.3. The YANG Code . . . . . . . . . . . . . . . . . . . . . .56 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . .1311 5. Manageability Considerations . . . . . . . . . . . . . . . .1311 6. Security Considerations . . . . . . . . . . . . . . . . . . .1311 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .1312 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . .1312 9. References . . . . . . . . . . . . . . . . . . . . . . . . .1413 9.1. Normative References . . . . . . . . . . . . . . . . . .1413 9.2. Informative References . . . . . . . . . . . . . . . . .1513 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .1514 1. Introduction A transport network is a server-layer network designed to provide connectivity services for a client-layer network to carry the client traffic transparently across the server-layer network resources. A transport network can be constructed of equipments utilizing any of a number of different transport technologies such as the Optical Transport Networks (OTN) or packet transport as provided by the MPLS- Transport Profile (MPLS-TP). This document defines a data model of an OTN network topology, using YANG[RFC6020].[RFC7950]. The model can be used by an application exposing to a transport controller via a REST interface. Furthermore, it can be used by an application for the following purposes (but not limited to): o To obtain a whole view of the network topology information of its interest; o To receive notifications with regard to the information change of the OTN topology; o To enforce the establishment and update of a network topology with the characteristic specified in the data model, e.g., by a client controller; The YANG model defined in thisdraftdocument is independent of control plane protocols and captures topology related information pertaining to an Optical Transport Networks (OTN)-electrical layer, as the scope specified by [RFC7062] and [RFC7138]. Furthermore, it is not a stand-alone model, but augmenting from the TE topology YANG model defined in [I-D.ietf-teas-yang-te-topo]. Optical network technologies, including fixed Dense Wavelength Switched Optical Network (WSON) and flexible optical networks (a.k.a., flexi-grid networks), are covered in [I-D.ietf-ccamp-wson-yang] and [I-D.vergara-ccamp-flexigrid-yang], respectively. 2. Terminology and Notations A simplified graphical representation of the data model is used in this document. The meaning of the symbols in the YANG data tree presented later in thisdraftdocument is defined in[I-D.ietf-netmod-rfc6087bis].[I-D.ietf-netmod-yang-tree-diagrams]. They are provided below for reference. o Brackets "[" and "]" enclose list keys. o Abbreviations before data node names: "rw" means configuration (read-write) and "ro" state data (read-only). o Symbols after data node names: "?" means an optional node, "!" means a presence container, and "*" denotes a list and leaf-list. o Parentheses enclose choice and case nodes, and case nodes are also marked with a colon (":"). o Ellipsis ("...") stands for contents of subtrees that are not shown. 3. YANG Data Model for OTN Topology 3.1. the YANG Tree module: ietf-otn-topology augment /nd:networks/nd:network/nd:network-types/tet:te-topology: +--rw otn-topology! augment /nd:networks/nd:network: +--rw name? string augment /nd:networks/nd:network/nd:node: +--rw name? string augment /nd:networks/nd:network/lnk:link/tet:te/tet:config: +--rw available-odu-info* [priority] | +--rw priority uint8 | +--rw odulist* [odu-type] | | +--rw odu-type identityref | | +--rw number? uint16 | | +--rw tpn-range? string | +--rw ts-range? string +--rw tsg? identityref +--rw distance? uint32 augment /nd:networks/nd:network/lnk:link/tet:te/tet:state: +--ro available-odu-info* [priority] | +--ro priority uint8 | +--ro odulist* [odu-type] | | +--ro odu-type identityref | | +--ro number? uint16 | | +--ro tpn-range? string | +--ro ts-range? string +--ro tsg? identityref +--ro distance? uint32 augment /nd:networks/nd:network/nd:node/lnk:termination-point /tet:te/tet:config: +--rwclient-facing? empty +--rw tpn? uint16 +--rw tsg? identityref +--rw protocol-type? identityref +--rw adaptation-type? adaptation-type +--rw sink-adapt-active? boolean +--rw source-adapt-active? boolean +--rw tributary-slots | +--rw values* uint8 +--rwsupported-payload-types* [index] +--rw index uint16 +--rw payload-type? string augment/nd:networks/nd:network/nd:node/lnk:termination-point/ tet:te/tet:state: +--ro client-facing? empty +--ro tpn? uint16 +--ro tsg? identityref +--ro protocol-type? identityref +--ro adaptation-type? adaptation-type +--ro sink-adapt-active? boolean +--ro source-adapt-active? boolean +--ro tributary-slots | +--ro values* uint8/nd:networks/nd:network/nd:node/lnk:termination-point /tet:te/tet:state: +--ro supported-payload-types* [index] +--ro index uint16 +--ro payload-type? string 3.2. Explanation of the OTN Topology Data Model As can be seen, from the data tree shown in Section 3.1, the YANG module presented in thisdraftdocument augments from a more generic Traffic Engineered (TE) network topology data model, i.e., theietf-te- topology.yangietf- te-topology.yang as specified in [I-D.ietf-teas-yang-te-topo]. The entities and their attributes, such as node, termination points and links, are still applicable for describing an OTN topology and the model presented in thisdraftdocument only specifies withtechnology-specifictechnology- specific attributes/information. For example, if the data plane complies with ITU-T G.709 (2012) standards, the switching-capability and encoding attributes MUST be filled as OTN-TDM and G.709 ODUk(Digital Path) respectively. Note the model in thisdraftdocument re-uses some attributes defined inietf- transport-types.yang,ietf-transport-types.yang, which is specified in[I-D.sharma-ccamp-otn-tunnel-model].[I-D.ietf-ccamp-otn-tunnel-model]. One of the main augmentations in this model is that it allows to specify the type of ODU container and the number a link can support per priority level. For example, for a ODU3 link, it may advertise 32*ODU0, 16*ODU1, 4*ODU2 available, assuming only a single priority level is supported. If one of ODU2 resource is taken to establish a ODU path, then the availability of this ODU link is updated as 24*ODU0, 12*ODU1, 3*ODU2 available. If there are equipment hardware limitations, then a subset of potential ODU type SHALL be advertised. For instance, an ODU3 link may only support 4*ODU2. 3.3. The YANG Code <CODE BEGINS> file"ietf-otn-topology@2017-04-25.yang""ietf-otn-topology@2017-09-14.yang" module ietf-otn-topology { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-otn-topology"; prefix "otntopo"; import ietf-network { prefix "nd"; } import ietf-network-topology { prefix "lnk"; } import ietf-te-topology { prefix "tet"; revision-date 2017-06-10; } import ietf-transport-types { prefix "tran-types"; } organization"Internet Engineering Task Force (IETF)"IETF CCAMPWG";Working Group"; contact""WG Web: <http://tools.ietf.org/wg/ccamp/> WG List: <mailto:ccamp@ietf.org>ID-draft editor:Editor: Haomian Zheng(zhenghaomian@huawei.com);<mailto:zhenghaomian@huawei.com> Editor: Zheyu Fan(fanzheyu2@huawei.com);<mailto:fanzheyu2@huawei.com> Editor: Anurag Sharma(ansha@google.com);<mailto:ansha@google.com> Editor: Xufeng Liu(Xufeng_Liu@jabil.com) ";<mailto:Xufeng_Liu@jabil.com> Editor: Sergio Belotti <mailto:sergio.belotti@nokia.com> Editor: Yunbin Xu <mailto:xuyunbin@ritt.cn> Editor: Lei Wang <mailto:wangleiyj@chinamobile.com> Editor: Oscar Gonzalez de Dios <mailto:oscar.gonzalezdedios@telefonica.com>"; description "This module defines a protocol independent Layer 1/ODU topology data model."; revision2017-04-252017-09-14 { description "Revision0.3";0.4"; reference"draft-zhang-ccamp-l1-topo-yang-07.txt"; } /* typedef */ typedef adaptation-type { type enumeration { enum CBR { description "Constant Bit Rate."; } enum ATMvp { description "ATM VP."; } enum GFP { description "Generic Framing Procedure."; } enum NULL { description "NULL"; } enum PRBS { description "Pseudo Random Binary Sequence"; } enum RSn { description "SDH/SONET section"; } enum ODUj-21 { description "ODU payload type 21"; } enum ETHERNET_PP-OS { description "ETHERNET_PP-OS, for ODU 2 only"; } enum CBRx { description "CBRx(0.. 1.25G), for ODU0 only"; } enum ODU { description "Optical Data Unit"; } } description "Defines a type representing the adaptation type on the termination point.";"draft-ietf-ccamp-otn-topo-yang-01.txt"; } /* * Groupings */ grouping otn-topology-type { container otn-topology { presence "indicates a topology type of Optical Transport Network (OTN)-electrical layer."; description "otn topology type"; } description "otn-topology-type"; } grouping otn-topology-attributes { leaf name { type string; description "the topology name"; } description "name attribute for otn topology"; } grouping otn-node-attributes { description "otn-node-attributes"; leaf name { type string; description "a name for this node."; } } grouping otn-link-attributes { description"otn link attributes";"link attributes for OTN"; listavailable-odu-info{available-odu-info { key "priority"; max-elements "8"; description "List of ODU type and number on this link"; leaf priority { type uint8 { range "0..7"; } description "priority"; } list odulist { key "odu-type"; description "the list of available ODUs per priority level"; leaf odu-type { typeidentityref{identityref { base tran-types:tributary-protocol-type; } description "the type of ODU"; } leaf number { type uint16; description "the number of odu type supported"; }} }leafdistancetpn-range { typeuint32;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"distance in the unit"A list ofkilometers";available tributary port number range 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"; } }grouping otn-tp-attributes { description "otn-tp-attributes";leafclient-facingts-range { typeempty; description "if present, it means this tp is a client-facing tp. adding/dropping client signal flow."; } leaf tpn { type uint16string {range "0..4095";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"Tributary Port Number. Applicable in case"A list ofmux services.";available tributary slot range between 1 and 9999. For example 1-20,25,50-1000"; reference"RFC7139:"RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical TransportNetworks.";Networks"; } } leaf tsg { type identityref { base tran-types:tributary-slot-granularity; } description "Tributary slotgranularity.";granularity"; reference"G.709/Y.1331, February 2012: Interfaces"RFC 7138: Traffic Engineering Extensions to OSPF fortheGMPLS Control of Evolving G.709 Optical TransportNetwork (OTN)"; } leaf protocol-type { type identityref { base tran-types:tributary-protocol-type; } description "Protocol type for the Termination Point.";Networks"; } leafadaptation-typedistance { typeadaptation-type;uint32; description"This attribute indicates"distance in thetypeunit ofthe supported adaptation function at the termination point."; reference "G.874.1, January 2002: Optical transport network (OTN): Protocol-neutral management information model for the network element view.";kilometers"; }leaf sink-adapt-active { type boolean; description "This attribute allows for activation or deactivation of the sink adaptation function. The value of TRUE means active."; reference "G.874.1, January 2002: Optical transport network (OTN): Protocol-neutral management information model for the network element view ";}leaf source-adapt-activegrouping otn-tp-attributes {type boolean;description"This attribute allows for activation or deactivation of the sink adaptation function. The value of TRUE means active."; reference "G.874.1, January 2002: Optical transport network (OTN): Protocol-neutral management information model"tp attributes forthe network element view "; } container tributary-slots { description "AOTN"; listof tributary slots used by the ODU Termination Point."; leaf-list valuessupported-payload-types {type uint8; description "Tributary slot value."; reference "G.709/Y.1331, February 2012: Interfaces for the Optical Transport Network (OTN)"; } } list supported-payload-types{key "index"; description"supported"Supported payload types of aTP";TP. The payload type is defined as the generalized PIDs in GMPLS."; leaf index { type uint16; description "payload type index"; } leaf payload-type { type string; description "the payload type supported by this client tp"; reference "http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xhtml not: the payload type is defined as the generalized PIDs in GMPLS.";/gmpls-sig-parameters.xhtml"; } } } /* * Data nodes */ augment"/nd:networks/nd:network/nd:network-types/tet:te-topology""/nd:networks/nd:network/nd:network-types/" + "tet:te-topology" { uses otn-topology-type; description "augment network types to include otn newtork"; } augment "/nd:networks/nd:network" { when"nd:network-types/tet:te-topology/otn-topology""nd:network-types/tet:te-topology/otntopo:otn-topology" { description "Augment only for otn network"; } uses otn-topology-attributes; description "Augment network configuration"; } augment "/nd:networks/nd:network/nd:node" { when"../nd:network-types/tet:te-topology/otn-topology""../nd:network-types/tet:te-topology/otntopo:otn-topology" { description "Augment only for otn network"; } description "Augment node configuration"; uses otn-node-attributes; } augment "/nd:networks/nd:network/lnk:link/tet:te/tet:config" { when"../../../nd:network-types/tet:te-topology/otn-topology""../../../nd:network-types/tet:te-topology/" + "otntopo:otn-topology" { description "Augment only for otn network."; } description "Augment link configuration"; uses otn-link-attributes; } augment "/nd:networks/nd:network/lnk:link/tet:te/tet:state" { when"../../../nd:network-types/tet:te-topology/otn-topology""../../../nd:network-types/tet:te-topology/" + "otntopo:otn-topology" { description "Augment only for otn network."; } description "Augment link state"; uses otn-link-attributes; } augment "/nd:networks/nd:network/nd:node/"+"lnk:termination-point/tet:te/tet:config"+ "lnk:termination-point/tet:te/tet:config" { when"../../../../nd:network-types/tet:te-topology/otn-topology""../../../../nd:network-types/tet:te-topology/" + "otntopo:otn-topology" { description "Augment only for otn network"; } description "OTN TP attributes config inaODU topology."; uses otn-tp-attributes; } augment "/nd:networks/nd:network/nd:node/"+"lnk:termination-point/tet:te/tet:state"+ "lnk:termination-point/tet:te/tet:state" { when"../../../../nd:network-types/tet:te-topology/otn-topology""../../../../nd:network-types/tet:te-topology/" + "otntopo:otn-topology" { description "Augment only for otn network"; } description "OTN TP attributes state inaODU topology."; uses otn-tp-attributes; } } <CODE ENDS> 4. IANA Considerations TBD. 5. Manageability Considerations TBD. 6. Security Considerations The data following the model defined in thisdraftdocument is exchanged via, for example, the interface between an orchestrator and a transport network controller. The security concerns mentioned in [I-D.ietf-teas-yang-te-topo] for using ietf-te-topology.yang model also applies to thisdraft.document. The YANG module defined in this document can be accessed via the RESTCONF protocol defined in [RFC8040], or maybe via the NETCONF protocol [RFC6241]. There are a number of data nodes defined in the YANG module which are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., POST) to these data nodes without proper protection can have a negative effect on network operations. Editors note: to list specific subtrees and data nodes and their sensitivity/vulnerability. 7. Acknowledgements We would like to thank Igor Bryskin, Zhe Liu,Dieter Bellerand Daniele Ceccarelli for their comments and discussions. 8. Contributors Baoquan Rao Huawei Technologies Email: raobaoquan@huawei.com Xian Zhang Huawei Technologies Email: zhang.xian@huawei.comSergio Belotti Nokia Email: sergio.belotti@nokia.comHuub van Helvoort Hai Gaoming BV the Netherlands Email: huubatwork@gmail.com Victor Lopez Telefonica Email: victor.lopezalvarez@telefonica.com Yunbo Li China Mobile Email: liyunbo@chinamobile.com Dieter Beller Nokia Email: dieter.beller@nokia.com Yanlei Zheng China Unicom Email: zhengyl@dimpt.com 9. References 9.1. Normative References [I-D.ietf-ccamp-otn-tunnel-model] zhenghaomian@huawei.com, z., Fan, Z., Sharma, A., Rao, R., Belotti, S., Lopezalvarez, V., and Y. Li, "OTN Tunnel YANG Model", draft-ietf-ccamp-otn-tunnel-model-00 (work in progress), July 2017. [I-D.ietf-teas-yang-te-topo] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and O. Dios, "YANG Data Model for TE Topologies", draft-ietf-teas-yang-te-topo-08teas-yang-te-topo-12 (work in progress),MarchJuly 2017.[I-D.sharma-ccamp-otn-tunnel-model] Zhang, X., xiangkun, x., ansharma@infinera.com, a., and R. Rao, "OTN Tunnel YANG Model", draft-sharma-ccamp-otn- tunnel-model-01 (work in progress), March 2017. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <http://www.rfc-editor.org/info/rfc6020>.[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,<http://www.rfc-editor.org/info/rfc6241>.<https://www.rfc-editor.org/info/rfc6241>. [RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and J. Drake, "Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks", RFC 7138, DOI 10.17487/RFC7138, March 2014,<http://www.rfc-editor.org/info/rfc7138>.<https://www.rfc-editor.org/info/rfc7138>. [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>. [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,<http://www.rfc-editor.org/info/rfc8040>.<https://www.rfc-editor.org/info/rfc8040>. 9.2. Informative References [I-D.ietf-ccamp-wson-yang] Lee, Y., Dhody, D., Zhang, X., Guo, A., Lopezalvarez, V., King, D.,and B.Yoon, B., and R. Vilata, "A Yang Data Model for WSON Optical Networks",draft-ietf-ccamp-wson-yang-05draft-ietf-ccamp-wson-yang-07 (work in progress),FebruaryJuly 2017.[I-D.ietf-netmod-rfc6087bis] Bierman, A., "Guidelines for Authors[I-D.ietf-netmod-yang-tree-diagrams] Bjorklund, M. andReviewers of YANG Data Model Documents", draft-ietf-netmod-rfc6087bis-12L. Berger, "YANG Tree Diagrams", draft- ietf-netmod-yang-tree-diagrams-01 (work in progress),MarchJune 2017. [I-D.vergara-ccamp-flexigrid-yang] Madrid, U., Perdices, D., Lopezalvarez, V., Dios, O., King, D., Lee, Y., and G. Galimberti, "YANG data model for Flexi-Grid Optical Networks", draft-vergara-ccamp-flexigrid-yang-04flexigrid-yang-05 (work in progress),MarchJuly 2017. [RFC7062] Zhang, F., Ed., Li, D., Li, H., Belotti, S., and D. Ceccarelli, "Framework for GMPLS and PCE Control of G.709 Optical Transport Networks", RFC 7062, DOI 10.17487/RFC7062, November 2013,<http://www.rfc-editor.org/info/rfc7062>.<https://www.rfc-editor.org/info/rfc7062>. Authors' Addresses Haomian Zheng Huawei Technologies F3 R&D Center, Huawei Industrial Base, Bantian, Longgang District Shenzhen, Guangdong 518129 P.R.China Email: zhenghaomian@huawei.com Zheyu Fan Huawei Technologies F3 R&D Center, Huawei Industrial Base, Bantian, Longgang District Shenzhen, Guangdong 518129 P.R.China Email: fanzheyu2@huawei.com Anurag Sharma Google 1600 Amphitheatre Parkway Mountain View, CA 94043 Email: ansha@google.com Xufeng Liu Jabil Email: Xufeng_Liu@jabil.com Sergio Belotti Nokia Email: sergio.belotti@nokia.com Yunbin Xu CAICT Email: xuyunbin@ritt.cn Lei Wang China Mobile Email: wangleiyj@chinamobile.com Oscar Gonzalez de Dios Telefonica Email: oscar.gonzalezdedios@telefonica.com