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]