INTERNET-DRAFT T. Pang Intended Status: Standard Track China Telecom Expires: August 14, 2015 R. Huang Huawei February 10, 2015 YANG Data Model for Application Intelligent Service Profiles (ALPS) draft-ph-supa-alps-yang-dm-00 Abstract This document introduces a common YANG data model for network service profile. The common model can be augmented by additional YANG modules defining data models for specific network services to support various different network service consumers. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2015 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 Expires August 14, 2015 [Page 1] INTERNET DRAFT February 10, 2015 (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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Design of Application Intelligent Service Profiles Modules . . 3 3.1 Demand . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2 Demand-group . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3 Endpoint . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.4 Endpoint-group . . . . . . . . . . . . . . . . . . . . . . . 7 3.5 Connection . . . . . . . . . . . . . . . . . . . . . . . . . 8 4 Application Intelligent Service Profiles Modules Hierarchy . . . 8 5 Augmentation Examples . . . . . . . . . . . . . . . . . . . . . 9 5.1 QoS Clause Augmentation . . . . . . . . . . . . . . . . . . 9 5.2 Resource Clause Augmentation . . . . . . . . . . . . . . . . 10 5.3 VPN Instance Endpoint Augmentation . . . . . . . . . . . . . 11 6. Application Intelligent Service Profiles YANG Module . . . . . 12 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 15 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 15 9 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 15 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1 Normative References . . . . . . . . . . . . . . . . . . . 15 10.2 Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Expires August 14, 2015 [Page 2] INTERNET DRAFT February 10, 2015 1 Introduction SUPA (Simplified Use of Policy Abstractions) is aiming to introduce the concepts OF multi-level and multi-technology network abstractions to address the current separation between development and deployment operations [SUPA-ps]. To achieve this goal, one important problem is how to describe the network service requirements. A service profile could be regarded as the requirement coming from network service consumers. This document introduces a common YANG data model for network service profile. The common model can be augmented by additional YANG modules defining data models for specific network services to support various different network service consumers. 2 Terminology 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 RFC 2119 [RFC2119]. This document uses the following terms: NETCONF: Network Configuration Protocol SUPA: Simplified Use of Policy Abstractions YANG: A data modeling language used to model configuration and state data manipulated by the NETCONF protocol. ALPS: Application Intelligent Service Profiles 3. Design of Application Intelligent Service Profiles Modules This section describes common network service profile yang model structure and each separate elements. Specific service profile can inherit and augment from it. Demand: A Demand is the requirement description of a service. It could be some QoS requirements, resource requirements, or security requirements, etc. The demands can be applied to an endpoint, an endpoint group or a connection. Demand Group: A Demand Group consists of one or multiple demands having certain relationship with each other. The demand group is identified by a demand group name and contains one or multiple demands. Expires August 14, 2015 [Page 3] INTERNET DRAFT February 10, 2015 Endpoint: It could be used to describe a network device, an end user, a instance running in a device, an interface or a group of end users having same characters and could be applied the same requirements to. An endpoint may have a type, an identifier attribute, and a related demand group. Endpoint Group: The endpoint group is identified by a endpoint group name and contains one or multiple endpoints that can be applied a same demand group to. Connection: It indicates the one-way or two-way service transporting from one endpoint group to another endpoint group. It can be identified by a connection name and some other attributes. The following figure shows the structure of the Network Service Profile yang model: module: alps +--rw demand* | .... +--rw demand-group* | .... +--rw endpoint* | .... +--rw endpoint-group* | .... +--rw connection* | .... 3.1 Demand A demand contains a demand name leaf, a demand type leaf, a priority leaf, a clause container and a event container. It is used to describe some specific requirement from a service to the network. The following figure shows the structure of a demand list. module: alps +--rw demand* [name] +--rw name string +--rw demand-type alps-demand-type +--rw priority uint32 +--rw clause! +--rw event! .... The name is the identification of a demand. Different demands are distinguished via the name leaf. Expires August 14, 2015 [Page 4] INTERNET DRAFT February 10, 2015 The demand-type leaf is an enumeration type which indicates what kind of demands it belongs to. The priority leaf indicates the priority of this demand. It is usually used when multiple demands are applied. The clause container is a generalized aggregation container which describes the detailed requirements. It can be augmented by specific requirements (e.g., QoS, network resources or security etc.). Below is a simple qos-clause augmentation example. It is usually applied to a connection. augment /alps:demand/alps:clause +--rw qos-clause! The following figure augments a simple resource-clause container. It can be applied to either an endpoint or endpoint group, or a connection. augment /alps:demand/alps:clause +--rw resource-clause! The event container is a generalized container indicating the specific condition when the clause should be applied. It can be augmented according to different requirements, e.g., time event or statistic event. augment /alps:demand/alps:event +--rw time-event! +--rw start yang:date-and-time +--rw end yang:date-and-time +--rw duration uint32 +--rw statistic-event! +--rw traffic-statistics-condition! 3.2 Demand-group A demand-group contains a name leaf, a demand name list, and an operation container. It is used to collect a group of demands which may be all applied into a same object. The following figure shows the structure of a demand-group list. module: alps +--rw demand-group* [name] +--rw name string +--rw demand-name* string Expires August 14, 2015 [Page 5] INTERNET DRAFT February 10, 2015 +--rw operation! +--rw all? boolean +--rw expression! .... The name leaf is the identification of a demand-group. Different demand-groups are distinguished via the name leaf. The demand-name list refers to the specific demand described in the demand list. Please see Section 3.1. The operation container is a container to present how to deal with the demand list. It includes 2 leaves. The all leaf indicates the demands in this demand-group should be all applied. The expression leaf is also a container which can be augmented to present what the relationship among the demands is. For example, expression could be augmented as either an ORed set of ANDed expressions (Disjunctive Normal Form, or DNF) or an ANDed set of ORed expressions (Conjunctive Normal Form, or CNF). augment /alps:demand-group/alps:operation/alps:expression +--rw or-expression! | +--rw operands* [operand-name] | +--rw operand-name string | +--rw and-combination* [demand-name] | +--rw demand-name string +--rw and-expression! +--rw operands* [operand-name] +--rw operand-name string +--rw or-combination* [demand-name] +--rw demand-name string 3.3 Endpoint An endpoint contains a name leaf, a endpoint type leaf, a demand group name leaf and an attribute container. This element can be used to describe a network device, a end user, an instance, a virtual function, or a group of end uses who have same characters and could be applied the same requirements to. The following figure shows the structure of a endpoint list. module: alps +--rw endpoint* [name] +--rw name string +--rw endpoint-type alps-endpoint-type +--rw demand-group-name string +--rw attribute! .... Expires August 14, 2015 [Page 6] INTERNET DRAFT February 10, 2015 The name leaf is the identification of a endpoint. Different endpoints are distinguished via the name leaf. The endpoint-type leaf is an enumeration type which indicates what kind of endpoint it belongs to. The demand-group-name leaf refers to the specific demand group that is applied to this specific endpoint. Please see Section 3.2. The attribute container is a generalized aggregation container which can be augmented to indicate different attributes related to specific endpoint type. For example, IP and domain attributes could be augmented to an end-user or device endpoint; Instance attributes could be augmented to an instance endpoint. augment /alps:endpoint/alps:attribute +--rw ip-attribute! +--rw address inet:ip-address +--rw prefix inet:ipv4-prefix augment /alps:endpoint/alps:attribute +--rw domain-name-attribute! +--rw name inet:domain-name augment /alps:endpoint/alps:attribute +--rw device-attribute! augment /alps:endpoint/alps:attribute +--rw interface-attribute! augment /alps:endpoint/alps:attribute +--rw instance-attribute! 3.4 Endpoint-group An endpoint-group contains a name leaf, a endpoint group type leaf, endpoint name list and demand-group-name leaf. This element can be used to collect a group of endpoints that can be applied the same group of service requirements to. The following figure shows the structure of a demand-group list. module: alps +--rw endpoint-group* [name] +--rw name string +--rw endpoint-group-type alps-endpoint-group-type +--rw endpoint-name* string +--rw demand-group-name string Expires August 14, 2015 [Page 7] INTERNET DRAFT February 10, 2015 .... The name leaf is the identification of a endpoint-group. Different endpoint groups are distinguished via the name leaf. The endpoint-group-type leaf is an enumeration type which indicates what kind of endpoint group it belongs to. The endpoint-name list indicates the endpoints that form the endpoint group. It refers to the specific endpoint described in the endpoint list. Please see Section 3.3. The demand-group-name leaf refers to the specific demand group that is applied to this specific endpoint group. Please see Section 3.2. 3.5 Connection A connection contains a name leaf, a direction leaf, an endpoint group name list and a demand group name leaf. It is used to describe the one-way or two-way service transporting from one endpoint group to another endpoint group. The following figure shows the structure of a demand-group list. module: alps +--rw connection* [name] +--rw name string +--rw direction alps-connection-direction-type +--rw endpoint-group-name* string +--rw demand-group-name string .... The name leaf is the identification of a connection. Different connections are distinguished via the name leaf. The direction leaf is an enumeration type indicating whether the connection is one-way or two-way. The endpoint-group-name list indicates the endpoint-groups involved in this connection. At least 2 endpoint-groups MUST be included in this list. The endpoint-group name refers to the specific endpoint- group described in the endpoint-group list. Please see Section 3.4. The demand-group-name leaf refers to the specific demand group that is applied to this specific connection. Please see Section 3.2. 4 Application Intelligent Service Profiles Modules Hierarchy The following figure shows the structure of Application Intelligent Expires August 14, 2015 [Page 8] INTERNET DRAFT February 10, 2015 Service Profiles (ALPS) modules. module: alps +--rw demand* [name] +--rw name string +--rw demand-type alps-demand-type +--rw priority uint32 +--rw clause! +--rw event! +--rw demand-group* [name] +--rw name string +--rw demand-name* string +--rw operation! +--rw all? boolean +--rw expression! +--rw endpoint* [name] +--rw name string +--rw endpoint-type alps-endpoint-type +--rw demand-group-name string +--rw attribute! +--rw endpoint-group* [name] +--rw name string +--rw endpoint-group-type alps-endpoint-group-type +--rw endpoint-name* string +--rw demand-group-name string +--rw connection* [name] +--rw name string +--rw direction alps-connection-direction-type +--rw endpoint-group-name* string +--rw demand-group-name string 5 Augmentation Examples 5.1 QoS Clause Augmentation augment /alps:demand/alps:clause/alps:qos-clause +--rw simple-qos-clause! +--rw loss! | +--rw average-loss! | +--rw value uint32 +--rw delay | +--rw average-delay! | | +--rw value uint32 | +--rw range-delay! | +--rw min-value uint32 | +--rw max-value uint32 +--rw delay-variation! +--rw average-delay-variation! Expires August 14, 2015 [Page 9] INTERNET DRAFT February 10, 2015 +--rw value uint32 augment /alps:demand/alps:clause/alps:qos-clause +--rw class-qos-clause! +--rw classification-value qos-classification-type In this example, the clause container is augmented by a qos-clause container describing all requirements related to QoS. And then, qos- clause container is augmented by 2 containers: the simple-qos-clause and the class-qos-clause. The simple-qos-clause container is used to describe some simple end to end QoS requirements. It has several sub-containers to describe the detailed requirement from different aspects: The loss container is used to convey the loss requirement, e.g, average loss rate, max loss rate, etc. An average loss container is illustrated in this example to indicate average loss rate should not exceed this value. The delay container is used to describe the delay requirement like average delay. Here two containers are augmented: average-delay and range-delay. Average-delay is the value that average delay should not exceed. Range-delay indicates the scope that delay should be fit in. The delay-variation container is used to indicate the jitter requirement information. An average-delay-variation container is illustrated in this example. The class-qos-clause container is used to indicate the QoS requirement in different classes, e.g., gold class, silver class and bronzer class. 5.2 Resource Clause Augmentation augment /alps:demand/alps:clause/alps:resource-clause +--rw computation-resource-clause! +--rw cpu-clause! | +--rw cpu-min-speed uint64 | +--rw cpu-min-cores uint32 +--rw memory-clause! | +--rw memory-min-capacity uint64 +--rw storage-clause! +--rw storage-min-capacity! uint64 augment /alps:demand/alps:clause/alps:resource-clause +--rw network-resource-clause! Expires August 14, 2015 [Page 10] INTERNET DRAFT February 10, 2015 +--rw bandwidth-clause! +--rw upstream-bandwidth? uint32 +--rw downstream-bandwidth? uint32 +--rw available-bandwidth? uint32 In this example, the clause container is augmented by a resource- clause container describing all requirements related to resource. And then, resource-clause container is augmented by 2 containers: the computation-resource-clause and the network-resource-clause. The computation-resource-clause container is used to present some computation resources requirement. It can be divided into CPU resource (cpu-clause), memory resource (memeory-clause), and storage resource (storage-clause). The cpu-clause container contains 2 leaves, cpu-min-speed and cpu-min-cores, respectively describing the required minimum cpu speed and minimum CPU cores. The memory-clause container includes 1 memory-min-capacity leaf to indicate the required minimum memory capacity. The storage-clause container also includes 1 leaf: storage-min-capacity, which means the required minimum storage capacity. The network-resource-clause container is about the network resource requirements like bandwidth. Here a bandwidth-clause contain is illustrated. The bandwidth-clause includes upstream-bandwidth leaf, the downstream-bandwidth leaf and the available-bandwidth leaf. The upstream-bandwidth and the downstream-bandwidth are usually used to present the access network bandwidth requirement which may be applied to an endpoint. The available-bandwidth is usually applied to a connection. 5.3 VPN Instance Endpoint Augmentation The endpoint attribute container can be augmented to present a VPN instance. An example could be the L3VPN service module specified in [SUPA-vpn-model], as shown in the following figure. augment /alps:endpoint/alps:attribute/alsp:instance-attribute +--rw l3vpn-Instance* [instance-name] +--rw instance-name string +--rw servic-type? enumeration +--rw address-family-type? enumeration +--rw access-interface-id* [access-interface-id] +--rw access-interface-id string +--rw access-interface-address string +--rw ip-address-mask-length uint8 +--rw role enumeration +--rw user-name string +--rw user-password string Expires August 14, 2015 [Page 11] INTERNET DRAFT February 10, 2015 +--rw physical-node-id string +--rw physical-access-interface string +--rw protocol +--rw protocol-type? enumeration +--rw igp-attribute | +--rw protocol-id? uint32 +--rw bgp-attribute +--rw remote-as-number? string +--rw remote-peer-address string 6. Application Intelligent Service Profiles YANG Module file "alps.yang" module alps { yang-version 1; namespace "urn:TBD:params:xml:ns:yang:ietf-alps"; prefix alps; import ietf-yang-types { prefix yang;} organization ""; contact "@huawei.com"; description "This module defines alps yang data model"; typedef alps-demand-type { type string; description "demand type"; } typedef alps-demand-group-oper-type { type string; description "demand group operation type"; } typedef alps-endpoint-type { type string; description "endpoint type"; } typedef alps-endpoint-group-type { type string; description "endpoint group type"; } typedef alps-connection-direction-type { type string; description "connection direction type"; } Expires August 14, 2015 [Page 12] INTERNET DRAFT February 10, 2015 list demand { description "defines a list of demand."; key "name"; leaf name { type string; description ""; } leaf demand-type { type alps-demand-type; description ""; } leaf priority { type uint32; description ""; } container clause { } container event { } } list demand-group { description "defines a list of demand group."; key "name"; leaf name { type string; description ""; } leaf-list demand-name { type string; description ""; } container operation { leaf all { type boolean; description ""; } container expression { } } } list endpoint { description "defines a list of endpoint."; key "name"; leaf name { type string; description ""; Expires August 14, 2015 [Page 13] INTERNET DRAFT February 10, 2015 } leaf endpoint-type { type alps-endpoint-type; description ""; } leaf demand-group-name { type string; description ""; } container attribute { } } list endpoint-group { description "defines a list of endpoint group."; key "name"; leaf name { type string; description ""; } leaf endpoint-group-type { type alps-endpoint-group-type; description ""; } leaf-list endpoint-name { type string; description ""; } leaf demand-group-name { type string; description ""; } } list connection { description "defines a list of endpoint connection."; key "name"; leaf name { type string; description ""; } leaf direction { type alps-connection-direction-type; description ""; } leaf-list endpoint-group-name { type string; description ""; Expires August 14, 2015 [Page 14] INTERNET DRAFT February 10, 2015 } leaf demand-group-name { type string; description ""; } } } 7 Security Considerations TBD. 8 IANA Considerations TBD. 9 Acknowledgments The authors would like to thank Hong Zhou, Yinliang Hu for their valuable comments. 10 References 10.1 Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. [RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6021, October 2010. [SUPA-ps] G. Karagiannis, Q. Sun, Luis M. Contreras, P. Yegani, and JF Tremblay, "Problem Statement for Shared Unified Policy Automation (SUPA)", IETF Internet draft, draft- karagiannis-supa-problem-statement, January 2015. 10.2 Informative References [RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, "Policy Core Information Model -- Version 1 Specification", RFC 3060, February 2001. Expires August 14, 2015 [Page 15] INTERNET DRAFT February 10, 2015 [SUPA-framework] C. zhou, L. M. Contreras, Q. Sun, and P. Yegani, "The Framework of Shared Unified Policy Automation (SUPA)", IETF Internet draft, draft-zhou-supa-framework, January 2015. [SUPA-vpn-model] D. Zhang, A. Zaalouk, K. Pentikousis, and Y. Cheng, "VPN Service Management YANG Data Model", IETF internet draft, draft-zaalouk-supa-vpn-service-management-model, February 2015. Authors' Addresses Tao Pang Guangzhou Research Institute of ChinaTelecom Co.,Ltd. EMail: pangt@gsta.com Rachel Huang Huawei 101 Software Avenue, Yuhua District Nanjing 210012 China EMail: rachel.huang@huawei.com Expires August 14, 2015 [Page 16]