nfvrg R. Szabo, Ed. Internet-Draft Ericsson Intended status: Informational S. Lee, Ed. Expires: January 9, 2017 ETRI N. Figueira Brocade July 8, 2016 Policy-Based Resource Management draft-irtf-nfvrg-policy-based-resource-management-01 Abstract abstract to be defined 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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 9, 2017. Copyright Notice Copyright (c) 2016 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. Szabo, et al. Expires January 9, 2017 [Page 1] Internet-Draft Policy-based RM July 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Architecture Considerations . . . . . . . . . . . . . . . . . 4 5.1. MANO Architecture . . . . . . . . . . . . . . . . . . . . 4 5.2. Policies in the MANO Architecture . . . . . . . . . . . . 8 5.3. Global vs Local Policies . . . . . . . . . . . . . . . . 9 5.4. Hierarchical Policy Framework . . . . . . . . . . . . . . 10 5.4.1. Mapping to Hierarchical Resource Orchestration . . . 12 5.5. Policy Pub/Sub Bus . . . . . . . . . . . . . . . . . . . 13 5.5.1. Pub/sub bus in the hierarchical framework . . . . . . 15 5.6. Policy Intent Statement versus Subsystem Actions and Configurations . . . . . . . . . . . . . . . . . . . . . 17 5.7. Static vs Dynamic vs Autonomic Policies . . . . . . . . . 17 5.8. Policy Conflicts and Resolution . . . . . . . . . . . . . 17 5.9. Soft vs Hard Policy Constraints . . . . . . . . . . . . . 17 5.10. Resource management for VNF-FG: end-to-end considerations 17 6. Policy-Based Resource Management Examples . . . . . . . . . . 18 6.1. Policy-Based Multipoint Ethernet Service . . . . . . . . 19 6.2. Policy-Based NFV Placement . . . . . . . . . . . . . . . 19 6.3. Policy-Based Service Function Chaining . . . . . . . . . 19 7. Implementation Examples . . . . . . . . . . . . . . . . . . . 19 8. Gaps and Open Questions . . . . . . . . . . . . . . . . . . . 19 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Relation to other IETF/IRTF activities . . . . . . . . . 19 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 13. Security Considerations . . . . . . . . . . . . . . . . . . . 20 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 14.1. Normative References . . . . . . . . . . . . . . . . . . 20 14.2. Informative References . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction NFV "Point of Presence" (PoP) will be likely constrained in compute and storage capacity. Since practically all NFV PoPs are foreseen to be distributed, inter-datacenter network capacity is also a constraint. Additionally, energy is also a constraint, both as a general concern for NFV operators, and in particular for specific- purpose NFV PoPs such as those in mobile base stations. This draft focuses on the optimized resource management and workload distribution based on policy to address such contraints. Szabo, et al. Expires January 9, 2017 [Page 2] Internet-Draft Policy-based RM July 2016 1.1. Scope For the first version of the draft, only the research group currently adopted drafts (i.e., [I-D.norival-nfvrg-nfv-policy-arch], [I-D.irtf-nfvrg-resource-management-service-chain], and [I-D.unify-nfvrg-recursive-programming]) are considered as inputs to this document. The initial goal is to summarize these inputs and to assess gaps and open questions. 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 [RFC2119]. 3. Definitions This document uses the terms of [ETSI-NFV-TERM]: o MANO - Management and Orchestration: Describes the architecture framework to manage NFVI and orchestrate the allocation of resources needed by the NSs and VNFs. o NF - Network Functions: A functional building block within a network infrastructure, which has well-defined external interfaces and a well-defined functional behavior. o NFV Framework: The totality of all entities, reference points, information models and other constructs defined by the specifications published by the ETSI ISG NFV. o NFVI - NFV Infrastructure: The NFV-Infrastructure is the totality of all hardware and software components which build up the environment in which VNFs are deployed. o NFVI-PoP: A location or point of presence that hosts NFV infrastructure o NFVO - Network Function Virtualization Orchestrator: The NFV Orchestrator is in charge of the network wide orchestration and management of NFV (infrastructure and software) resources, and realizing NFV service topology on the NFVI. o NS - Network service: A composition of network functions and defined by its functional and behavioural specification. Szabo, et al. Expires January 9, 2017 [Page 3] Internet-Draft Policy-based RM July 2016 o VNF - Virtualized Network Function: An implementation of an NF that can be deployed on a Network Function Virtualization Infrastructure (NFVI). o VNF-FG - VNF Forwarding Graph: A NF forwarding graph where at least one node is a VNF. Additionally, we use the following terms: o NFP - Network Forwarding Path: The sequence of hardware/software switching ports and operations in the NFV network infrastructure as configured by management and orchestration that implements a logical VNF forwarding graph "link" connecting VNF "node" logical interfaces. o Virtual Link: A set of connection points along with the connectivity relationship between them and any associated target performance metrics (e.g. bandwidth, latency, QoS). The Virtual Link can interconnect two or more entities (VNF components, VNFs, or PNFs). o Scaling: Ability to dynamically extend/reduce resources granted to the Virtual Network function (VNF) as needed. o NFVIaaS: NFV infrastructure as a service to other SP customers. o SDN: Software Defined Networking. o BSS: Business Support Systems o OSS: Operation Support Systems o DC: Data Center o VM: Virtual machine 4. Requirements tbd 5. Architecture Considerations 5.1. MANO Architecture According to the ETSI MANO framework [ETSI-NFV-MANO], an NFVO is split into two functions (see Figure 1): Szabo, et al. Expires January 9, 2017 [Page 4] Internet-Draft Policy-based RM July 2016 o The orchestration of NFVI resources across multiple VIMs, fulfilling the Resource Orchestration functions. The NFVO uses the Resource Orchestration functionality to provide services that support accessing NFVI resources in an abstracted manner independently of any VIMs, as well as governance of VNF instances sharing resources of the NFVI infrastructure o The lifecycle management of Network Services, fulfilling the network Service Orchestration functions. Similarly, a VIM is split into two functions (see Figure 1): o Orchestrating the allocation/upgrade/release/reclamation of NFVI resources (including the optimization of such resources usage), and o managing the association of the virtualised resources to the physical compute, storage, networking resources. Szabo, et al. Expires January 9, 2017 [Page 5] Internet-Draft Policy-based RM July 2016 +-------------------+ |NVFO | | +--------------+ | | |NFVO: | | | |Service | | | |Lifecycle | | | |Management | | | +------+-------+ | | | | | +------+-------+ | | |NFVO: | | | |Resource | | | |Orchestration | | | +--+---+----+--+ | +-----|---|----|----+ / | \ /---------/ | \------------\ / | \ +-------------|-----+ +--------|----------+ +------|------------+ |VIM | | |VIM | | |VIM | | | +----------+---+ | | +-----+--------+ | | +---+----------+ | | |VIM: | | | |VIM: | | | |VIM: | | | |Orchestration | | | |Orchestration | | | |Orchestration | | | |& | | | |& | | | |& | | | |Optimization | | | |Optimization | | | |Optimization | | | +------+-------+ | | +------+-------+ | | +------+-------+ | | | | | | | | | | | +------+-------+ | | +------+-------+ | | +------+-------+ | | |VIM: | | | |VIM: | | | |VIM: | | | |Virtualized 2 | | | |Virtualized 2 | | | |Virtualized 2 | | | |Pys mapping | | | |Pys mapping | | | |Pys mapping | | | +--------------+ | | +--------------+ | | +--------------+ | +-------------------+ +-------------------+ +-------------------+ Figure 1: Functional decomposition of the NFVO and the VIM according to the ETSI MANO In Figure 2 we show various policies mapped to the MANO architecture (see Section 5.2 for more dicussions on policies in the MANO architeture): o Tenant Policies: Tenant policies exist whenever a domain offers a virtualization service to more than one consumer. User tenants may exists at the northbound of the NFVO. Additionally, if a VIM exposes resource services to more than one NFVO, then each NFVO may appear as a tenant (virtualization consumer) at the northbound of the VIM. Szabo, et al. Expires January 9, 2017 [Page 6] Internet-Draft Policy-based RM July 2016 o Wherever virtualization services are produced or consumed corresponding export and import policies may exist. Export policies govern the details of resources, capabilities, costs, etc. exposed to consumers. In turn, consumers (tenants) apply import policies to filter, tweak, annotate resources and services received from their southbound domains. An entity may at the same time consume and produce virtualization services hence apply both import and export policies. o Operational policies support the business logic realized by the domain's ownership. They are often associated with Operations or Business Support Systems (OSS or BSS) and frequently determine operational objectives like energy optimization, utilization targets, offered services, charging models, etc. Operational policies may be split according to different control plane layers, for example, i) lifecycle and ii) resource management layers within the NFVO. Szabo, et al. Expires January 9, 2017 [Page 7] Internet-Draft Policy-based RM July 2016 T1 T2...Tn | | | +-----|--|---|------+ |NVFO | | | | Tenant | +--+--+---+----+ | <- Policies | |NFVO: | | Operational | |Service | | Policies-> | |Lifecycle | | | |Management | | | +------+-------+ | | | | | +------+-------+ | | |NFVO: | | Operational | |Resource | | Policies-> | |Orchestration | | ^ | +--+---+----+--+ | |Import to +-----|---|---------+ |Policies other NFVO / \ \ +-------+ \ \ / \ to NFVO ^ +------\------|-----+ \ / |Export |VIM \ | | \ / |Policies | +-----+----+---+ | +--------|----|-----+ | |VIM: | | |VIM | | | Tenant | |Orchestration | | | +-----+----+---+ | <- Policies | |& | | | |VIM: | | | |Optimization | | . | |Orchestration | | | +------+-------+ | . | |& | | <- Operational | | | | |Optimization | | Policies | +------+-------+ | | +------+-------+ | | |VIM: | | | | | | |Virtualized 2 | | | +------+-------+ | | |Pys mapping | | | |VIM: | | <- Operational | +--------------+ | | |Virtualized 2 | | Policies +-------------------+ | |Pys mapping | | | +--------------+ | +-------------------+ Figure 2: Policies within the MANO framework 5.2. Policies in the MANO Architecture The current industry work in the area of policy for NFV is mostly considered in the framework of general cloud services, and typically focused on individual subsystems and addressing very specific use cases or environments. For example, [ETSI-NFV-WHITE-PAPER] addresses network subsystem policy for network virtualization, [ODL-GB-POLICY] and [ODL-NIC-PROJECT] are open source projects in the area of network Szabo, et al. Expires January 9, 2017 [Page 8] Internet-Draft Policy-based RM July 2016 policy as part of the OpenDaylight [ODL-SDN-CONTROLLER] software defined networking (SDN) controller framework, [RFC3060] specifies an information model for network policy, [VM-HOSTING-NET-CLUSTER] focuses on placement and migration policies for distributed virtual computing, [OPENSTACK-CONGRESS] is an open source project proposal in OpenStack [OPENSTACK] to address policy for general cloud environments. A policy framework applicable to the MANO architure must consider NFV services from the perspective of overall orchestration requirements for services involving multiple subsystems (e.g., Figure 1 and Figure 2). While this document discusses policy atributes as applicable to the MANO architecture, the general topic of policy has already been intensively studied and documented on numerous publications over the past 10 to 15 years (see [RFC3060], [POLICY-FRAMEWORK-WG], [RFC3670], [RFC3198], and [CERI-DATALOG] to name a few). This document's purpose is to discuss and document a policy framework applicable to the MANO architecture using known policy concepts and theories to address the unique requirements of NFV services including multiple PoPs and networks forming hierarchical domain architectures [SDN-MULTI-DOMAIN]. With the above goals, this document analyses "global versus local policies" (Section 5.3), a "hierarchical policy framework" (Section 5.4) to address the demanding and growing requirements of NFV environments, a "policy pub/sub bus in the hierarchical framework" (Section 5.5), "policy intent versus subsystem actions" (Section 5.6), "static versus dynamic versus autonomic policies" (Section 5.7), "policy conflict detection and resolution" (Section 5.8), and "soft versus hard policy constraints" (Section 5.9), which can be relevant to resource management in service chains [RESOURCE-MGMT-SERVICE-CHAIN]. 5.3. Global vs Local Policies Some policies may be subsystem specific in scope, while others may have broader scope and interact with multiple subsystems. For example, a policy constraining certain customer types (or specific customers) to only use certain server types for VNF or Virtual Machine (VM) deployment would be within the scope of the compute subsystem. A policy dictating that a given customer type (or specific customers) must be given "platinum treatment" could have different implications on different subsystems. As shown in Figure 8, that "platinum treatment" could be translated to servers of a given performance specification in a compute subsystem and storage of a given performance specification in a storage subsystem. Szabo, et al. Expires January 9, 2017 [Page 9] Internet-Draft Policy-based RM July 2016 Policies with broader scope, or global policies, would be defined outside affected subsystems and enforced by a global policy engine (Figure 3), while subsystem-specific policies or local policies, would be defined and enforced at the local policy engines of the respective subsystems. Examples of sub-system policies can include thresholds for utilization of sub-system resources, affinity/anti-affinity constraints with regard to utilization or mapping of sub-system resources for specific tasks, network services, or workloads, or monitoring constraints regarding under-utilization or over- utilization of sub-system resources. +----------------------------------------------------------------+ | +----------------------------------------------+ | | | Global Policy Engine | | | +----------------------------------------------+ | | | | +----------------------------------------------+ | | | Global Policies | | | +----------------------------------------------+ | +----------------------------------------------------------------+ ^ ^ ^ ^ | | | | V V V V +-------------+ +-------------+ +-------------+ +-------------+ |Compute | |Network | |Storage | |Whatever | |Subsystem | |Subsystem | |Subsystem | |Subsystem | | | | | | | | | |Local Policy | |Local Policy | |Local Policy | |Local Policy | |Engine | |Engine | |Engine | |Engine | | | | | | | | | |Local | |Local | |Local | |Local | |Policies: | |Policies | |Policies | |Policies | | P0, P1, | | P0, P1, | | P0, P1, | | P0, P1, | | | | | | | | | +-------------+ +-------------+ +-------------+ +-------------+ Figure 3: Global versus Local Policy Engines 5.4. Hierarchical Policy Framework So far, we have referenced compute, network, and storage as subsystems examples. However, the following subsystems may also support policy engines and subsystem specific policies: o SDN Controllers, e.g., OpenDaylight [ODL-SDN-CONTROLLER]. Szabo, et al. Expires January 9, 2017 [Page 10] Internet-Draft Policy-based RM July 2016 o OpenStack [OPENSTACK] components such as, Neutron, Cinder, Nova, and etc. o Directories, e.g., LDAP, ActiveDirectory, and etc. o Applications in general, e.g., standalone or on top of OpenDaylight or OpenStack. o Physical and virtual network elements, e.g., routers, firewalls, application delivery controllers (ADCs), and etc. o Energy subsystems, e.g., OpenStack Neat [OPENSTACK-NEAT]. Therefore, a policy framework may involve a multitude of subsystems. Subsystems may include other lower level subsystems, e.g., Neutron [OPENSTACK-NEUTRON] would be a lower level subsystem in the OpenStack subsystem. In other words, the policy framework is hierarchical in nature, where the policy engine of a subsystem may be viewed as a higher level policy engine by lower level subsystems. In fact, the global policy engine in Figure 3 could be the policy engine of a Data Center subsystem and multiple Data Center subsystems could be grouped in a region containing a region global policy engine. In addition, one could define regions inside regions, hierarchically, as shown in Figure 4. Metro and wide-area network (WAN) used to interconnect data centers would also be independent subsystems with their own policy engines. Szabo, et al. Expires January 9, 2017 [Page 11] Internet-Draft Policy-based RM July 2016 To higher level domain ^ Region 1 | Domain V +-------------------+ +-------------------+ | +---------------+ | | +---------------+ | | |Region 1 Global| |<------>| |WAN 1 Global | | | |Policy Engine | | | |Policy Engine | | | +---------------+ | | +---------------+ | | | | | | +---------------+ | | +---------------+ | | |Whatever | | | |Whatever | | | |Subsystems | | | |Subsystems | | | | | | | | | | | |Local Policy | | | |Local Policy | | | |Engines | | | |Engines | | | +---------------+ | | +---------------+ | +-------------------+ +-------------------+ ^ ^ | | | +-------------------------+ | | DC 1 Domain V DC N Domain V +-------------------+ +-------------------+ | +---------------+ | | +---------------+ | | |DC 1 Global | | | |DC N Global | | | |Policy Engine | | | |Policy Engine | | | +---------------+ | | +---------------+ | | | | | | +---------------+ | | +---------------+ | | |Whatever | | | |Whatever | | | |Subsystems | | | |Subsystems | | | | | | | | | | | |Local Policy | | | |Local Policy | | | |Engines | | | |Engines | | | +---------------+ | | +---------------+ | +-------------------+ +-------------------+ Figure 4: A Hierarchical Policy Framework 5.4.1. Mapping to Hierarchical Resource Orchestration If the MANO framework is extended to multi layer hierarchies [I-D.unify-nfvrg-recursive-programming], then a potential mapping of the hierarchical policies to the MANO architecture is shown in Figure 5 Szabo, et al. Expires January 9, 2017 [Page 12] Internet-Draft Policy-based RM July 2016 T1 T2...Tn +--|--|----|---+ | | |Service | Domain 4 | Orchestrator| ************************************ +--+-----------+ T1 T2...Tn *******|****************** Tenant Policies -> +--|--|----|---+ | | NFVO: | | | Service | | <-Domain Policies | Lifecycle | | | Orchestrator | | +-------+------+ / Domain 3 | / ******************** +-+---------+--+ <-Tenant Policies * |NFVO: | ****************** * |Rersource | <-Domain Policies T1 T2...Tn * * |Orchestration | +--|--|----|---+ * * +--+---+-------+ | NFVO: | * ********|***|************************ | Service | * / | | Lifecycle | /---------/ | <-Domain Policies | Orchestrator | / * | +---------+----+ | * | | | * | +--+-------+---+* | <-Tenant Policies | |* | |NFVO: |* | <-Domain Policies |Rersource |* | |Orchestration |* | +------+-------+* | /|\ * *********|********** +------+-------+* * +------+-------+ * <-Tenant Policies +--|a/VIM: |* * |VIM: | * +--|b |Resource |* * |Resource | * <-Domain Policies |c | |Orchestrationn|* * |Orchestration | * | | +--------------+* * +--------------+ * Domain 1 * * Domain 2 * ************************ * * Figure 5: Policies in a Hierarchical Orchestration View 5.5. Policy Pub/Sub Bus In [I-D.irtf-nfvrg-nfv-policy-arch] the authors argued for the need of policy subsystems to subscribe to policy updates at a higher policy level. A policy publication/subscription (pub/sub) bus would be required as shown in Figure 6. Szabo, et al. Expires January 9, 2017 [Page 13] Internet-Draft Policy-based RM July 2016 +----------------------------------------------------------------+ | +----------------------------------------------+ | | | Global Policy Engine | | | +----------------------------------------------+ | | | | +----------------------------------------------+ | | | Global Policies | | | +----------------------------------------------+ | +----------------------------------------------------------------+ ^ | | Policy Pub/Sub Bus V -------------------------------------------------------------- ^ ^ ^ ^ | | | | | | | | V V V V +-------------+ +-------------+ +-------------+ +-------------+ |Compute | |Network | |Storage | |Whatever | |Subsystem | |Subsystem | |Subsystem | |Subsystem | | | | | | | | | |Local Policy | |Local Policy | |Local Policy | |Local Policy | |Engine | |Engine | |Engine | |Engine | | | | | | | | | |Local | |Local | |Local | |Local | |Policies: | |Policies | |Policies | |Policies | | P0, P1, | | P0, P1, | | P0, P1, | | P0, P1, | | | | | | | | | +-------------+ +-------------+ +-------------+ +-------------+ Figure 6: A Policy Pub/Sub Bus A higher tier policy engine would communicate policies to lower tier policy engines using a policy pub/sub bus. Conversely, lower tier policy engines would communicate their configured policies and services to the higher tier policy engine using the same policy pub/ sub bus. Such communications require each policy pub/sub bus to have a pre-defined/pre-configured policy "name space". For example, a pub/sub bus could define services using the name space "Platinum", "Gold", and "Silver". A policy could then be communicated over that pub/sub bus specifying a Silver service requirement. In a hierarchical policy framework, a policy engine may use more than one policy pub/sub bus, e.g., a policy pub/sub bus named "H" to communicate with a higher tier policy engine and a policy pub/sub bus named "L" to communicate with lower tier policy engines. As the name spaces of policy pub/sub buses H and L may be different, the policy Szabo, et al. Expires January 9, 2017 [Page 14] Internet-Draft Policy-based RM July 2016 engine would translate policies defined using the policy pub/sub bus H name space to policies defined using the policy pub/sub bus L name space, and vice-versa. 5.5.1. Pub/sub bus in the hierarchical framework Figure 7 shows the Pub/sub bus in the hierarchical MANO framework. Policy communications would employ a policy pub/sub bus between the subsystems' policy engines in the policy hierarchy (see Section 5.4). The global NFVO subsystem should have visibility into the policies defined locally at each PoP to be able to detect any potential global policy conflicts, e.g., a local PoP administrator could add a local policy that violates or conflicts with a global policy. In addition, the global NFVO subsystem would benefit from being able to import the currently configured services at each PoP. The global NFVO would use such information to monitor global policy conformance and also to facilitate detection of policy violations when new global policies are created, e.g., a global level administrator is about to add a new global policy that, if committed, would make certain already configured services a violation of the policy. The publication of subsystem service tables for consumption by a global policy engine is a concept used in the Congress [OPENSTACK-CONGRESS] OpenStack [OPENSTACK] project. Szabo, et al. Expires January 9, 2017 [Page 15] Internet-Draft Policy-based RM July 2016 Customers | V +--------------+ | Web Portal | +--------------+ ^ | V +-----------------+ +-----------------+ | OSS/BSS | | Global NFVO | | +-------------+ | | +-------------+ | | |OSS/BSS | | Policy | |NFVO | | | |Policy Engine|<---------->|Policy Engine| | | +-------------+ | | +-------------+ | | | | ^ | | ... | | | ... | +-----------------+ +--------|--------+ | Policy (Pub/Sub Bus) V ------------------------------------------- ^ ^ ^ | | | +-------|-------+ +-------|-------+ +-------|-------+ | PoP A | | | PoP B | | | PoP C | | | V | | V | | V | | +-----------+ | | +-----------+ | | +-----------+ | | |Local NFVO | | | |Local NFVO | | | |Local NFVO | | | | +-------+ | | | | +-------+ | | | | +-------+ | | | | |Policy | | | | | |Policy | | | | | |Policy | | | | | |Engine | | | | | |Engine | | | | | |Engine | | | | | +-------+ | | | | +-------+ | | | | +-------+ | | | +-----------+ | | +-----------+ | | +-----------+ | | ^ | | ^ | | ^ | | | | | | | | | | | V | | V | | V | | +-----------+ | | +-----------+ | | +-----------+ | | |VIM | | | |VIM | | | |VIM | | | | +-------+ | | | | +-------+ | | | | +-------+ | | | | |Policy | | | | | |Policy | | | | | |Policy | | | | | |Engine | | | | | |Engine | | | | | |Engine | | | | | +-------+ | | | | +-------+ | | | | +-------+ | | | +-----------+ | | +-----------+ | | +-----------+ | | ... | | ... | | ... | +---------------+ +---------------+ +---------------+ Figure 7: Pub/sub bus in the hierarchical MANO framework Szabo, et al. Expires January 9, 2017 [Page 16] Internet-Draft Policy-based RM July 2016 5.6. Policy Intent Statement versus Subsystem Actions and Configurations Content to be merged +----------------------------------------------------------------+ | Policy: "a given customer must be given Platinum treatment" | +----------------------------------------------------------------+ ^ ^ ^ ^ | | | | V V V V +-------------+ +-------------+ +-------------+ +-------------+ |Compute | |Network | |Storage | |Whatever | |Subsystem | |Subsystem | |Subsystem | |Subsystem | | | | | | | | | |Policy | |Policy | |Policy | |Policy | |translation: | |translation: | |translation: | |translation: | | | | | | | | | |Install | |Give customer| |Give customer| | ... | |customer VMs | |the best QoS,| |the fastest | | | |on servers | |which | |SSD storage. | | | |with 3GHz | |translates | | | | | |16-core Xeon | |here to set | | | | | |processors, | |DHCP to xx, | | | | | |and etc. | |and etc. | | | | | +-------------+ +-------------+ +-------------+ +-------------+ Figure 8: Example of Subsystem Translations of Policy Actions 5.7. Static vs Dynamic vs Autonomic Policies Content to be merged 5.8. Policy Conflicts and Resolution Content to be merged 5.9. Soft vs Hard Policy Constraints Content to be merged 5.10. Resource management for VNF-FG: end-to-end considerations Another subsystem example for the policy framework is VNF-FG. While the target KPIs of individual VNFs and VLs are pre-configured in their descriptors, the KPIs of a network service instance are determined by coupled performances and capabilities of VNF instances Szabo, et al. Expires January 9, 2017 [Page 17] Internet-Draft Policy-based RM July 2016 and VL instances that constitute the VNF-FG. For example, if one of the VNF instances or VL instances along the VNF-FG gets overloaded, the end-to-end network service may also get affected. Thus, the chained performances and capabilities of VNF and VL instances need to be considered at enforcing the service policies. Another important factor for VLs is the inter-connectivity between different NFVI-PoPs, which is an enabler of resource sharing among different NFVI-PoPs. When the VNF instances of a network service are allocated at different NFVI-PoPs, the NFVI-PoP interconnect may be a bottleneck point of the VNF-FG which needs to be monitored to support KPIs of the network service. In order to address the aforementioned considerations, it is required to support resource management capability for VNF-FG by considering resource state or KPIs of VNF instances and VL instances which connect them. The resource management operations for VNF-FG are related to the following operations in VNFM and VIM: o Locate VNF instances o Evaluate the performance of VNF instances and VL instances o Relocate (or scale) VNF instances o Monitor state or KPIs of a VNF instance, VL instances including NFVI-PoP interconnects Studies about evaluation methodologies and performance metrics for VNF instances and NFVI resources can be found at [ETSI-NFV-PER001] [I-D.liu-bmwg-virtual-network-benchmark] [I-D.ietf-bmwg-virtual-net]. The performance metrics of VNF instances and VL instances related to VNF-FG can be defined as follows: o topological location of a VNF instance o throughput of a VNF instance o energy consumption of a VNF instance o throughput of a VL instance 6. Policy-Based Resource Management Examples Szabo, et al. Expires January 9, 2017 [Page 18] Internet-Draft Policy-based RM July 2016 6.1. Policy-Based Multipoint Ethernet Service Content to be merged 6.2. Policy-Based NFV Placement Content to be merged 6.3. Policy-Based Service Function Chaining Content to be merged 7. Implementation Examples tbd 8. Gaps and Open Questions tbd 9. Conclusions tbd 9.1. Relation to other IETF/IRTF activities tbd 10. Acknowledgements The research leading to some of the results described in this document has received funding from the European Union Seventh Framework Programme (FP7/2007-2013) under grant agreement no. 619609 - the UNIFY project. The views expressed here are those of the authors only. The European Commission is not liable for any use that may be made of the information in this document. 11. Contributors This document is the result of merging multiple drafts. This section acknowledges those who provided important ideas and text into this document. o Z. Qiang (Ericsson), M. Kind (DT-AG) from [I-D.unify-nfvrg-recursive-programming] o R. Krishnan (Dell), D. Lopez (Telefonica) and S. Wright (AT&T) from [I-D.irtf-nfvrg-nfv-policy-arch] Szabo, et al. Expires January 9, 2017 [Page 19] Internet-Draft Policy-based RM July 2016 o S. Lee (ETRI), S. Pack (KU), M-K. Shin (ETRI) and E. Paik (KT) from [I-D.irtf-nfvrg-resource-management-service-chain] 12. IANA Considerations tbd 13. Security Considerations tbd 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, "Policy Core Information Model -- Version 1 Specification", RFC 3060, DOI 10.17487/RFC3060, February 2001, . [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J., and S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, DOI 10.17487/RFC3198, November 2001, . [RFC3670] Moore, B., Durham, D., Strassner, J., Westerinen, A., and W. Weiss, "Information Model for Describing Network Device QoS Datapath Mechanisms", RFC 3670, DOI 10.17487/RFC3670, January 2004, . 14.2. Informative References [CERI-DATALOG] Ceri, S. and others, "What you always wanted to know about Datalog (and never dared to ask", IEEE Transactions on Knowledge and Data Engineering, (Volume: 1, Issue: 1), August 2002. [ETSI-NFV-MANO] ETSI, "Network Function Virtualization (NFV) Management and Orchestration V0.6.3", October 2014. Szabo, et al. Expires January 9, 2017 [Page 20] Internet-Draft Policy-based RM July 2016 [ETSI-NFV-PER001] ETSI, "Network Function Virtualization: Performance and Portability Best Practices v1.1.1", June 2014. [ETSI-NFV-TERM] ETSI, "NFV Terminology for Main Concepts in NFV", October 2013. [ETSI-NFV-WHITE-PAPER] ETSI NFV White Paper, "Network Functions Virtualisation, An Introduction, Benefits, Enablers, Challenges, & Call for Action", . [I-D.ietf-bmwg-virtual-net] Morton, A., "Considerations for Benchmarking Virtual Network Functions and Their Infrastructure", draft-ietf- bmwg-virtual-net-03 (work in progress), June 2016. [I-D.irtf-nfvrg-nfv-policy-arch] Figueira, N., Krishnan, R., Lopez, D., Wright, S., and D. Krishnaswamy, "Policy Architecture and Framework for NFV Infrastructures", draft-irtf-nfvrg-nfv-policy-arch-03 (work in progress), March 2016. [I-D.irtf-nfvrg-resource-management-service-chain] Lee, S., Pack, S., Shin, M., Paik, E., and R. Browne, "Resource Management in Service Chaining", draft-irtf- nfvrg-resource-management-service-chain-03 (work in progress), March 2016. [I-D.liu-bmwg-virtual-network-benchmark] Liu, V., Liu, D., Mandeville, B., Hickman, B., and G. Zhang, "Benchmarking Methodology for Virtualization Network Performance", draft-liu-bmwg-virtual-network- benchmark-00 (work in progress), July 2014. [I-D.norival-nfvrg-nfv-policy-arch] Figueira, N., Krishnan, R., Lopez, D., and S. Wright, "Policy Architecture and Framework for NFV Infrastructures", draft-norival-nfvrg-nfv-policy-arch-04 (work in progress), June 2015. [I-D.unify-nfvrg-recursive-programming] Szabo, R., Qiang, Z., and M. Kind, "Towards recursive virtualization and programming for network and cloud resources", draft-unify-nfvrg-recursive-programming-02 (work in progress), October 2015. Szabo, et al. Expires January 9, 2017 [Page 21] Internet-Draft Policy-based RM July 2016 [ODL-GB-POLICY] "OpenDaylight Group Based Policy", . [ODL-NIC-PROJECT] "OpenDaylight Network Intent Composition Project", . [ODL-SDN-CONTROLLER] "OpenDaylight SDN Controller", . [OPENSTACK] "OpenStack", . [OPENSTACK-CONGRESS] "OpenStack Congress", . [OPENSTACK-NEAT] "OpenStack Neat", . [OPENSTACK-NEUTRON] "OpenStack Neutron", . [POLICY-FRAMEWORK-WG] "Policy Framework Working Group (IETF)", . [RESOURCE-MGMT-SERVICE-CHAIN] Lee, S. and others, "Resource Management in Service Chaining", . [SDN-MULTI-DOMAIN] Figueira, N. and R. Krishnan, "SDN Multi-Domain Orchestration and Control: Challenges and Innovative Future Directions", IEEE International Conference on Computing (ICNC), February 2015. [VM-HOSTING-NET-CLUSTER] Grit, L. and others, "Virtual Machine Hosting for Networked Clusters: Building the Foundations for "Autonomic" Orchestration", Virtualization Technology in Distributed Computing (VTDC), 2006. Szabo, et al. Expires January 9, 2017 [Page 22] Internet-Draft Policy-based RM July 2016 Authors' Addresses Robert Szabo (editor) Ericsson Konyves Kaman krt. 11 Budapest, EMEA 1097 Hungary Phone: +36703135738 Email: robert.szabo@ericsson.com Seungik Lee (editor) ETRI 218 Gajeong-ro Yuseung-Gu Daejeon 305-700 Korea Phone: +82 42 860 1483 Email: seungiklee@etri.re.kr Norival Figueira Brocade Email: nfigueir@Brocade.com Szabo, et al. Expires January 9, 2017 [Page 23]