Network Working Group J. Bi Internet Draft Tsinghua University Intended status: Standard Track R. Tadepalli Expires: August 2015 Wipro Limited M. Hayashi KDDI R&D Labs. Inc. February 16, 2015 DDC Service Policy YANG Data Model draft-bi-supa-policy-model-00 Abstract This document describes a YANG data model for traffic steering policies in Distributed Data Center (DDC) scenarios. The policy model is a specific data model for traffic steering using VPN technology. It helps the service management in Simplified Use of Policy Abstractions (SUPA) to model the policy (a set of constraints and rules) that defines how a VPN service is monitored by bandwidth and managed during its lifecycle. Two traffic steering applications have been provided such as traffic optimization with pass or bypass specific nodes or sites. 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 August 16, 2015 [Page 1] Internet-Draft SUPA Policy Model February 2015 This Internet-Draft will expire on August 16, 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. Network Configuration Model Overview .........................4 4. Network Policy Configuration Modules .........................4 4.1. Network Policy Model ....................................4 4.2. Policy Applications in DDC services .....................5 4.2.1. Model for Traffic Steering Policy ..................7 5. Security Considerations .....................................10 6. IANA Considerations .........................................10 7. Acknowledgments .............................................11 8. References ..................................................11 8.1. Normative References ...................................11 8.2. Informative References .................................11 1. Introduction In order to support the DDC service with VPN connection as well as new services, it brings new requirements for both network providers and service providers. Rapid uptake of new services requires dynamic service provisioning capabilities in the service management. This is achieved 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. A policy defines: Bi, et al. Expires August 16, 2015 [Page 2] Internet-Draft SUPA Policy Model February 2015 1. An event or a set of events that trigger the evaluation of policy: This is the trigger for the service management application to evaluate if a policy needs to be applied. For example a user action to provision a new VPN service can be a event. 2. A set of conditions that need to be satisfied for the policy to be applicable: This enables service management to select the right policy by validating the conditions against the current network state. 3. A set of actions that should be triggered as part of the policy execution: This enables the service management to provision the service. 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. With respect to the scope, defining an information model for the policy exchange between the policy manager and policy agent and a corresponding data model based on yang to support specific DDC service use case is initial goal of this document. The protocol specific aspects are deferred to respective implementations. Also certain foundational concepts of the model are intentionally left open to enable future extension. Here the traffic steering policy in DDC use case provides a concrete example for a specific network technology and service, as what constitutes a policy could itself vary 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 Bi, et al. Expires August 16, 2015 [Page 3] Internet-Draft SUPA Policy Model February 2015 only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying [RFC2119] significance. 3. Network Configuration Model Overview Figure 1 illustrates the network configuration model which contains several modules for specific services such as VPN management. Basically, service model is to define the creation and configuration of the VPN service, while the policy model is more focused on the adjustment or optimization of the flow path during the lifecycle of the VPN service based on the predefined policy. +------------------------------------------+ | Service Management | | | | +------------+ +------------+ | | | Service | | Policy | | | | Data Model | | Data Model | | | +------------+ +------------+ | +------------------------------------------+ Figure 1: Overview of configuration model structure 4. Network Policy Configuration Modules In this section, a policy model is defined with an application for traffic steering between data centers are provided to illustrate how to use the policy model. The policy model and policy configuration are based on a set of specific network services and the framework of SUPA [SUPA-framework]. 4.1. Network Policy Model In SUPA framework, network 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. Among different types of policy models, the SUPA policy model is focused on an E-C-A (Event-Condition-Action) YANG data model. Within SUPA scope, the service management system takes the E-C-A fashioned policy model to handle the VPN management in the data center use case to improve bandwidth utilization and facilitate service deployment. Event: a significant occurrence in time that triggers the evaluation of the condition of the policy rule Bi, et al. Expires August 16, 2015 [Page 4] Internet-Draft SUPA Policy Model February 2015 Condition: a set of tests that determine if the actions of the policy rule should be executed or not Action: a set of operations that should be performed if the condition is true Note that event, condition, and action can each be made up of Boolean clauses module: SUPA-policy +--rw policy-set +--rw SetName string +--rw SetType enumeration +--rw applicable-service-type enumeration +--rw policy-rule +--rw rule-name string +--rw rule-type enumeration +--rw priority uint8 +--rw policy-time-period +--rw start yang:date-and-time +--rw end yang:date-and-time +--rw duration? uint32 +--rw periodicity enumeration +--rw event +--rw EventType enumeration +--rw value uint32 +--rw condition string +--rw variable string +--rw match enumeration +--rw action +--rw pass string +--rw bypass string 4.2. Policy Applications in DDC services More specifically, for the networking system an E-C-A based policy model can cover use cases as follows: Network Policy -event: -- bandwidth usage -- port N status -- TTL value - condition : -- bandwidth usage > x Bi, et al. Expires August 16, 2015 [Page 5] Internet-Draft SUPA Policy Model February 2015 -- port N is up -- TTL < y - action: -- adjust flow -- use backup link -- retry For the first one, if the bandwidth usage of a contain link is above threshold, the flow will be adjusted. The event is the link bandwidth usage, the condition is bandwidth usage above the x and the action is to adjust the flow. The second one is, if the port N is up, the system will use backup link. The third one is, if the TTL is below y, retry. The following describes SUPA policy model designed for DDC services use case [SUPA-DDC] to do the traffic steering among DCs. [SUPA-DDC] took a large-scale Internet Data Center (IDC) operator as an example to describe what SUPA needs to do in VPN-based traffic steering. Here the policy model only focus on the policy based traffic steering application. The traffic steering policy is used in dynamical link configuration in DDC services [SUPA-DDC]. The service management can dynamically adjust the traffic flow in the links based on traffic steering policy. The policy model specifies some high level requirements to the links, like routing strategy. For example in this specific traffic steering policy model, if the link bandwidth usage is above certain threshold, the monitored flow will be forced to routed to the third place to bypass the overloaded node or site. Module "ietf-supa-policy" defines E-C-A based policy model to describe the policy management in DDC service. In effect, the module can be expanded with more operation services for DDC services. Bi, et al. Expires August 16, 2015 [Page 6] Internet-Draft SUPA Policy Model February 2015 module: ietf-supa-policy +--rw DDC-policy +--rw traffic-steering-flow-path* [vpn-name] +--rw vpn-name string +--rw vpn-type? enumeration +--rw flow-name? string +--rw TrafficSteeringPolicy +--rw bandwidth +--rw Type enumeration +--rw value uint32 +--rw threshold string +--rw match enumeration +--rw action +--rw pass string +--rw bypass string +--NodeList string +--SiteList string 4.2.1. Model for Traffic Steering Policy module ietf-supa-policy { namespace "urn:ietf:params:xml:ns:yang:ietf-supa-policy"; // replace with IANA namespace when assigned prefix policy; import ietf-inet-types { prefix inet; } organization "IETF"; contact "Editor: Jun Bi junbi@tsinghua.edu.cn "; description "This YANG module defines a component that describing the ddc policy model for monitoring and optimizing tenant's DC (data center) services that are deployed in multiple data centers. Terms and Acronyms DDC: Distributed Data Center L2VPN: Layer 2 Virtual Private Network L3VPN: Layer 3 Virtual Private Network"; revision 2015-02-05 { Bi, et al. Expires August 16, 2015 [Page 7] Internet-Draft SUPA Policy Model February 2015 description "Initial revision."; reference " Network Policy YANG Data Model "; } container ddc-policy{ description "Distributed Data Center Service Operation Data"; container specify-flow-paths { description "To improve the bandwidth utilization (or reduce the cost, or other reason) and mitigate traffic congestion,management system/ application requires controller to adjust certain flows to pass/bypass certain nodes(or links), when, e.g., bandwidth utilization exceed certain threshold. Vpn name, vpn type, adjusted flow and specified nodes (that the flow should pass) should be told to controller. so that the controller can configure the network elements to change the VRF table and routing table"; list specify-flow-path { key "vpn-name"; description "The list of VPN and flow that need to be adjusted in specific paths. So as to optimizing traffic in the links that are between data centers."; leaf vpn-name { type string; mandatory true; description "Indicates the name of VPN that the adjusted flow belongs to. A VPN instance is identified by vpn-name. It should be one of the created VPN instance names"; } leaf vpn-type { type enumeration { enum L2VPN { description "L2VPN"; } enum L3VPN { description "L3VPN"; } } Bi, et al. Expires August 16, 2015 [Page 8] Internet-Draft SUPA Policy Model February 2015 description "Indicates the type of VPN instance that the adjusted flow belongs to. L2VPN or L3VPN"; } leaf flow-name { type string; description "The name of the adjusted flow. So as to tell the Controller which flow should be adjusted"; } Container TrafficSteeringPolicy{ list bandwidth { key "type"; leaf Type { type enumeration { enum utilization { description "the link utilization ratio, 0-100%"; } enum BW { description "the bandwidth value, 2G,10G e.g."; } } } leaf Value { type uint32; } } list threshold { key "match"; leaf match { type enumeration { enum above { description "if the value is above the threshold"; } enum below { description "if the value is below the threshold"; } } } Bi, et al. Expires August 16, 2015 [Page 9] Internet-Draft SUPA Policy Model February 2015 } container action { leaf pass { type string description " pass action, if the policy is triggered, certain nodes or sites will be passed"; } leaf bypass { type string description " bypass action, if the policy is triggered, certain nodes or sites will be bypassed"; } Leaf-list NodeList { type string; description " List of nodes that the adjusted flow needs to pass or bypass So as to adjust the flow path between data centers."; } Leaf-list SiteList { type string; description " List of sites that the adjusted flow needs to pass or bypass So as to adjust the flow path between data centers."; } } } } } } 5. Security Considerations TBD 6. IANA Considerations This document has no actions for IANA. Bi, et al. Expires August 16, 2015 [Page 10] Internet-Draft SUPA Policy Model February 2015 7. Acknowledgments This document has benefited from reviews, suggestions, comments and proposed text provided by the following members, listed in alphabetical order: Jing Huang, Junru Lin, Felix Lu, Juergen Schoenwaelder, Yiyong Zha, and Min Zha. 8. References 8.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. 8.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. Bi, et al. Expires August 16, 2015 [Page 11] Internet-Draft SUPA Policy Model February 2015 [POLICY MODEL] Z. Wang, L. Dunbar, Q. Wu, "Network Policy YANG Data Model" draft-wang-netmod-yang-policy-dm, January 2015. Authors' Addresses Jun Bi Tsinghua University Institute for Network Sciences and Cyberspace, Tsinghua University Beijing 100084, China Email: junbi@cernet.edu.cn Raghavendra Tadepalli Wipro Limited Email: raghav.rao@wipro.com Michiaki Hayashi KDDI R&D Labs. Inc. 2-1-15 Ohara, Fujimino, Saitama, Japan. 356-8502 Email: mc-hayashi@kddilabs.jp Bi, et al. Expires August 16, 2015 [Page 12]