TEAS Working Group X. Zhang, Ed. Internet-Draft Huawei Technologies Intended status: Standards Track J. Ryoo Expires: January 9, 2017 ETRI July 08, 2016 A Service YANG Model for Connection-oriented Transport Networks draft-zhang-teas-transport-service-model-00 Abstract A transport network is a server-layer network designed to provide connectivity services for a client-layer network to carry the client traffic opaquely across the server-layer network resources. A transport network may be constructed from equipments utilizing any of a number of different transport technologies such as the evolving optical transport infrastructure (Synchronous Optical Networking (SONET) / Synchronous Digital Hierarchy (SDH) and Optical Transport Network (OTN)) or packet transport as epitomized by the MPLS Transport Profile (MPLS-TP). This draft provides a transport service YANG model that can be used together with the RESTCONF protocol for a northbound client to initiate service requests toward the transport network controllers via the RESTful interface between them so as to enable automated service interations. 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 at http://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." Zhang & Ryoo Expires January 9, 2017 [Page 1] Internet-Draft Transport Service Model July 2016 This Internet-Draft will expire on January 9, 2017. Copyright Notice Copyright (c) 2016 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) 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Service Model - YANG Tree . . . . . . . . . . . . . . . . . . 3 4. Service Model - YANG Code . . . . . . . . . . . . . . . . . . 5 5. Open Issues/Future Items . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Manageability Considerations . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction A transport network is a server-layer network designed to provide connectivity services, or more advanced services like Virtual Private Networks (VPN) for a client-layer network to carry the client traffic opaquely across the server-layer network resources. It acts as a pipe provider for upper-layer networks, such as IP network and mobile networks. Transport networks, such as Synchronous Optical Networking (SONET) / Synchronous Digital Hierarchy (SDH), Optical Transport Network (OTN), Wavelength Division Multiplexing (WDM), and flexi-grid networks, are often built using equipments from a single vendor and are managed using private interfaces to dedicated Element Management Systems Zhang & Ryoo Expires January 9, 2017 [Page 2] Internet-Draft Transport Service Model July 2016 (EMS) / Network Management Systems (NMS). All transport networks have high benchmarks for reliability and operational simplicity. This suggests a common, technology-independent management/control paradigm that is extended to represent and configure specific technology attributes. The YANG language [RFC6020] is currently the data modeling language of choice within the IETF and has been adopted by a number of industry-wide open management and control initiatives. YANG may be used to model both configuration and operational states; it is vendor-neutral and supports extensible APIs for control and management of elements. This document, exploting the YANG language, provides a transport service model that can be used by a northbound client (e.g., an orchestrator, a client network controller etc.) to initiate service requests, as well as retrieving service states, toward the transport network via the RESTful interface provided by the transport network controller(s). The model is currently scoped for connection-oriented transport networks and connection-less transport networks are out of scope. 2. Terminology 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 this draft is defined in [I-D.ietf-netmod-rfc6087bis]. 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. Service Model - YANG Tree The service model YANG tree is provided below: Zhang & Ryoo Expires January 9, 2017 [Page 3] Internet-Draft Transport Service Model July 2016 module: ietf-transport-service +--rw transport_service +--rw service* [service-id] +--rw service-id -> ../config/service-id +--rw config | +--rw service-id? uint32 | +--rw service-name? string | +--rw service-endpoints* [node-id tp-id] | | +--rw type? enumeration | | +--rw node-id union | | +--rw tp-id uint32 | | +--rw endpoint-name? string | +--rw service-type identityref | +--rw supporting-tunnel | | +--rw tunnel-name? string | +--rw bandwidth? decimal64 | +--rw protection-type? identityref | +--rw schedule | | +--rw schedules | | +--rw schedule* [schedule-id] | | +--rw schedule-id uint32 | | +--rw start? yang:date-and-time | | +--rw schedule-duration? string | | +--rw repeat-interval? string | +--rw constraints | +--rw delay-limit? uint32 | +--rw delayvariation-limit? uint32 | +--rw packetloss-limit? decimal64 | +--rw objective? identityref +--ro state +--ro service-id? uint32 +--ro service-name? string +--ro service-endpoints* [node-id tp-id] | +--ro type? enumeration | +--ro node-id union | +--ro tp-id uint32 | +--ro endpoint-name? string +--ro service-type identityref +--ro supporting-tunnel | +--ro tunnel-name? string +--ro bandwidth? decimal64 +--ro protection-type? identityref +--ro schedule | +--ro schedules | +--ro schedule* [schedule-id] | +--ro schedule-id uint32 | +--ro start? yang:date-and-time | +--ro schedule-duration? string Zhang & Ryoo Expires January 9, 2017 [Page 4] Internet-Draft Transport Service Model July 2016 | +--ro repeat-interval? string +--ro creation-time? ytypes:date-and-time +--ro constraints | +--ro delay-limit? uint32 | +--ro delayvariation-limit? uint32 | +--ro packetloss-limit? decimal64 | +--ro objective? identityref +--ro performance-info | +--ro delay? uint32 | +--ro delay-variation? uint32 | +--ro packet-loss? decimal64 +--ro oper-status tet:te-oper-status 4. Service Model - YANG Code file "ietf-transport-service@2016-07-07.yang" module ietf-transport-service { yang-version 1; namespace "urn:ietf:params:xml:ns:yang:ietf-transport-service"; prefix transservice; import ietf-inet-types { prefix inet; } import ietf-yang-types { prefix ytypes; } import ietf-schedule { prefix "sch"; } import ietf-te-topology { prefix "tet"; } organization "Internet Engineering Task Force"; contact "Editor: Xian ZHANG (zhang.xian@huawei.com)"; description "this module describes a service module that is an essential API for a client to ask for a provider network for a path Zhang & Ryoo Expires January 9, 2017 [Page 5] Internet-Draft Transport Service Model July 2016 without the need to care about underlying technologies. Capability to specify constraints/policies are provided as optional features."; revision 2016-07-07 { description "Initial revision."; reference "to add the draft name"; } grouping endpoints-grouping{ description "end point grouping"; leaf type { type enumeration { enum root { description "root"; } enum leaf { description "leaf"; } enum unknown { description "unknown"; } } default root; description "This attribute indicates whether a endpoint of the service is acting as a root or leaf, and takes on the value either root, leaf or unkown. If the service type is Point-to-Point or Multipoint-to-Multipoint, then the type is equal to root. If the service type is Point-to-Multipoint, then the type can be either root or leaf."; } leaf node-id { type union { type inet:ip-address; //IPv4 or IPv6 type uint32; } description "the node address of a service ."; } leaf tp-id { type uint32; description "the termination point of a service."; Zhang & Ryoo Expires January 9, 2017 [Page 6] Internet-Draft Transport Service Model July 2016 } leaf endpoint-name { type string; description "the name of this service endpoint"; } } identity service-type { description "base identity from which the specific service type can be derived."; } identity service-P2P { base service-type; description "a point-to-point service type"; } identity service-P2MP { base service-type; description "a point to multi-point type"; } identity service-MP2MP { base service-type; description "a multi-point to multi-point type"; } //note: service type such as EPL, EVPL, EPLAN // EVPLAN, E-Tree can be added when augmenting // this model. identity service-prot-type { description "base identity from which the specific protection type can be derived."; } identity service-prot-unprotected { base service-prot-type; description "service protection type: unprotected"; } Zhang & Ryoo Expires January 9, 2017 [Page 7] Internet-Draft Transport Service Model July 2016 identity service-prot-1plusR { base service-prot-type; description "service protection type: dynamic reroute"; reference "draft-ietf-teas-gmpls-resource-sharing-proc-04"; } identity service-prot-1plus1 { base service-prot-type; description "service protection type: static 1+1"; } identity service-prot-1plus1plusR { base service-prot-type; description "service protection type: 1+1+R"; reference "draft-ietf-teas-gmpls-resource-sharing-proc-04"; } identity objective-type{ description "base identity from which the specific obective funciton can be derived."; } identity objective-mindelay{ base objective-type; description "objective: minimized delay"; } identity objective-mincost { base objective-type; description "objective: minimized cost"; } identity objective-mindistance { base objective-type; description "objective: minimized distance"; } grouping service-config-grouping { description "service-config-groupoing"; leaf service-id { Zhang & Ryoo Expires January 9, 2017 [Page 8] Internet-Draft Transport Service Model July 2016 type uint32; description "an unique identificaiton of a service."; } leaf service-name{ type string; description "the name for a service"; } list service-endpoints{ key "node-id tp-id"; description "this provides the service endpoints and it can be used to support different types of services (including P2P, MP2MP, P2MP)"; uses endpoints-grouping; } leaf service-type { type identityref { base service-type; } mandatory true; description "the type of a service request"; } container supporting-tunnel { leaf tunnel-name{ type string; description "the name of a tunnel (unique)"; } description "the tunnels that can be used to support the service"; } leaf bandwidth { type decimal64 { fraction-digits 2; } description "the bandwidth requested by a service."; } leaf protection-type{ type identityref { Zhang & Ryoo Expires January 9, 2017 [Page 9] Internet-Draft Transport Service Model July 2016 base service-prot-type; } description "the type of protection expected for this service"; } } grouping constraints-grouping { leaf delay-limit { type uint32; description "Delay variation in micro-seconds."; } leaf delayvariation-limit { type uint32; description "Delay variation."; } leaf packetloss-limit { type decimal64 { fraction-digits 6; range "0 .. 50.331642"; } description "Delay variation in %."; } leaf objective { type identityref { base objective-type; } description "objective function imposed for path computation from this service."; } description "constraints gropuing"; } container transport_service { description "serves as a top-level container for a list of services"; list service { key "service-id"; description Zhang & Ryoo Expires January 9, 2017 [Page 10] Internet-Draft Transport Service Model July 2016 "an unique identifier of a service"; leaf service-id { type leafref { path "../config/service-id"; } description "a unique service identifier."; } container config{ description "service config container"; uses service-config-grouping; container schedule { uses sch:schedules; description "to specify bandwidth scheduling information of this service."; } container constraints{ uses constraints-grouping; description "specify the constraints imposed by a service"; } } container state { config false; description "operational state of a service"; uses service-config-grouping; container schedule { uses sch:schedules; description "to specify bandwidth scheduling state information of this service."; } leaf creation-time { type ytypes:date-and-time; description "the time when service is created"; } container constraints{ Zhang & Ryoo Expires January 9, 2017 [Page 11] Internet-Draft Transport Service Model July 2016 uses constraints-grouping; description "specify the constraints imposed by a service"; } container performance-info{ description "service state-performance info"; leaf delay{ type uint32; description "the latency of this service"; } leaf delay-variation { type uint32; description "the service delay varation"; } leaf packet-loss { type decimal64 { fraction-digits 6; range "0 .. 50.331642"; } description "packet loss"; } } leaf oper-status { type tet:te-oper-status; mandatory true; description "the operational status of this service"; } }//end of state of a service }//end of service list (including config and state) }//service top container } 5. Open Issues/Future Items Attributes/functions that are under considerations for updating the YANG model: 1): to add information such as PIR/CIR pertaining to ETH service when augmenting this model; to add signal-type information for otn service when augmenting this model; Zhang & Ryoo Expires January 9, 2017 [Page 12] Internet-Draft Transport Service Model July 2016 2): to add service-related notification, e.g.: service up; service down, service degraded etc.; 3): to figure out how to deal with attributes such as bandwidth, schedule where it can be per node for non-P2P, but is per node pair for P2P; 4): to add a RPC for service query, instead of actual setup; 5): to add XRO/IRO constraints; If service query RPC is supported, then loose or strict IRO/ERO should be specified; 6. IANA Considerations TBD. 7. Manageability Considerations TBD 8. Security Considerations Since the data model defined in this draft is manipulated via, for example, the interface between an orchestrator and a transport network controller. The YANG module defined in this draft is designed to be accessed via the RESTCONF protocol defined in [I-D.ietf-netconf-restconf], or maybe via the NETCONF protocol [RFC6241]. As mentioned in Security Conserations Section of [I-D.ietf-netconf-restconf] that HTTPS defined in [RFC7230] can be used to provide security while accessing data. 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. Editor note: to List specific subtrees and data nodes and their sensitivity/vulnerability. 9. Acknowledgements We would like to thank Baoquan Rao and Gang Xie for their initial discussions that trigger the generation of this draft. We would also like to thank Michael Scharf from Nokia for very useful comments to this draft and the model. Zhang & Ryoo Expires January 9, 2017 [Page 13] Internet-Draft Transport Service Model July 2016 Aspects of the work in this Internet-Draft is funded by the UK Engineering and Physical Sciences Research Council (EPSRC) under the TOUCAN project (EP/L020009/1). 10. Contributors Zhe Liu Huawei Technologies Email: liuzhe123@huawei.com Sergio Belotti Nokia Email:sergio.belotti@nokia.com Daniel King Lancaster University Email:d.kindg@lancaster.ac.uk 11. References 11.1. Normative References [I-D.ietf-netconf-restconf] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", draft-ietf-netconf-restconf-13 (work in progress), April 2016. [I-D.ietf-netmod-rfc6087bis] Bierman, A., "Guidelines for Authors and Reviewers of YANG Data Model Documents", draft-ietf-netmod-rfc6087bis-06 (work in progress), March 2016. [I-D.ietf-teas-yang-te] Saad, T., Gandhi, R., Liu, X., Beeram, V., Shah, H., Chen, X., Jones, R., and B. Wen, "A YANG Data Model for Traffic Engineering Tunnels and Interfaces", draft-ietf-teas-yang- te-03 (work in progress), March 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . Zhang & Ryoo Expires January 9, 2017 [Page 14] Internet-Draft Transport Service Model July 2016 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, . 11.2. Informative References [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, . Authors' Addresses Xian Zhang (editor) Huawei Technologies F3-5-B R&D Center, Huawei Industrial Base, Bantian, Longgang District Shenzhen, Guangdong 518129 P.R.China Email: zhang.xian@huawei.com Jeong-dong Ryoo ETRI Email: ryoo@etri.re.kr Zhang & Ryoo Expires January 9, 2017 [Page 15]