Internet DRAFT - draft-bi-declarative-policy

draft-bi-declarative-policy



Network Working Group                                                     J. Bi 
Internet Draft                                                   Tsinghua Univ. 
Intended status: Standard Track                                          Q. Sun 
Expires: June 2016                                                       C. Xie 
                                                                  China Telecom 
                                                                         Y. Zha 
                                                            Huawei Technologies 
                                                                     
                                                                     
                                                              December 16, 2015 
 
                                    
                          Declarative Policy Model  
                       draft-bi-declarative-policy-03 


Abstract 

   This document describes a declarative policy model to describe the user's 
   declarative on network policy. The declarative policy model is a specific data 
   model specifies the desired state of the network system. It helps the service 
   management 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 declarative 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 

   This Internet-Draft will expire on June 16, 2015. 
 
 
 
Bi, et al.                 Expires June 16, 2016                    [Page 1] 

Internet-Draft            Declarative Policy Model               December 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 declarativeion will be more expressed by declarative policy. 


 
 
Bi, et al.                 Expires June 16, 2016                    [Page 2] 

Internet-Draft            Declarative Policy Model               December 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 declarative 
   policy 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 declarative 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 declarative 
   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 June 16, 2016                    [Page 3] 

Internet-Draft            Declarative Policy Model               December 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 
   declarative 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, declarative 
   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 declarative 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 declarative 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 June 16, 2016                    [Page 4] 

Internet-Draft            Declarative Policy Model               December 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 declarative base policy model is shown as figure 3 and the 
   entire data model is defined as follows.  










 
 
Bi, et al.                 Expires June 16, 2016                    [Page 5] 

Internet-Draft            Declarative Policy Model               December 2015 
    

   module: ietf-declarative-policy 
      +--rw policy 
         +--rw policy-name?              string 
         +--rw policy-priority?          uint8 
         +--rw policy-validity-period 
         |  +--rw start?         yang:date-and-time 
         |  +--rw end?           yang:date-and-time 
         |  +--rw duration?      uint32 
         |  +--rw periodicity?   enumeration 
         +--rw policy-target 
         |  +--rw profileType?          string 
         |  +--rw domain-name?          string 
         |  +--rw admin-subnet?         string 
         |  +--rw business-type-name?   string 
         |  +--rw instance 
         +--rw policy-atomic 
            +--rw declarative-policy 
               +--rw policy-rule-deploy-status?   enumeration 
               +--rw policy-rule-exec-status?     enumeration 
               +--rw declarative-policy-rule 
                  +--rw desired-state 
                  |  +--rw constraint-on-state 
                  |  |  +--rw quantified-variable 
                  |  |  |  +--rw quantifier?   enumeration 
                  |  |  |  +--rw element?      string 
                  |  |  |  +--rw set?          string 
                  |  |  +--rw predicate 
                  |  |     +--rw object?           string 
                  |  |     +--rw logic-operator?   enumeration 
                  |  |     +--rw value?            string 
                  |  +--rw constraint-priority?   uint8 
                   
    
         Figure 3. Hierarchy of the declarative policy data model 
    
    
    
 <CODE BEGINS> file "ietf-declarative-policy@2015-11-18.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; 
     } 
 
 
Bi, et al.                 Expires June 16, 2016                    [Page 6] 

Internet-Draft            Declarative Policy Model               December 2015 
    

      
     organization "IETF"; 
     contact 
       "Editor: Yiyong Zha"; 
    
     description 
       "This YANG module defines a component that describing 
        the declarative policy data model to describe the states and  
        constraints. 
    
        Terms and Acronyms 
        "; 
       revision 2015-10-10 { 
       reference "ietf-declarative-policy@2015-10-10"; 
     } 
     revision 2015-09-10 { 
       reference "ietf-declarative-policy@2015-9-10"; 
     } 
     container policy{ 
       description 
         "This defines a policy data model with declarative policy  
         constraint"; 
       leaf policy-name {   
         type string; 
         description  
           "The name of the policy"; 
       } 
       leaf policy-priority { 
         type uint8; 
         description 
           "The priority of the defined policy"; 
       } 
       container 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 { 
 
 
Bi, et al.                 Expires June 16, 2016                    [Page 7] 

Internet-Draft            Declarative Policy Model               December 2015 
    

           type uint32; 
           description 
             "How long the policy will be valid."; 
         } 
         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 policy-target { 
         description  
           "SUPAPolicyTarget is an abstract class that  
           defines a set of managed objects that may be  
           affected by the actions of a SUPAPolicyStatement."; 
         leaf profileType { 
           type string; 
           description 
             "Which profile the policy will be worked on."; 
         } 
         leaf domain-name { 
           type string; 
           description 
             "Which domain the policy will be worked on."; 
         } 
         leaf admin-subnet { 
           type string; 
           description 
             "Which subnet the policy will be worked on."; 
         } 
         leaf business-type-name { 
           type string; 
           description 
             "Which business the policy will be worked on."; 
         }   
         container instance  { 
 
 
Bi, et al.                 Expires June 16, 2016                    [Page 8] 

Internet-Draft            Declarative Policy Model               December 2015 
    

           description 
             "Which instance the policy will be worked on? E.g., 
             a VPN, a flow or a link"; 
           }   
       } 
       container policy-atomic { 
         description 
           "Define an atomic declarative policy."; 
         container declarative-policy { 
           description  
             "supa declarative 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{ 
 
 
Bi, et al.                 Expires June 16, 2016                    [Page 9] 

Internet-Draft            Declarative Policy Model               December 2015 
    

                 value 0; 
                 description "undefined";        
               } 
               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 declarative-policy-rule { 
             description 
               "The declarative policy rule is defined as  
               constraints on states and actions."; 
             grouping FOL-statement { 
               description 
                 "SUPA declarative policy is based on constraint.  
                 The constraint is defined as first order logic 
                 statement which consists of quantified variables 
 
 
Bi, et al.                 Expires June 16, 2016                   [Page 10] 

Internet-Draft            Declarative Policy Model               December 2015 
    

                 and predicate expression."; 
               container quantified-variable {  
                 description 
                   "The quantified-variable defines existence  
                   of the element that is being described. It is 
                   the major difference of FOL from propositional 
                   logic."; 
                 leaf quantifier { 
                   type enumeration { 
                     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 some{ 
                       value 2; 
                       description 
                         "At least one: there is at least one  
                         element in the set meets certain  
                         requirement."; 
                     } 
                     enum lone{ 
                       value 3; 
                       description 
                         "Also called 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."; 
                 } 
 
 
Bi, et al.                 Expires June 16, 2016                   [Page 11] 

Internet-Draft            Declarative Policy Model               December 2015 
    

                 leaf element { 
                   type string; 
                   description 
                     "The objects of constraints, which is the  
                     elements of the predicate"; 
                 } 
                 leaf set { 
                   type string; 
                   description 
                     "The set of which the element belongs to. It 
                     is usually pre-defined as policy target or  
                     certain problem domain such as a subnet. "; 
                 } 
               } 
               container predicate { 
                 description 
                   "Predicate expression is no constraint that  
                   holds for all the predefined quantified  
                   variables. "; 
                 leaf object { 
                   type string; 
                   description 
                     "The object of constraints, which is the  
                     subject of the predicate. It can be but  
                     not must be the same of element in quantified  
                     variables."; 
                 } 
                 leaf logic-operator { 
                   type enumeration{ 
                     enum unknown { 
                       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; 
 
 
Bi, et al.                 Expires June 16, 2016                   [Page 12] 

Internet-Draft            Declarative Policy Model               December 2015 
    

                       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  
                       "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  
                 goal. Just defines one of multiple states  
                 without telling how"; 
               container constraint-on-state { 
                 uses FOL-statement; 
                 description 
                   "Use first order logic to describe the  
                   constraint. FOL statement includes  
                   quantifier and predicate to describe the  
                   state."; 
 
 
Bi, et al.                 Expires June 16, 2016                   [Page 13] 

Internet-Draft            Declarative Policy Model               December 2015 
    

               } 
             leaf constraint-priority { 
                 type uint8; 
                 description 
                   "0-7 denotes the priority of this state  
                   constraint"; 
               } 
             } 
           } 
         } 
       }   
     } 
   } 
    
   <CODE ENDS> 
    
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: 







 
 
Bi, et al.                 Expires June 16, 2016                   [Page 14] 

Internet-Draft            Declarative Policy Model               December 2015 
    

    
    
                 +--------------+              +--------------+ 
                 | 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 

  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 June 16, 2016                   [Page 15] 

Internet-Draft            Declarative Policy Model               December 2015 
    

       Please view in a fixed-width font such as Courier. 
    
    
                        +--------------+     +--------------+ 
                        | Policy       |-----|Rule(abstract)| 
                        +--------------+     +--------------+ 
                                                    A 
                                            +-------+ 
                                            | 
                                    +-------+--------------+ 
                                    | Declarative- rule    | 
                                    +----------------------+ 
        A                               V 
    ----+  subclass                     + 
                                        | 
        V                       +----------------------+ 
    ----+  composition          | desired-state        | 
                                +----------------------+ 
    
            Figure 5. policy model of traffic steering policy use case 
                                                    
    
   The desired-state may contain one or multiple constraint, which describe the 
   desired states. In this case, it 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 result, also can be constrained by desired-state. 
    
   Before giving out the 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 declarative policies. 
    
   The guide model can be seen in figure 6 
    
    
    
    
 
 
Bi, et al.                 Expires June 16, 2016                   [Page 16] 

Internet-Draft            Declarative Policy Model               December 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/declarative 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 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 June 16, 2016                   [Page 17] 

Internet-Draft            Declarative Policy Model               December 2015 
    

    
    
   'Action container' is regulating the output action which solver must output. It 
   connects the goal/declarative 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 constraint in this case may like follow: 
   threshold = 0.7 
   no flow.userlevel = Gold 


























 
 
Bi, et al.                 Expires June 16, 2016                   [Page 18] 

Internet-Draft            Declarative Policy Model               December 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 |   |Decla  | | 
                   /----------\      | |     |   |rative | | 
                   | Event    |----->| +-----+   +-------+ | 
                   | data     |      |                     | 
                   \-----A----/      +-----------|---------+ 
                         |                       | 
                   +-------------+ +-------------v---------+ 
                   |  Collector  | |   Action Scheduler    | 
                   +-----A-------+ +-------------|---------+ 
                        |event                  v action 
                                              
              Figure 7. Declarative policy framework as an example 
                                    
   Figure 7 shows the example framework. In the framework, the policy engine takes 
   the key role who translates the declarative 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 June 16, 2016                   [Page 19] 

Internet-Draft            Declarative Policy Model               December 2015 
    

   Then, under some concrete traffic steering scenario, one user can express the 
   declarative 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 declarative 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 
   declarative 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 <flow,link> 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 declarative/goal. 
    
6. Security Considerations 

   TBD 

    

7. IANA Considerations 

   This document has no actions for IANA.  

    





 
 
Bi, et al.                 Expires June 16, 2016                   [Page 20] 

Internet-Draft            Declarative Policy Model               December 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 June 16, 2016                   [Page 21] 

Internet-Draft            Declarative Policy Model               December 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 June 16, 2016                   [Page 22]