Network Working Group J. Bi Internet Draft Tsinghua Univ. Intended status: Standard Track Q. Sun Expires: May 2016 C. Xie China Telecom Y. Zha Huawei Technologies November 13, 2015 Declarative Policy Model draft-bi-declarative-policy-01 Abstract This document describes a declarative (also called intent based) policy model to describe the user's intent on network policy. The intent policy model is a specific data model specifies the desired state of the network system. It helps the service management in Simplified Use of Policy Abstractions (SUPA) to model the policy (a set of states described by constraints) that defines the final results of a VPN service without specifying how it is monitored and managed during its lifecycle. One application for Distributed Data Center (DDC) scenarios with policy enforcement is provided with details of how to convert high level intent policy into lower level configurations. 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), 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Bi, et al. Expires May 13, 2016 [Page 1] Internet-Draft Declarative Policy Model November 2015 This Internet-Draft will expire on May 13, 2015. Copyright Notice Copyright (c) 2014 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. Conventions used in this document ..................................... 3 3. Policy Based Service Management Framework.............................. 3 4. Declarative Policy Configuration Modules .............................. 4 4.1. Declarative Policy Framework ..................................... 4 4.2. Declarative Policy Model ......................................... 5 5. Declarative Policy Applications in DDC services ...................... 14 5.1. Policy Based Traffic Steering Case study ........................ 14 5.2. Declarative Policy Enforcement .................................. 19 6. Security Considerations .............................................. 20 7. IANA Considerations .................................................. 20 8. Acknowledgments ...................................................... 21 9. References............................................................ 21 9.1. Normative References ............................................ 21 9.2. Informative References .......................................... 21 1. Introduction In order to support emerging DDC service with VPN connection as well as new services, it brings new requirements on Policy based service management for service providers. Instead of manual configuration of the network infrastructures, policy based service management is achieved by using policies that can be created by the operators once and the service management refers to these policies to infer how a given service needs to be provisioned considering the current state of the network. With the general trend of NFV/SDN, network management and control is moving from low level operation to high level decision making. Human to machine communication is changing from imperative to declarative. In the other hand, human intention will be more expressed by declarative policy. Bi, et al. Expires May 13, 2016 [Page 2] Internet-Draft Declarative Policy Model November 2015 In SUPA framework, network policy consists of different layers with generic policy on top while declarative policy and ECA (Event-Condition-Action) policy. ECA policy is a predefined rule or a set of rules that the service management use to map the service to the lower level network infrastructures as shown in draft [draft-chen-supa-eca-data-model]. Oh the other hand, declarative policy is higher level abstraction which only specifies the needs or the final state of the system without knowing the low level network infrastructures. In this way, the declarative policy defines the final state and the constraint for the network behaviors. Meanwhile, DDC service which is mainly relied on VPN [RFC4110] needs policy based management and controlling capability from the service management systems to facilitate the service deployment both inter data centers and within data center. This document introduces YANG [RFC6020] [RFC6021] data models for SUPA configuration. Such models can facilitate the standardization for the interface of SUPA, as they are compatible to a variety of protocols such as NETCONF [RFC6241] and [RESTCONF]. Please note that in the context of SUPA, the term "application" refers to an operational and management applications employed, and possibly implemented, by an operator. The policy model is based on the first example - - DDC services. Also certain foundational concepts of the model are intentionally left open to enable future extension. With respect to the scope, defining an information model on the top level and a corresponding data model based on yang to express the declarative policy for traffic optimization in specific DDC service use case is initial goal of this document. In addition to the generic policy model, here the traffic optimization policy in DDC use case provides a concrete example for a specific network service, as what constitutes an intent policy could be enforced and executed depending on the context where it is used, e.g. there could be tenant specific policies, site specific, network domain specific etc. 2. Conventions used in this document 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]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying [RFC2119] significance. 3. Policy Based Service Management Framework The usage of policy rules to manage the behavior of one or more managed entities helps to simplify the service deployment and management. Policy is about governance, and can be expressed differently: e.g. ''When this threshold Bi, et al. Expires May 13, 2016 [Page 3] Internet-Draft Declarative Policy Model November 2015 is violated, change the route path of the flow'' is a lower level policy and can be executed with direct operations. ''The links between DCs require LOAD BALANCE'' is a higher level policy which cannot be directly executed. Different users and operators may have different requirements on policies and level of policy abstractions depends on their operational capability and SLA requirements. The document focused on developing a model that abstracts network resources and services and a methodology by which the management and monitoring of network services can be done using standardized policy rules. Figure 1 illustrates the network policy model which contains generic model that has ECA model and intent policy model. +--------------------------------------------+ | Generic Policy | | | | +------------+ +-----------------+ | | | ECA Policy | | Declarative | | | | Data Model | |Policy Data Model| | | +------------+ +-----------------+ | +--------------------------------------------+ Figure 1: Overview of policy model structure 4. Declarative Policy Configuration Modules In this section, an declarative policy model is defined with some high level descriptions on the structure. The policy model and policy configuration are based on a set of specific network services and the framework of SUPA [SUPA- framework]. Meanwhile, the policy model should be working on the orchestration level which is above network element and below OSS level based on the YANG model classification in [draft-bogdanovic-netmod-yang-model classification-02] 4.1. Declarative Policy Framework Unlike the ECA policy model that specify the corresponding action, intent policy only express what should be done, not how to do it. It specifies criteria for choosing a set of states, any of which is acceptable. Moreover, rationality is generated by policy engine by enforcing the policy into real actions and make sure the goal has been fulfilled. In order to express what is needed, the intent policy is defined with description of state and behavior constraint. Desired state: The description of the final state of the system, in another word, the goal or the intent of the policy management. In SUPA scope, it consists of constraints. Here the constraint is defined with First Order Logic (FOL) which has 'predicate' expression to describe the relation or attributes, Bi, et al. Expires May 13, 2016 [Page 4] Internet-Draft Declarative Policy Model November 2015 and 'quantifier' to describe the quantity of the objects in the domain to meet the predicate expression. Behavior constraint: a set of constraints to limit the possible operations or states in processing the policy goal to achieve the final state. Note that state and behavior can be described as constraint or a set of constraints. +--------------------------+ | PolicyRuleMetaData | +--------------------------+ | +--------+------+ | PolicyRule | +-----------+---+ | ---------------------- | | +--------------+ +----------------+ | ECA Policy | | Declarative | | Model | | Policy Model | +--------------+ ++---+-----------+ | | ----------------------- | | | +-----------------+ +---------------------+ | Desired State | | Behavior Constraint | +-----------------+ +---------------------+ Figure 2: Overview of information declarative policy model 4.2. Declarative Policy Model The hierarchy of the intent base policy model is shown as figure 3 and the entire data model is defined as follows. Bi, et al. Expires May 13, 2016 [Page 5] Internet-Draft Declarative Policy Model November 2015 module: ietf-declarative-policy +--rw supa-policy +--rw supa-policy-name? string +--rw supa-policy-priority? uint8 +--rw supa-policy-validity-period | +--rw start? yang:date-and-time | +--rw end? yang:date-and-time | +--rw duration? uint32 | +--rw periodicity? enumeration +--rw supa-policy-target | +--rw profileType? string | +--rw asDomainName? string | +--rw adminSubnetwork? string | +--rw businessTypeName? string | +--rw instance +--rw supa-policy-atomic +--rw supa-intent-policy +--rw policy-rule-deploy-status? enumeration +--rw policy-rule-exec-status? enumeration +--rw intent-policy-rule +--rw desired-state | +--rw constraint | | +--rw quantifier? enumeration | | +--rw object? string | | +--rw predicate? enumeration | | +--rw value? string | +--rw constraint-priority? uint8 +--rw behavior-constraint +--rw constraint? string +--rw constraint-priority? uint8 Figure 3. Hierarchy of the declarative policy data model file "ietf-declarative-policy @2015-10-10.yang'' module ietf-declarative-policy { namespace "urn:ietf:params:xml:ns:yang:ietf-declarative-policy"; // replace with IANA namespace when assigned prefix policy; import ietf-yang-types { prefix yang; } organization "IETF"; Bi, et al. Expires May 13, 2016 [Page 6] Internet-Draft Declarative Policy Model November 2015 contact "Editor: Yiyong Zha"; description "This YANG module defines a component that describing the intent policy data model to describe the states and constraints. Terms and Acronyms "; revision 2015-10-10 { reference "ietf-supa-intent-policy@2015-09-10"; } container supa-policy{ description "This defines a policy data model with intent policy constraint"; leaf supa-policy-name { type string; description "The name of the policy"; } leaf supa-policy-priority { type uint8; description "The priority of the defined policy"; } container supa-policy-validity-period { description "The valid time of the policy. E.g., the policy will be valid 9am-9am daily"; leaf start { type yang:date-and-time; description "When the policy will be start to work."; } leaf end { type yang:date-and-time; description "When the policy will be terminated."; } leaf duration { type uint32; description "How long the policy will be valid."; Bi, et al. Expires May 13, 2016 [Page 7] Internet-Draft Declarative Policy Model November 2015 } leaf periodicity { type enumeration { enum daily { value 0; description "The policy will be repeated daily."; } enum monthly { value 1; description "The policy will be repeated monthly."; } } description "How the policy will be repeated."; } } container supa-policy-target { description "SUPA Policy Target is an abstract class that defines a set of managed objects that may be affected by the actions of the intent policy."; leaf profileType { type string; description "Which profile the policy will be worked on."; } leaf asDomainName { type string; description "Which domain the policy will be worked on."; } leaf adminSubnetwork { type string; description "Which subnet the policy will be worked on."; } leaf businessTypeName { type string; description "Which business the policy will be worked on."; } container instance { description "Which instance the policy will be worked on? E.g., a VPN, a flow or a link"; Bi, et al. Expires May 13, 2016 [Page 8] Internet-Draft Declarative Policy Model November 2015 } } container supa-policy-atomic { description "Define an atomic intent policy."; container supa-intent-policy { description "supa intent policy only describes the desired state and constraints of the policy and what is wanted without telling how to do."; leaf policy-rule-deploy-status { type enumeration { enum undefined{ value 0; description "undefined"; } enum enabled{ value 1; description "deployed and enabled"; } enum in-test{ value 2; description "deployed and in test"; } enum not-enabled{ value 3; description "deployed but not enabled"; } enum ready{ value 4; description "ready to be deployed"; } enum not-deployed{ value 5; description "not deployed"; } } description "Describes the deploy status of the policy."; } leaf policy-rule-exec-status { type enumeration { enum undefined{ value 0; description "undefined"; } Bi, et al. Expires May 13, 2016 [Page 9] Internet-Draft Declarative Policy Model November 2015 enum OPmode-executed-succeeded{ value 1; description "executed and SUCEEDED (operational mode)"; } enum OPmode-executed-failed{ value 2; description "executed and FAILED (operational mode)"; } enum OPmode-executing{ value 3; description "currently executing (operational mode)"; } enum TEmode-executed-succeeded{ value 4; description "executed and SUCEEDED (test mode)"; } enum TEmode-executed-failed{ value 5; description "executed and FAILED (test mode)"; } enum TEmode-executing{ value 6; description "currently executing (test mode)"; } } description "Describes the execution status of the policy."; } container intent-policy-rule { description "The intent policy rule is defined as constraints on states and actions."; grouping FOL-statement { description "SUPA intent policy is based on constraint. The constraint is defined as first order logic statement which consists of quantifier and predicate expression."; leaf quantifier { type enumeration { Bi, et al. Expires May 13, 2016 [Page 10] Internet-Draft Declarative Policy Model November 2015 enum none { value 0; description "None: no one in the set meets certain requirement."; } enum all{ value 1; description "All: all elements in the set meets certain requirement."; } enum exist{ value 2; description "At least one: there is at least one element in the set meets certain requirement."; } enum at-most-one{ value 3; description "At most one: there is at most one element in the set meets certain requirement."; } enum singleton{ value 4; description "Singleton: there is only one element in the set meets certain requirement."; } } description "Quantifier defines the quantity of specimens in the domain of discourse that satisfy an predicate expression."; } leaf object { type string; description "The objects of constraints, which is the elements of the predicate."; } leaf predicate { type enumeration{ enum unknown { Bi, et al. Expires May 13, 2016 [Page 11] Internet-Draft Declarative Policy Model November 2015 value 0; description "Unknown"; } enum match { value 1; description "Match"; } enum greater-than { value 2; description "Greater than"; } enum greater-than-or-equal-to { value 3; description "Greater than or equal to"; } enum less-than { value 4; description "Less than"; } enum less-than-or-equal-to { value 5; description "Less than or equal to"; } enum equal-to { value 6; description "Equal to"; } enum not-equal-to { value 7; description "Not equal to"; } enum in { value 8; description "IN"; } enum not-in { value 9; description "NOT IN"; } } description "A predicate is commonly understood to be a Boolean-valued expression."; } leaf value { type string; description Bi, et al. Expires May 13, 2016 [Page 12] Internet-Draft Declarative Policy Model November 2015 "The value in the predicate expression to describe the relationship of the objects."; } } container desired-state { description "Describes the final state based on user's intent. Just defines one of multiple states without telling how."; container constraint { uses FOL-statement; description "Use first order logic to describe the constraint. FOL statement includes quantifier and predicate to describe the state."; } leaf constraint-priority { type uint8; description "0-7 denotes the priority of this state constraint."; } } container behavior-constraint { description "Describes the constraint on the corresponding actions being performed to achieve the goal or intent."; leaf constraint { type string; description "Describes the constraint on the actions, such as 'gold users remain untouched'."; } leaf constraint-priority { type uint8; description "0-7 denotes the priority of this state constraint."; } } } } } } } Bi, et al. Expires May 13, 2016 [Page 13] Internet-Draft Declarative Policy Model November 2015 5. Declarative Policy Applications in DDC services 5.1. Policy Based Traffic Steering Case study Traffic Steering use case description: In one set of links, keep all link utilization below 70%. If some flows need to move to other link, keep Gold user flows untouched. After analyze above case, we structure the description as following: Related objects: links flow (user type) Goal all link utilization < 70% Constraint: keep Gold user flows untouched The service model of this use case: +--------------+ +--------------+ | Link +--------------+ Flow | +--------------+ m n +--------------+ | uti: float | | bw:int | | phybw: int | | srcip:IPAddr | | | | destip:IPAddr| | | | userlevel: | | | | enum(Gold, | +--------------+ | Normal) | | | +--------------+ Figure 4. Service model of traffic steering policy use case Link attribute Uti: link bandwidth utility Phybw: physical bandwidth of the link Bi, et al. Expires May 13, 2016 [Page 14] Internet-Draft Declarative Policy Model November 2015 Flow attribute bw: the bandwidth of the flow srcip,destip: the source and dest ip address of the flow userlevel: the user's service level of the flow, it can be gold or normal. Bi, et al. Expires May 13, 2016 [Page 15] Internet-Draft Declarative Policy Model November 2015 +--------------+ +--------------+ | Policy |-----|Rule(abstract)| +--------------+ +--------------+ A +-------+ | +-------+------+ | Goal-rule | +--------------+ A V V ----+ subclass +-------+ +------+ | | V +-------------+ +--------------+ ----+ composition | Goal | | behavior | +-------------+ | constraint | +--------------+ Figure 5. policy model of traffic steering policy use case The goal may contain one or multiple constraint, which describe the desired states. In this case, goal has a constraint like following string: no link:Link link.uti > 0.7 above description can be read by the constraint solver combining the service model defined above. It defines a variable "link" and announce it as Link type, and says that there is no link in question, whose uti greater than 0.7(the threshold) There is another constraint that: "If some flows need to move to other link, keep Gold user flows untouched." This is another kind of constraint that confines the behavior, since it assume there are some movement of the flows between links. We call it behavior constraint. Before giving out the behavior constraint programming script, we introduce a 'guide' model first which is internally build for the traffic steering problem domain. The guide model is consumed by a multi-constraint solver. 'Guide' model is the bridge to connect goal to actions. One guide model may cover a problem domain and serve many goal/intent policies. The guide model can be seen in figure 6 Bi, et al. Expires May 13, 2016 [Page 16] Internet-Draft Declarative Policy Model November 2015 +------------------+ | Guide | +------------------+ V V V V | | | +---------------------+ +-----------------+ | +-------+ | | | | +------------+ +----------+ +-------------+ +-----------+ | Action | | Select | | Constraint | | Fact | | Container | +----------+ +-------------+ +-----------+ +------------+ Figure 6. Build in guide model for traffic steering problem domain The Guide model contains 'Select', 'Constraint', 'Fact', 'Action container'. The objective of guide model is to guide the constraint solver output actions which can map to low layer functions. Guide expresses the sentence: 'Select' objects which meet the 'Constraint', following the 'Fact' and output actions formatted in 'Action Container'. 'Select' may coexist with other guidance type to let the constraint solver know the problem solving direction. Most cases of multiple constraint solving can belong to select. For example, select host to run VM, select physical network resource for virtual network path. The Select string in this case: flowset: set Flow linkB: set Link flow:Flow in flowset tolink:Link in linkB 'Constraint' contains all common constraints under this problem domain. It can be extended to express customer's constraints which in goal/intent policy model. Constraint in guide also hides some complexity from customer. The Constraint string in this case: any link1:Link link1.uti>threshold flowset in link1.flows link1 not in linkB 'Fact' is to input some basic behavior of the problem domain to the solver and let the solver can do the work and at the same time keep service agnostic. The Fact string in this case: link1.uti -= flow.bw/link1.phybw tolink.uti+= flow.bw/link1.phybw Bi, et al. Expires May 13, 2016 [Page 17] Internet-Draft Declarative Policy Model November 2015 'Action container' is regulating the output action which solver must output. It connects the goal/intent policy engine to the lower action system. The Action container string in this case: move(flow:Flow,tolink:Link) This action container assume that there is a low layer function corresponds to the abstract move action container and the function can perform the work that move the flow to the target link tolink. Come back to the goal-rule model, there is behavior constraint which extends the Constraint in guide model. The goal in goal-rule also consists of constraints; the behavior constraint is a little different that it confines the intermediate behavior which modeled in the problem domains guide model. The behavior constraint in this case may like follow: threshold = 0.7 no flow.userlevel = Gold Bi, et al. Expires May 13, 2016 [Page 18] Internet-Draft Declarative Policy Model November 2015 5.2. Declarative Policy Enforcement Based on the service model and policy model traffic steering use case introduced in above section, this section introduce an example of policy framework and briefly illustrate how to enforce the declarative policy. +---------------------------------------+ | SUPA policy service API | | | +--------|--------------------|---------+ | | /-------v--------\ /-------v--------\ | Service model | | Policy | | | | repository | \-------|--------/ \-------|--------/ +------------+ | /----------\ +---v-------v---------+ | Context |----->| Policy Engine | | data | | | \----------/ | +-----+ +-------+ | | | ECA | |Intent/| | /----------\ | | | |Goal | | | Event |----->| +-----+ +-------+ | | data | | | \-----A----/ +-----------|---------+ | | +-------------+ +-------------v---------+ | Collector | | Action Scheduler | +-----A-------+ +-------------|---------+ |event v action Figure 7. Intent policy framework as an example Figure 7 shows the example framework. In the framework, the policy engine takes the key role who translates the intent policy to lower layer actions. The policy engine is problem domain agnostic. It depends on service model and policy model to operate on problem domains. Following give some brief illustration around the traffic steering use case that how the policy engine do declarative policy enforcement. First, to inject the capability of operating on traffic steering policy to the policy system, the guide model (see section 5.1) and the service mode (see section 5.1) is input to the system. Bi, et al. Expires May 13, 2016 [Page 19] Internet-Draft Declarative Policy Model November 2015 Then, under some concrete traffic steering scenario, one user can express the intent by transfer the desired state and constraint to the system. After verifying the policy language script against the service model and policy syntax, the policy framework will save the user's intent policy in policy repository. When the policy is activated, the policy engine may get data from context data store, in this case, the data include the link, flow and their relationship information. The policy engine is guided by the guide model and user's intent policy model, evaluates whether some selected data is compatible with the constraints and desired states. After finding out data, the policy engine will fill the tuples which is the result of the 'select' to the action container, in this case is move(flow:Flow,tolink:Link) Finally the policy engine output a list of actions such like move(flow1,link3) move(flow2,link5) move(flow4,link2) ... The flow1, flow2, flow4, link3, link5, link2 all comes from context data store as shown in figure 4. The policy engine even does not know what 'move' is, but the system can map the abstract move action to a con12444crete function at lower layer to perform the movement. The collecting context data, making decision and output action circle may perform one or multiple times to change the traffic steering system to a new steady state and meet the user's intent/goal. 6. Security Considerations TBD 7. IANA Considerations This document has no actions for IANA. Bi, et al. Expires May 13, 2016 [Page 20] Internet-Draft Declarative Policy Model November 2015 8. Acknowledgments This document has benefited from reviews, suggestions, comments and proposed text provided by the following members, listed in alphabetical order: Felix Lu, Juergen Schoenwaelder, John Strassner, and Min Zha. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, October 2010. [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, May 2002. 9.2. Informative References [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-problem-statement] 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. [SUPA-DDC] Y. Cheng,and JF. Tremblay, ''Use Cases for Distributed Data Center Applications in SUPA'', IETF Internet draft, draft-cheng-supa-ddc-use-cases, January 2015. [RESTCONF] Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando, "RESTCONF Protocol", draft-ietf-netconf-restconf (work in progress), July 2014. [POLICY MODEL] Z. Wang, L. Dunbar, Q. Wu, ''Network Policy YANG Data Model'' draft-wang-netmod-yang-policy-dm, January 2015. Bi, et al. Expires May 13, 2016 [Page 21] Internet-Draft Declarative Policy Model November 2015 Authors' Addresses Jun Bi Tsinghua University Network Research Center, Tsinghua University Beijing 100084 P.R. China Email: junbi@tsinghua.edu.cn Qiong Sun China Telecom No.118 Xizhimennei street, Xicheng District Beijing 100035 P.R. China Email: sunqiong@ctbri.com.cn Chongfeng Xie China Telecom No.118 Xizhimennei street, Xicheng District Beijing 100035 P.R. China Email: xiechf@ctbri.com.cn Yiyong Zha Huawei Technologies Section F, Huawei Industrial Base, Longgang District Shenzhen 518129 P.R. China Email: zhayiyong@huawei.com Bi, et al. Expires May 13, 2016 [Page 22]