Internet DRAFT - draft-ph-supa-alps-yang-dm
draft-ph-supa-alps-yang-dm
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
<Huang, et al.> Expires August 14, 2015 [Page 1]
INTERNET DRAFT <YANG Data Model for ALPS> 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
<Huang, et al.> Expires August 14, 2015 [Page 2]
INTERNET DRAFT <YANG Data Model for ALPS> 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.
<Huang, et al.> Expires August 14, 2015 [Page 3]
INTERNET DRAFT <YANG Data Model for ALPS> 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.
<Huang, et al.> Expires August 14, 2015 [Page 4]
INTERNET DRAFT <YANG Data Model for ALPS> 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
<Huang, et al.> Expires August 14, 2015 [Page 5]
INTERNET DRAFT <YANG Data Model for ALPS> 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!
....
<Huang, et al.> Expires August 14, 2015 [Page 6]
INTERNET DRAFT <YANG Data Model for ALPS> 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
<Huang, et al.> Expires August 14, 2015 [Page 7]
INTERNET DRAFT <YANG Data Model for ALPS> 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
<Huang, et al.> Expires August 14, 2015 [Page 8]
INTERNET DRAFT <YANG Data Model for ALPS> 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!
<Huang, et al.> Expires August 14, 2015 [Page 9]
INTERNET DRAFT <YANG Data Model for ALPS> 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!
<Huang, et al.> Expires August 14, 2015 [Page 10]
INTERNET DRAFT <YANG Data Model for ALPS> 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
<Huang, et al.> Expires August 14, 2015 [Page 11]
INTERNET DRAFT <YANG Data Model for ALPS> 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
<CODE BEGINS> 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";
}
<Huang, et al.> Expires August 14, 2015 [Page 12]
INTERNET DRAFT <YANG Data Model for ALPS> 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 "";
<Huang, et al.> Expires August 14, 2015 [Page 13]
INTERNET DRAFT <YANG Data Model for ALPS> 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 "";
<Huang, et al.> Expires August 14, 2015 [Page 14]
INTERNET DRAFT <YANG Data Model for ALPS> February 10, 2015
}
leaf demand-group-name {
type string;
description "";
}
}
}
<CODE ENDS>
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.
<Huang, et al.> Expires August 14, 2015 [Page 15]
INTERNET DRAFT <YANG Data Model for ALPS> 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
<Huang, et al.> Expires August 14, 2015 [Page 16]
