Network Working Group M. Klyus Internet Draft NetCracker Intended status: Standard Track J. Strassner Expires: December 2015 Huawei Technologies June 6, 2015 SUPA Proposition draft-klyus-supa-proposition-00 Abstract The rapid increase in enterprise and service provider network architecture complexity makes operating and managing services much more difficult. Simplified Use of Policy Abstractions (SUPA) defines a generic policy information model, and associated generic YANG data models, for different types of policy rules that control managed entities throughout the service development and deployment lifecycle. It also defines a mapping by which the management and monitoring of network services can be done using standardized policy rules. 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 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." Klyus, et al. Expires September 6, 2015 [Page 1] Internet-Draft SUPA - Proposition June 2015 Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction .................................................. 3 1.1. Problem Statement ........................................ 4 1.2. Requirements ............................................. 6 2. Terminology ................................................... 7 3. Framework for Generic Policy-based Management ................. 9 3.1. Overview ................................................. 9 3.2. Functional Entities ..................................... 12 3.2.1. Service Management ................................. 12 3.2.2. Network Manager/Controller ......................... 12 3.2.3. Network Elements ................................... 14 3.3. Generic Management Policy Information Model ............. 14 3.4. Refinement of the SGPIM ................................. 15 3.4.1. Event-Condition-Action Policy Information Model .... 15 3.4.2. Declarative Policy Information Model ............... 15 3.4.3. Data Model Mappings ................................ 15 4. Application of Generic Policy-based Management ............... 15 4.1. Declarative Example ..................................... 16 4.2. ECA Example ............................................. 16 4.3. ECA plus Declarative Example ............................ 17 5. Related Work ................................................. 18 5.1. Related Work within the IETF ............................ 18 5.1.1. I2RS Working Group ................................. 18 5.1.2. L3SM Working Group ................................. 18 5.1.3. ALTO Working Group ................................. 18 5.1.4. TEAS Working Group ................................. 19 5.1.5. BESS Working Group ................................. 19 5.1.6. SFC Working Group .................................. 20 5.1.7. NVO3 Working Group ................................. 20 5.1.8. ACTN Working Group ................................. 20 Klyus, et al. Expires December 6, 2015 [Page 2] Internet-Draft SUPA - Proposition June 2015 5.2. Related Work outside the IETF ........................... 21 5.2.1. TM Forum ........................................... 21 5.2.2. MEF ................................................ 22 5.2.3. Open Daylight ...................................... 23 5.2.4. Open Networking Foundation ......................... 23 5.2.5. OpenStack .......................................... 23 5.2.6. The NEMO Project ................................... 24 5.2.7. The Floodlight Project ............................. 25 5.2.8. The ONOS Project ................................... 25 5.3. Technical Implementation Scenarios ...................... 25 6. Framework Summary ? Features and Benefits .................... 25 7. Security Considerations ...................................... 26 8. IANA Considerations........................................... 26 9. Acknowledgments .............................................. 26 10. References .................................................. 26 10.1. Normative References ................................... 26 10.2. Informative References ................................. 26 1. Introduction Network operators, including Internet Service Providers, Datacenters operators and others, are under constant pressure to optimize the usage of their installed network resources while maintaining high availability, complexity and deploying new services at an ever-increasing pace. The introduction of new paradigms aims at reducing these efforts, optimized network resource usage and minimize operational overhead. Such a new paradigm is the deployment of automated network configuration and optimization through the use of two complementary mechanisms that are software abstractions to simplify monitoring and control operations and the increase in programmatic control over the configuration and operation of such networks. Policy-based management can be used to combine these two mechanisms into an extensible framework. Management applications would benefit from a view of the network that is adapted to their needs and from a policy framework that is efficient and simple to use. Several organizations have started working on protocols and models to be used between controllers and network devices, either physical ones or virtualized. This work started some years ago in a number of different organizations and has spawned a large amount of interest in the networking community. However the definition of interfaces between controllers and applications, the so-called "northbound" side, has seen a lot less progress during the same time. There's a need for management applications to interface with controllers in a Klyus, et al. Expires December 6, 2015 [Page 3] Internet-Draft SUPA - Proposition June 2015 simple and elegant way. For this purpose, applications require a way to express their requirements in the form of simple policy statements applied to network elements. These network elements should be as simplified (abstracted) as possible for their manipulation by the application. The responsibility of providing an abstract and simple view adapted to each application need is the burden of the controller. The goal of the Simplified Use of Policy Abstractions (SUPA) group is to develop a methodology by which network services can be managed and automated by using a set of information policy model and how these model can map to YANG- based service and policy data models. It also focus on how to communicate these policy models. SUPA will focus in the first phase on inter-datacenter traffic management as part of the distributed data center use case, including the set of information models required to construct an extensible, policy- based framework. These information models will lead to a set of core YANG data models for a policy-based management framework to monitor and control network services. 1.1. Problem Statement Network operators are faced with networks of increasing size and complexity while trying to improve their quality and availability, as more and more business services depend on them. Software abstractions simplify the design and configuration of monitoring and control operations, and enable more powerful programmatic control (often called software-defined) to be exerted. These are considered by many network operators as an essential tool toward the management of that complexity. Providing means to network operators to (1) express policies on top of arbitrary configuration data models and (2) represent and use multiple types of policy rules, enable significant improvements in configuration agility, error detection and uptime for operators. This section describes the problems that need to be addressed in order to equip service providers with a generic policy-based management model that can represent multiple types of policy rules to quickly and dynamically manage their offering of network services. The rapid growth in the variety and importance of traffic flowing over increasingly complex enterprise and service Klyus, et al. Expires December 6, 2015 [Page 4] Internet-Draft SUPA - Proposition June 2015 provider network makes the task of network operations and management applications and of deploying new services much more difficult. This is a significant challenge that network operators (service providers, SME, etc) face today. Several mechanisms can be used to deal with this challenge. The main ones are: (1) the use of software abstractions to simplify the design and configuration of monitoring and control operations and (2) the use of programmatic control over the configuration and operation of such networks. The combination of these mechanisms can (1) provide additional and significant benefits in design and deployment agility and (2) be used to define a generic policy-based management model. In particular, the power of policy management is its applicability to many different types of systems. Many different types of actors can be identified that can use a policy management system, including applications, end-users, developers, network administrators and operators. Each of these actors, typically, has different skills and uses different concepts and terminologies. For example, an operator may want to express that only Platinum and Gold users can use streaming and interactive multimedia applications. As a second example, an operator may want to define a more concrete policy rule that looks at the number of dropped packets. If, for example, this number exceeds a certain threshold value, then the applied queuing, dropping and scheduling algorithms could be changed in order to reduce the number of dropped packets. Both examples can be referred to as "policy rules", but they take very different forms, since they are at very different levels of abstraction and likely authored by different actors. The first example described a very abstract policy rule, and did not contain any technology-specific terms, while the second example included a more concrete policy rule and likely used technical terms of a general (e.g., IP address range, port numbers) as well as vendor-specific nature (e.g., specific algorithms implemented in a particular device). Furthermore, these two policy rules could affect each other. For example, Gold and Platinum users might need different device configurations to give the proper QoS markings to their streaming multimedia traffic. This is very difficult to do if a common policy framework does not exist. It needs to be mentioned that there are ongoing policy modeling efforts in IETF. However, all these policy modeling efforts can Klyus, et al. Expires December 6, 2015 [Page 5] Internet-Draft SUPA - Proposition June 2015 be characterized as being technology-specific. This means that the IETF needs to reinvent the wheel in different colors (i.e., policy models that apply for a specific technology) several times. SUPA will address these challenges by: (1) developing an information model fragment for defining standardized policy rules at different levels of abstraction, (2) specifying how to map this information fragment into corresponding YANG [RFC6020] and [RFC6991], data models to define interoperable implementations that can exchange and modify generic policies using protocols such as NETCONF/RESTCONF on the interface north of the controller (or other similar management entity) and south of the service manager. Specifically, three information model fragments are envisioned: (a) a generic policy information model (GPIM) that defines concepts needed by policy management independent of the form and content of the policy (b) a more specific information model that refines the generic information model to specify how to build policy rules of the event-condition-action (ECA) paradigm (c) a more specific information model that refines the generic information model to specify how to build policy rules that declaratively specify what goals to achieve (but not how to achieve those goals); this is often called "intent-based" policy 1.2. Requirements In order to satisfy the challenges mentioned in Section 1.1 and the goal of the DDC use case briefly described in section 5.3, the following requirements need to be addressed: o) Specify a generic and non-technology specific policy information model. o) Specify a more specific information model that defines how to build policy rules of the event-condition-action (ECA) paradigm. o) Specify a more specific information model that defines how to build policy rules that declaratively specify what Klyus, et al. Expires December 6, 2015 [Page 6] Internet-Draft SUPA - Proposition June 2015 goals (what intents) to achieve using the Goal (Intent) policy paradigm. o) Specify how to map the above mentioned information models into corresponding YANG standardized data models to define interoperable implementations that can exchange and modify generic policies using protocols such as NETCONF/RESTCONF on the interface north of the controller (or other similar management entity) and south of the service manager. 2. Terminology This section defines acronyms and terms used in the rest of this document. NE Network Element NC Network Controller NM Network Manager NS Network Service Some of definitions are based on [RaBe11] and/or [Stras02]. Network Service: the composition of network functions as defined by its functional and behavioral specification. A network service is characterized by performance, dependability, and security specifications. Furthermore, a network service is delivered by network service endpoints, which may be aggregations of multiple lower-layer technology specific endpoints. Network Element: a physical or virtual entity that implements one or more network function(s). NEs can interact with local or remote network controllers in order to exchange information, such as configuration information and status. Service specific abstraction: an abstract view of the service topology, associated with a specific network service type, e.g., inter-datacenter communication services Policy: a definite goal, course, or method of action to guide and determine present and future decisions. Policies are implemented or executed within a particular context. SUPA policy: a means to monitor and control the changing and/or maintaining of the state of one or more managed entities. Klyus, et al. Expires December 6, 2015 [Page 7] Internet-Draft SUPA - Proposition June 2015 Policy-based management: the usage of policy rules to manage one or more entities. Information Model: a representation of managed objects and their relationships that is independent of data repository, language, and protocol. Data Model: a representation of managed objects and their relationships that is dependent on data repository, language, and/or protocol (typically all three). Policy Rule: A container that uses metadata to define how the content is interpreted, and hence, how the behavior that it governs is defined separates the content of the policy from its representation provides a convenient control point for OAMP operations. Policy condition: a representation of the necessary state and/or prerequisites that define whether a policy rule?s actions should be performed. Policy action: defines what is to be done to enforce a policy rule when its conditions are met. Event Condition Action policy: reactive behavior of a system that correlates a set of events, a set of conditions, and a set of actions. Conditions are evaluated on the occurrence of an event and which determine whether the policy is applicable or not for that particular situation. Furthermore, the actions are only executed only if the conditions are met. Goal (Intent) policy rule (also called a declarative policy rule, or an intent-based policy rule): a declarative statement that defines what the policy should do, but not how to implement the policy. Model Mapping: a translation from one type of model to another type of model. Model mapping changes the representation and/or level of abstraction used to another representation and/or level of abstraction. The most common form of model mapping is from an information model to a data model; another important form is from a vendor-neutral data model to a vendor-specific data model. Klyus, et al. Expires December 6, 2015 [Page 8] Internet-Draft SUPA - Proposition June 2015 3. Framework for Generic Policy-based Management The SUPA policy framework defines a set of consistent, flexible, and scalable mechanisms for monitoring and controlling resources and services. It may be used to create a management and operations interface that can enable existing IETF frameworks, including but not limited to I2RS and L3SM. It allows resources and services to be controlled and monitored in a unified way that is independent of technology and vendor. Resource and service management become more effective, because policy defines the context that different operations, such as configuration, are applied to. 3.1. Overview +----------------------------------------------------------------- | Service Management | | +----------------------------------+ | | | Generic Policy Information Model | | | +----+------------------------+----+ | | D R | | D R | | \ / \ / | | +---------------------------+ +-------------------------------+ | | | Generic Policy Data Model | | Service Management Data Model | | | +---------------------------+ +---------------+---------------+ | | / \ / \ | | | | | | | NETCONF/RESTCONF | | | +----+----------------------+----+ | | C C | | C C | | \ / \ / | | +----------------+-----------+ +-------+--------------------+ | | | Network Manager/Controller | | Network Manager/Controller | | | | +--------------------+ | | +---------------------+ | | | | | Network Resource | | | | Network Resource | | | | | | Data Model | | | | Data Model | | | | | +--------------------+ | | +---------------------+ | | | +----------------------------+ +----------------------------+ | +------+---+---+-------------------------+---+---+----------------+ / \ / \ / \ / \ / \ / \ Klyus, et al. Expires December 6, 2015 [Page 9] Internet-Draft SUPA - Proposition June 2015 C C C C C C C C C C C C C C C C C C \ / \ / \ / \ / \ / \ / NE1 NE2 NEn NE1 NE2 NEn Figure 1 SUPA Framework In Figure 1: A double-headed arrow with Cs means communication; A double-headed arrow with Ds means derived from; A double-headed arrow with Rs means references; An overview of the SUPA framework is shown in Figure 1. The network entities used in this framework are: SM: Service Management, which represents one or more network entities that are running and controlling network services. This model contains the following entities: Generic Policy Information Model: a model for defining policy rules that are independent of data repository, data definition, query, and implementation languages, and protocol. Generic Policy Data Model: a model of policy rules for that are dependent of data repository, data definition, query, and implementation languages, and protocol. Examples of policy information models can be found in [ID.draft-strassner-supa-generic-policy-info-model] and [ID.draft-bi-supa-policy-model]. There can be various types of policies, including service specific policies and network-wide policies. There can be a centralized and/or distributed entity or set of entities that are responsible for the creation, management, and retirement policy rules, which is known as a policy manager. The policy manager can be located in the SM or in a separate location. Policy data models now considered by SUPA take two forms: (1) ECA (event, condition, action) and (2) declarative (also known as intent-based), as described in [ID.draft-strassner-supa-generic-policy-info-model]. This may Klyus, et al. Expires December 6, 2015 [Page 10] Internet-Draft SUPA - Proposition June 2015 be extended in the future. Service Management Data Model: a model of the network service (e.g., VPNs) and resources (e.g., a device interface) required by the network service to be correctly deployed and executed on the physical and/or virtual topology. An example of a service management data model can be found in [ID.draft-zaalouk-supa-vpn-service-management-model]. NM/NC: Network Manager / Controller, which represents one or more entities that are able to control the operation and management of a network infrastructure (e.g., a network topology that consists of Network Elements (NEs)). Network Resource Data Model: a model of the physical and virtual network topology including the resource attributes (e.g., data rate or latency of links) and operational parameters needed to support service deployment over the network topology. An example of a network resource data model can be found in [ID.draft-contreras-supa-yang-network-topo]. SUPA will not define network resource data models, which is out of the scope of SUPA. SUPA will make use of network resource data models defined by other WGs or SDOs. Network Element (NE), which handles packets based on the network management and controlling procedures. NEs can interact with local or remote NM/NC in order to exchange information, such as configuration information, policy enforcement capabilities, and network status. Service Management (SM) communicates with the NM/NC using an appropriate protocol, such as NETCONF [RFC6241] or RESTCONF [ID.draft-ietf-netconf-restconf]. NM/NC exchanges configuration information with NEs and derives the current network topology that contains the NEs, and also the capabilities and status of NEs, which will be stored in network Klyus, et al. Expires December 6, 2015 [Page 11] Internet-Draft SUPA - Proposition June 2015 resource data model. NM/NC may also communication with a network management system to retrieve the above information. It can use existing network management and signaling protocols, such as I2RS [I2RS], NETCONF [NETCONF], RESTCONF [ID.draft-ietf-netconf- restconf], etc. Service Management (SM) will send policy rules and associated data (e.g., service management data), both in the form of a data model, To the NM/NC. The NM/NC will (in conjunction with network resource data models) then produce NE configurations. 3.2. Functional Entities 3.2.1. Service Management There are a wide variety of communication services offered by service providers. The Service Management (SM) is a functional entity, residing at the Application layer, which enables network services, such as: o) Network services (e.g., L2VPN, L3VPN, etc.) o) application-specific policies SM will push service management data model and policy data model to NM/NC for service deployment. 3.2.2. Network Manager/Controller | | to/from Service Management | +--------------------------+----------------------------------------+ | Network Manager/Controller Functional Block | | +-------------------------------+ +---------------------------+ | | | NM/NC to SM Interface | | mapping: Policy Data | | | +-------------------------------+ | Model + Network Resource | | | | Data Model to Service | | | +-------------------------------+ | Specific Topology | | | | | +---------------------------+ | | | Network Resource Data Model | | | | | +---------------------------+ | | +-------------------------------+ | mapping: Service Data | | Klyus, et al. Expires December 6, 2015 [Page 12] Internet-Draft SUPA - Proposition June 2015 | | Model + Service Specific | | | +-------------------------------+ | Topology to Detail NEs' | | | | NM/NC to NE Interface | | Configurations | | | +-------------------------------+ +---------------------------+ | +-------------------------------------------------------------------+ Figure 2 NM/NC Functional Blocks Network Manager/Controller (NM/NC) is a functional entity that is able to generate and maintain desired and current topologies of the network infrastructure. As part of this process, it is also responsible for reserving and releasing network resources that are required to support network services in a given network infrastructure. The NM/NC contains a set of data models, functions and APIs, including: o) Network Resource Data Model Maintain an up to date topology of the network infrastructure, including capabilities and current status of NEs. o) Mapping: service specific topology This mapping procedure will combine the policy data model and service management data model and generate a specific topology. o) Mapping: target NE(s) detail configurations This mapping procedure will use the service specific topology generated in the previous procedure and the service management data model to generate detail NE(s) configurations. o) NM/NC to traditional network management system interface: provides the interface with existing network management system protocols (e.g., I2RS [I2RS], NETCONF, etc.) to request configuration and status information, and push configuration changes to NEs. o) NM/NC to SM interface: used to support the communication between the SM and NM/NC. The candidate protocols used for this purpose could be either NETCONF [RFC6241] or RESTCONF [ID.draft- ietf-netconf-restconf]. Klyus, et al. Expires December 6, 2015 [Page 13] Internet-Draft SUPA - Proposition June 2015 An example of the mapping procedures can be that, a service requires that a link from A to B is created; and the policy requires that the hops of this link should not exceed N. Then when NM/NC receives the policy data model and service management data model from SM, it will first apply the policy data model to the network resource data model and get a sub-set topology which can fulfill the hops limit requirements. Then NM/NC will further generate detail configurations for target NE(s). The mapping procedures can be enforced by functional entity called policy agent. After the service is deployed, if there is a network topology change, network configurations for this service may need to be updated accordingly. A possible solution is to repeat the mapping procedures, and generate configurations for NEs (maybe another set of NEs). This requires that NM/NC maintains a copy of the service management data models and policy data models. For more detail about mapping mechanisms, please refer to [ID.draft-pentikousis-supa-mapping]. 3.2.3. Network Elements The Network Element (NE) responds to requests and commands from the NM/NC and makes corresponding configuration changes. An NE may be a physical or a virtual entity, and is locally managed (e.g., via CLI, SNMP, or NETCONF). SUPA will specify mechanisms, in order to enable the NEs to interact with either local or remote network management systems. The interaction may include the exchange of information, such as configuration and status information. The NEs will be able to push this information in an event that the NM/NC can subscribe to, and/or provide this information after receiving a request from the NM/NC. 3.3. Generic Management Policy Information Model The purpose of the SUPA Generic Policy Information Model (SGPIM) is to define a common framework for expressing policies at different levels of abstraction. SUPA uses the SGPIM as a common vocabulary for representing concepts that are common to expressing policy, but which are independent of language, Klyus, et al. Expires December 6, 2015 [Page 14] Internet-Draft SUPA - Proposition June 2015 protocol, repository, and level of abstraction. This enables different policies at different levels of abstraction to form a continuum, where more abstract policies can be translated into more concrete policies, and vice-versa. 3.4. Refinement of the SGPIM An information model is abstract. As such, it cannot be instantiated (i.e., objects cannot be created directly from it). Therefore, SUPA defines a mapping from its information model to two different data models (which can be instantiated). These two data models represent two different forms of policy rules, with two different sets of semantics. One is an event- condition-action (ECA) form, while the other is a declarative, or logic-based, form. This provides two different types of abstractions that serve different use cases. It also helps prove the genericity of the SGPIM. 3.4.1. Event-Condition-Action Policy Information Model The SUPA ECA Policy Rule Information Model (EPRIM) represents a policy rule as a statement that consists of an event clause, a condition clause, and an action clause. This type of Policy Rule explicitly defines the current and desired states of the system being managed. 3.4.2. Declarative Policy Information Model The SUPA Logic Statement Information Model (SLSIM) is a set of (logic-based) propositions that form a (single) conclusion. A proposition is either TRUE or FALSE. A proposition be created from simpler propositions. This version of the SGPIM defines two forms of SUPA Logic Statements: one using propositional logic, and one using first order logic. 3.4.3. Data Model Mappings The SGPIM defines concepts common to any type of policy rule or statement. It is used in combination with the EPRIM or the SLSIM to create a reusable model of a policy. This combined information model is then mapped to a YANG data model. 4. Application of Generic Policy-based Management This section provides examples of how SUPA can be used to define different types of policies. Examples applied to various Klyus, et al. Expires December 6, 2015 [Page 15] Internet-Draft SUPA - Proposition June 2015 domains, including access control, routing, and service function chaining, are also included. 4.1. Declarative Example Declarative policies are policies that describe what to do, but not how to do it. Declarative policies can apply to services and/or resources. Here are some simple examples: Access to source code servers is limited to Intranet users. The above policy does not specify ports, protocols, IP addresses, or other specific technology. Furthermore, it is not limited to any one specific user or application. Periodically perform workload consolidation if average CPU utilization falls below X%. Again, note the lack of technology-specific references in the policy. Proactively monitor Gold Service users to ensure their SLAs are not violated. In the above policy, Gold Service is an aggregation of different traffic types, each with different constraints. The policy will dynamically create a service function chain based on the current context to ensure that the customer's SLA is not violated. 4.2. ECA Example ECA equivalents to the above three examples follow. Access to source code servers is limited to Intranet users. Event: access request to code server received Condition: is connection type intranet based Action: no: deny; yes: accept Periodically perform workload consolidation if average CPU utilization falls below X%. Event: alarm or periodic time period check Condition: CPU utilization level comparison Action: no violation: no action violation: 1) determine workload profile in time interval 2) determine complementary workloads (e.g., Klyus, et al. Expires December 6, 2015 [Page 16] Internet-Draft SUPA - Proposition June 2015 whose peaks are at different times in day) 3) combine workloads (e.g., using integer programming) Proactively monitor Gold Service users to ensure their SLAs are not violated. Event: alarm or periodic time check Condition: is SLA metric set in danger of being violated Action: no: no action yes: based on metric(s) being violated, take one or more actions such as remark, change queuing, dropping, and/or scheduling parameters (or even the algorithm), create new service to offload traffic, etc. In the above examples, the event, condition, and/or action clauses are typically expressed using technology-specific concepts. This is in direct contrast to their declarative equivalents. 4.3. ECA plus Declarative Example The fundamental reason that SUPA defines two different types of policy rules is to enable different actors to express policy in a manner conducive to their role. The SGPIM defines concepts that are common to both the EPRIM and the SLSIM. This enables these two types of policies to be used together to provide a more powerful description. For example, consider the second example above. The declarative policy is conceptually more abstract than its ECA counterpart, since the declarative version expresses intent without defining which specific managed entities are affected. The execution of the declarative example could result in one or more ECA policy rules being triggered. Similarly, an ECA policy rule could trigger additional ECA policy rules to be evaluated. The advantage of this approach is that policy, along with metadata, can be used to dynamically decide which service functions to insert into a path (instead of being restricted to a fixed, linear set of service functions). Klyus, et al. Expires December 6, 2015 [Page 17] Internet-Draft SUPA - Proposition June 2015 5. Related Work 5.1. Related Work within the IETF 5.1.1. I2RS Working Group I2RS defines an interface that interacts with the routing system using a collection of protocol-based control or management interfaces. Users of I2RS interfaces are typically management applications and controllers. SUPA is an I2RS client, and does not directly interface to the routing system. Rather, SUPA uses data produced by I2RS (e.g., topological information) to construct its policies. The SUPA use case involved distributed data center interconnection; this use case defines a multi-tenant environment, where each tenant may control and monitor its network, even if that network may be physically located in a different data center. In contrast, I2RS defines interfaces to routing system (i.e., the collection of entities, protocols, and processes that collectively build the forwarding tables that are exported to the network's forwarding plane). It is envisioned that SUPA will use work produced by I2RS. SUPA may also provide policies that can be used by I2RS to monitor and control the routing system. Since both SUPA and I2RS uses YANG data models, communication between the two groups is facilitated. 5.1.2. L3SM Working Group L3SM defines an L3 VPN service model that can be used for communication between customers and network operators. This model enables customers to configure the network elements via L3 VPN technologies. In contrast, SUPA defines policies that are independent of a specific type of service, and hence conceptually, provides policies that define the configuration requirements for L3 VPN models that L3SM then implements. Both SUPA and L3SM use YANG data models. 5.1.3. ALTO Working Group The ALTO working group defined an architecture for exposing topology information, more specifically the cost of paths through an infrastructure, as defined in [RFC7285]. ALTO services are able to provide network maps defined as groups of endpoints. Endpoints are provider-defined entities, and can therefore represent any granularity of network, from the Klyus, et al. Expires December 6, 2015 [Page 18] Internet-Draft SUPA - Proposition June 2015 physical to groups of networks following similar paths or restraints. Although this model can represent different levels of abstraction at multiple granularities, it is not clear if it could be adapted easily for other purposes than providing cost maps in the context of ALTO. The ALTO model is meant to be used outside of the trust domain of an ISP by external clients. SUPA does not generate data that is similar to ALTO. Rather, SUPA could use ALTO data as part of its policies to configure services and/or resources. SUPA could also interact with ALTO by defining policies that tell the host which ALTO server to use. 5.1.4. TEAS Working Group The Traffic Engineering Architecture and Signaling working group is responsible for defining MPLS- and GMPLS-based Traffic Engineering architectures that enable operators to control how specific traffic flows are treated within their networks. It covers YANG models for a traffic engineering database, in coordination with other working groups (I2RS) providing YANG models for network topologies. Both TEAS and SUPA use YANG data models. SUPA does not generate traffic engineering (TE) data. However, SUPA could use TE data as part of its policies for configuring resources and/or services. SUPA could also define policies that define which service, path, and link properties to use for a given customer, and consequently, which protocol extensions to use. TEAS data could also be used to enable operators to define how particular traffic flows are treated in a more abstract (but still consistent) manner. 5.1.5. BESS Working Group The BGP Enabled Services defines and extends network services that are based on BGP. This includes BGP/MPLS IP provider- provisioned L3VPNs, L2VPNs, BGP-enabled VPN solutions for use in data center networking, and extensions to BGP-enabled solution to construct virtual topologies in support of services such as Service Function Chaining. The working group is also chartered to work on BGP extensions to YANG models and data models for BGP-enabled services. Both BESS and SUPA use YANG data models. SUPA does not generate BGP configurations. However, SUPA could use data defined by Klyus, et al. Expires December 6, 2015 [Page 19] Internet-Draft SUPA - Proposition June 2015 BESS as part of its policies for configuring resources and/or services. SUPA could also define policies that define that govern different aspects of services defined by BESS. 5.1.6. SFC Working Group The Service Function Chaining (SFC) working group defines a mechanism where traffic is classified; that classification is then use to select an ordered set of services to pass the traffic through. Both SFC and SUPA use YANG data models. SUPA could define policies that augment the functionality of SFC in several different ways, including: (1) path selection based on context, (2) which set of mechanisms to use to steer traffic through which set of service functions, (3) simplify the definition of dynamic service function chains (e.g., service paths that change based upon a set of data that is discovered at runtime), and (4) scalable mechanisms to monitor and control the configuration of SFC components. 5.1.7. NVO3 Working Group The NVO3 group proposes a way to virtualize the network edge for data centers in order to be able to move virtual instances without impacting their network configuration. This is realized through a centrally controlled overlay layer-3 network. The NVO3 work is not about defining policy information. Both NVO3 and SUPA use YANG data models. SUPA could define policies that define how the logically centralized network virtualization management entity (or entities) of NVO3 behave (e.g., the functions in the network virtualization control plane). 5.1.8. ACTN Working Group The ACTN proposed work, as described in [actn] framework, has two main goals, the abstraction of multiple optical transport domains into a single controller offering a common abstract topology and the splitting of that topology into abstract client views, which are usually a fraction of the complete network. The ACTN work is therefore about unification of several physical controllers in a virtual one and also about the segmentation, isolation and sharing of network resources. The ACTN work is not explicitly about policies, but some level Klyus, et al. Expires December 6, 2015 [Page 20] Internet-Draft SUPA - Proposition June 2015 of policing is applied in the creation of a client view and the way it interacts with the virtual controller beneath. One point where overlap may exist with some of the work proposed in SUPA is in the definition of multiple levels of abstract topologies. The ACTN proposed work, as described in [actn] framework, has two main goals, the abstraction of multiple optical transport domains into a single controller offering a common abstract topology, and the splitting of that topology into abstract client views, which are usually a fraction of the complete network. The ACTN work is therefore about unification of several physical controllers into a virtual one, and also about the segmentation, isolation and sharing of network resources. The ACTN work is not about defining policy information. Both SFC and SUPA use YANG data models. SUPA could define policies that define the behavior of the controller. 5.2. Related Work outside the IETF 5.2.1. TM Forum The TM Forum (a.k.a., the TeleManagement Forum) develops standards and best practices, research, and collaborative programs focused on digital business transformation. It consists of three major programs: 1) Agile Business and IT 2) Customer Centricity (experience) 3) Open Digital Ecosystem Of these, the ZOOM (Zero-touch Orchestration, Operations, and Management) project, located in the Agile Business and IT project, is the main sub-project in this area that is of interest to SUPA. Within ZOOM, the Foundational Studies project contains work on an information model and management architecture that are directly relevant to SUPA. The Information Model, Policy, and Security working groups are involved in this work. The ZOOM information model updates the existing Shared Information and Data (SID) information model to add support for the management of physical and virtual infrastructure, event- and data-driven systems, policy management (architecture and Klyus, et al. Expires December 6, 2015 [Page 21] Internet-Draft SUPA - Proposition June 2015 model), metadata for describing and prescribing behavior that can support changes at runtime, and access control. The policy information model defines event-condition-action (ECA), declarative (intent-based), utility function, and promise policies. The work in draft-strassner-supa-generic- policy-info-model-01 is based on this work. It currently extends the ECA model and provides additional detail not currently present in ZOOM; the next version of this draft will do the same for declarative policies. There is currently no plan to use the utility function and promise policies. Finally, it should be noted that the data model work planned for SUPA is not currently planned for the ZOOM project. 5.2.2. MEF MEF The MEF (originally named the Metro Ethernet Forum) develops architecture, service and management specifications related to Carrier Ethernet (CE). The CE architecture includes the definition of several interfaces specific to CE like the User Network Interface (UNI) and External Network Network Interface (ENNI). Specifications developed in this space include the definitions of CE services, CE service attributes, Ethernet Access Services, Class of Service, OAM and Management interfaces, Service Activation and Test. The more recent vision of the MEF related to the future of networking is described as The Third Network and includes plans to develop Lifecycle Service Orchestration with APIs for existing network, NFV and SDN implementations enabling Agile, Assured and Orchestrated Services. This stage of the MEF activity is now in early phases with focus on architectural work. The MEF has developed a number of Information and Data Models, and has recently started a project that used YANG to model and manage the services covered by the MEF. Although the MEF has created quite rigorous definitions of these services, these are transport technology specific, and they do not include and rely on policies. Klyus, et al. Expires December 6, 2015 [Page 22] Internet-Draft SUPA - Proposition June 2015 5.2.3. Open Daylight Open Daylight network controller implements a number of models through its service abstraction Layer (MD-SAL) based on draft IETF Yang models. Few of the below mentioned Open Daylight projects provides policy abstraction and better flexibility to the user. 5.2.3.1. Network Intent Composition (NIC) Network Intent Composition project aims at providing better flexibility and high-level interface for the specification of policies. The intents-based interface would provide a high level of abstraction easy to formulate by an application developer and completely detached from the underlying implementation details. By making intents portable and composable, the project aims at making intents a more scalable approach than existing interfaces. 5.2.3.2. Group Policy The group-based policy project defines an application-centric policy model for Open Daylight that separates information about application connectivity requirements from information about the underlying details of the network infrastructure. 5.2.4. Open Networking Foundation The ONF created a group responsible of defining northbound interfaces, but this hasn't lead to the publication of standards in this area so far. A blog entry on the ONF web site showed an interest in using the principle of intents at ONF, but no details were provided on the status of this project. The membership of this group being closed in nature, the status of current draft proposals is not known. 5.2.5. OpenStack OpenStack software controls large pools of compute, storage, and networking resources throughout a datacenter, managed through a dashboard or via the OpenStack API. OpenStack works with popular enterprise and open source technologies making it ideal for heterogeneous infrastructure. Few of the below mentioned OpenStack projects provides policy abstraction and better flexibility to the user. Klyus, et al. Expires December 6, 2015 [Page 23] Internet-Draft SUPA - Proposition June 2015 5.2.5.1. Group-Based Policies The Group-Based Policies project for OpenStack Neutron is built around entities assembled in Endpoints Groups (EPG) that provide or consume Contracts. Such Contracts are hierarchical entities containing policy rules. A first version was released in January 2015, based on the Juno release. This type of approach is more relational than declarative, but could be used to describe a large amount of possible scenarios. It has the advantage of providing a relatively simple policy model that covers a large applicability. From an OpenStack point of view, the scope of GBP is limited to networking within the Neutron module. 5.2.5.2. Congress The Congress project within OpenStack provides a way to formulate complex policies using the Datalog language, a derivate of Prolog. Datalog is entirely declarative and first- order logic, which gives it interesting properties, such as providing the same result no matter the order in which the statements are made. The language allows for the definition of types and for active enforcement or verification of the policies. Using Datalog also allows Congress to take advantage of the significant body of knowledge and experience relating to declarative languages and their implementation. The Congress policies aim at manipulating objects exposed by multiple OpenStack modules and is therefore larger in scope than network policying only. The only drawback of this approach lies in its potentially large computational complexity, which could limit its ability to react in real time fast events such as those relating to the network. 5.2.6. The NEMO Project The NEMO project is a research activity aiming at defining a simple declarative framework for networking. The NEMO syntax is not based on an existing language and covers the basic elements for network manipulation such as nodes, links and flows. The NEMO project has been successfully demonstrated at IETF-91, along with a companion graphical user interface, and this work now being proposed as the base for a new group called Intent-Based NEMO (IBNEMO) within the IETF. Klyus, et al. Expires December 6, 2015 [Page 24] Internet-Draft SUPA - Proposition June 2015 5.2.7. The Floodlight Project The Floodlight is an openflow enabled SDN controller. it uses another open source project called Indigo to support openflow and manage southbound devices. Indigo agent also supports abstraction layer to make it easy to integrate with physical and virtual switches. It supports configuration of abstraction layer so that it can configure openflow in hybrid mode. 5.2.8. The ONOS Project The ONOS is a SDN controller. It supports abstraction for both southbound and northbound interfaces. This is because NFV used in ONOS can reduce CaPex because each service can be virtualized, but it increases OpEx as service providers now have to contend with increased management complexity due to the management and orchestration of a large numbers of VMs on commodity servers, the management of network function software on the VMs and how VMs must be interconnected based on subscriber's service contract. This is why, ONOS uses Network Function as a Service (NFaaS) that not only virtualized the components and Virtual Network Functions (VNFs) but also introduces an abstractive unit for a collection of VMs and their interconnecting network(s). Being able to create and manipulate these units, rather than handling individual components, significantly simplifies operation. NFaaS manipulates these units in the enhanced form of a service. 5.3. Technical Implementation Scenarios Large scale Distributed Data Centers (DDCs) can provide various services and usually consist of many internal and external links where various VPNs are built upon. The Service provisioning and network connectivity configurations could be complex and dynamic, for which manual configuration is not onerous and error-prone. The SUPA generic policy management models can be used to support the dynamic and automated resource usage and simplify and automate the service/network deployment/configuration of various VPN scenarios in the DDC environment. A more detailed description of this use case is provided in [ID.draft-cheng- supa-ddc-use-cases]. 6. Framework Summary ? Features and Benefits Klyus, et al. Expires December 6, 2015 [Page 25] Internet-Draft SUPA - Proposition June 2015 7. Security Considerations TBD 8. IANA Considerations This document has no actions for IANA. 9. Acknowledgments This document has benefited from reviews, suggestions, comments and proposed text provided by the following members, listed in alphabetical order: G. Karagiannis, J. Strassner, C. Zhou, Q. Sun, Luis M. Contreras, Telefonica, P. Yegani, D. Romascanu, J. Bi 10. References 10.1. Normative References [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. [RFC6991] J. Schoenwaelder, "Common YANG Data Types", July 2013 [RFC6241] R. Enns, M. Bjorklund, J. Schoenwaelder, A. Bierman, "Network Configuration Protocol (NETCONF)", June 2011 [RFC7285] R. Alimi, R. Penno, Y. Yang, S. Kiesel, S. Previdi, W. Roome, S. Shalunov, R. Woundy "Application-Layer Traffic Optimization (ALTO) Protocol", September 2014 10.2. Informative References [SUPA-framework] C. Zhou, L. M. Contreras, Q. Sun, and P. Yegani, " The Framework of Simplified Use of Policy Abstractions (SUPA) ", IETF Internet draft, draft-zhou-supa- framework, February 2015. [SUPA-problem-statement] G. Karagiannis, Q. Sun, Luis M. Contreras, P. Yegani, JF Tremblay and J. Bi, "Problem Statement for Simplified Use of Policy Abstractions (SUPA)", IETF Internet draft, draft-karagiannis-supa-problem-statement, January 2015. [SUPA-gap-analysis] J. Bi, H.Rafiee, V,Choudhary, J.Strassner, D.Romascanu "Simplified Use of Policy Abstractions (SUPA) Gap Analysis", IETF Internet draft, draft-bi-supa-gap-analysis, May 2015. Klyus, et al. Expires December 6, 2015 [Page 26] Internet-Draft SUPA - Proposition June 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 [RaBe11] Raphael Romeikat, Bernhard Bauer, "Formal Specification of DomainSpecific ECA Policy Models", in Proc. 2011 Fifth IEEE International Conference on Theoretical Aspects of Software Engineering, 2011 [Stras02] John Strassner, "DEN-ng: Achieving Business-Driven Network Management" in Proc. IEEE Network Operations and Management Symposium (NOMS), 2002. Authors' Addresses Maxim Klyus, Ed. NetCracker Kozhevnicheskaya str.,7 Bldg. Nr. 1 Moscow, Russia Phone: +7-916-8575717 E-mail: klyus@netcracker.com John Strassner, Ed. Huawei Technologies 2330 Central Expressway Santa Clara, CA 95138 USA Email: john.sc.strassner@huawei.com Georgios Karagiannis Huawei Technologies Hansaallee 205, 40549 Dusseldorf, Germany Email: Georgios.Karagiannis@huawei.com Klyus, et al. Expires December 6, 2015 [Page 27] Internet-Draft SUPA - Proposition June 2015 Qiong Sun China Telecom No.118 Xizhimennei street, Xicheng District Beijing 100035 P.R. China Email: sunqiong@ctbri.com.cn Luis M. Contreras Telefonica I+D Ronda de la Comunicacion, Sur-3 building, 3rd floor Madrid 28050 Spain Email: luismiguel.contrerasmurillo@telefonica.com URI:http://people.tid.es/LuisM.Contreras/ Parviz Yegani JUNIPER NETWORKS 1133 Innovation Way Sunnyvale, CA 94089 Email: pyegani@juniper.net Cathy Zhou Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Jun Bi Tsinghua University Network Research Center, Tsinghua University Beijing 100084 China EMail: junbi@tsinghua.edu.cn Hosnieh Rafiee Huawei Technologies Duesseldorf GmbH Munich, Germany Phone: +49 (0)162 204 74 58 E-mail: ietf@rozanak.com Vikram Choudhary Huawei Technologies E-mail: vikram.choudhary@huawei.com Dan Romascanu Avaya Atidim Technology Park, Bldg. #3 Tel Aviv 61581, Israel Phone: +972-3-6458414 E-mail: dromasca@avaya.com