Network Working Group N. Vadrevu Internet Draft VN Telecom Consultancy Intended status: Informational D. Zhang Expires: February 2016 Alibaba Group August 3, 2015 Applicability of SUPA draft-vadrevu-supa-applicability-02 Abstract SUPA will define a generic policy information model, an imperative (Event-Condition-Action, ECA) policy information model and a declarative (intent-based) policy information model which is the extension of the generic information model, and a set of policy data models which will make use of the common concepts defined in the information model. This memo will explore some typical use cases and demonstrate the applicability of SUPA policy models. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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. xxx Expires February 3, 2016 [Page 1] Internet-Draft SUPA Model Applicability August 2015 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on February 3, 2009. 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 2. Conventions ................................................. 3 3. Termilogy ................................................... 3 4. Framework ................................................... 4 5. SUPA Examples ............................................... 5 5.1. SES Use Case ........................................... 5 5.1.1. Scenario .......................................... 5 5.1.2. Generic Policy Information Models ................. 7 5.1.3. Programmatic approach - SUPA modeling ............. 7 5.2. VPC Use Case ........................................... 8 5.2.1. Generic ........................................... 8 5.2.2. Example1 .......................................... 9 5.2.3. Example2 ......................................... 11 5.3. DC Link Use Case ...................................... 12 5.4. Virtual SP Use Case ................................... 13 5.5. Instant VPN Use Case .................................. 15 Vadrevu et al. Expires February 3, 2016 [Page 2] Internet-Draft SUPA Model Applicability August 2015 6. Security Considerations .................................... 17 7. IANA Considerations ........................................ 17 8. Acknowledgments ............................................ 17 9. References ................................................. 17 9.1. Normative References .................................. 17 9.2. Informative References ................................ 17 Authors' Addresses ............................................ 18 1. Introduction One of the ways for network service automation is using network management and operation software applications. The applications should not directly communicate with each network element; a hierarchical and extensible framework should be considered to hide the protocol specific and/or vendor specific details, high level network and service abstraction, and standardized programming API will be necessary. SUPA will define policy information models and data models, for service management and operation applications. [I-D.strassner-supa- generic-policy-info-model] defines a common set of concepts for various data models which may use different languages, protocols, and repositories. Three information models are defined in [I-D.strassner-supa-generic- policy-info-model]: Generic Policy Information Model (GPIM), Eca Policy Rule Information Model (EPRIM), Logic Statement Information Model (LSIM). The ECA information model is intended for dynamic service automation; while the LSIM is intended for expressing high requirements without being involved in network details. Data models can be defined by developers / operators or by any third party, as long as they follow the common concepts defined in SUPA information model. [I-D.chen-supa-eca-data-model] defines a policy data model of Event-Condition-Action (ECA), which is an example. 2. Conventions 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 RFC-2119 [RFC2119]. 3. Termilogy DC Data Center Vadrevu et al. Expires February 3, 2016 [Page 3] Internet-Draft SUPA Model Applicability August 2015 SES Switched Ethernet services SP Service Provider SUPA Simplified Use of Policy Abstractions VM Virtual Machine VPC Virtual Private Cloud 4. Framework +-----------------------------------------------------------------+ | 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 | | | +--------------------+ | | +---------------------+ | +---+---+---+----------------+ +-----+---+---+--------------+ Vadrevu et al. Expires February 3, 2016 [Page 4] Internet-Draft SUPA Model Applicability August 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 Use of SUPA Models C: Communications D: Derived from R: References (i.e., the information model is used by the system to instantiate the data model). As shown in Figure 1, SUPA will define generic policy information models, which are independent of services and use cases. Policy data models can be derived from the generic information models. The data model will define high level, maybe network-wide policies. Policy data model will be used in conjunction with service data models to generate configurations for network elements. The service data model is use case specific and will be developed by operators or third parties, which is out the scope of SUPA. The service management applications will send SUPA data models to the service management system, where policy making and automated policy enforcement will be performed, and the data models will be mapped to configuration of network elements. Configuration of network elements is vendor specific, using various protocols, such Netconf, Restconf, etc. SUPA also make use of information collected from network elements. The information may include warning or fault event, load status, traffic statistics, etc, which can be used to adjust network configurations. This kind of automation is done through ECA data models. 5. SUPA Examples 5.1. SES Use Case 5.1.1. Scenario Vadrevu et al. Expires February 3, 2016 [Page 5] Internet-Draft SUPA Model Applicability August 2015 +-----------------------------------------------------------------+ | Service Management | | +----------------------------------+ | | | Generic Policy Information Model | | | +----+------------------------+----+ | | | | +---------------------------+ +-------------------------------+ | | | Generic Policy Data Model | | Service Management Data Model | | | +---------------------------+ +---------------+---------------+ | +-----------------------------------------------------------------+ | | +------------------------------+ | Network Manager / Controller | +------------------------------+ | | +------------------+ +-------------+ | Traffic Analysis | +--------+ | Headquarter |----------| |-------| Site 1 | +-------------+ | WAN Optimization | +--------+ +------------------+ | | +----------+ | Site 2 | +----------+ Figure 2 Switched Ethernet Service Switched Ethernet services (SES) to Small and Medium Businesses business is a growing business segment of the service provider. As the Enterprise's applications grow in demands in terms of the bandwidth and richness of applications, WAN optimization is needed to improve the service quality. SUPA policy data models can be used for maximizing the WAN performance by analyzing the traffic and performing application management and acceleration tools for the network. In the use case below, Service Manager (SM) is used for service and policy definition and Network Manager (Controller) is used for network topology maintenance and mapping data models to detail network configurations. Vadrevu et al. Expires February 3, 2016 [Page 6] Internet-Draft SUPA Model Applicability August 2015 While speed and bandwidth are at the forefront of the WAN Optimization there need to be tools in place to detect, diagnose, remedy and report application performance to ensure the SLAs for a customer are enforced. The service is modeled in terms of what kind of service (Ethernet, VLAN), bandwidth (10Mbps- 10 Gbps), service package (platinum, gold, silver) etc. Policy models are based on an Event condition action like: 1. Bandwidth usage alarm triggers data caching 2. Latency alarm triggers reduction of re transmission 3. WAN outage at a specific site can trigger geographic redundancy (provided the service is setup for GR) The above are 3 of the primitives (Event condition action - ECA) on which the run time operations could be based on. When the service model is comprehensively designed with more possibilities (variables), more policy models could be implemented 5.1.2. Generic Policy Information Models Requirements and configurations derived from above application scenarios can be described by service data model and policy data models as below: Service data model can be used to describe attributes for the SES, including service package type (Platinum, gold etc), bandwidth bought by the subscriber (100Mbps, 10Gbps), connection name -copper/ GigE, latency, etc. Policy data model describes a condition when the link capacity reaches 90%, Service prioritization and WAN optimization need to be enforced based on the customers service package. Event is the link utilization and condition is the usage and action is the WAN optimization. The actions could trigger multiple actions like data compression, protocol acceleration (like streaming gets priority) which are beyond the scope of SUPA 5.1.3. Programmatic approach - SUPA modeling The advantage of the programmatic approach can be maximized by defining as many SUPA ECA models as possible in a top down approach Vadrevu et al. Expires February 3, 2016 [Page 7] Internet-Draft SUPA Model Applicability August 2015 In this use case, since this is a switched service, point to point traffic can be identified (by IP Address and port number) and segmented and whole bandwidth can be utilized by many applications simultaneously. Examples are: Print jobs, backups etc.. The benefit of the SUPA is in creating many policies upfront. As the operations grow in complexity SUPA can expand an existing policy by adding more variables. This is how reusable policies can be developed upfront and configuration and maintenance operations can be dealt by modeling and programmatic approach. Logic Statement Information Model (LSIM) can also be called as declarative or intent model. This type of model will describe the service intention without specifying low level details, such protocol level or network device level detail, but just the service requirements itself. 5.2. VPC Use Case 5.2.1. Generic In practice, a public cloud operator can virtualize the cloud resources into multiple isolated virtualized private clouds and provide them to tenants. Such a virtualized private cloud is referred to as a VPC. In a typical VPC provided by, e.g., Alibaba or Amazon, through a control portal, a tenant can establish and manage the network easily, for instance, deploying or removing virtualized network devices (e.g., virtualized routers and virtualized switches), adjusting the topology of VPC networks, specifying packet forwarding policies, and deploying or removing virtual services (e.g., load balancers, firewalls, databases, DNS, etc.). The network functionalities that the tenant can access are virtualized and actually performed by the VMs located on the servers connected through physical or overlay networks. Note that the servers may be located in different data centers which are geographically distributed. The manipulation of the virtualized VPC network may also affect the configuration of physical networks. For instance, when a tenant newly deploys two VMs in the VPC which are located in different DCs, the VPC control mechanism may have to generate a VPN between two DCs Vadrevu et al. Expires February 3, 2016 [Page 8] Internet-Draft SUPA Model Applicability August 2015 for the internal VPC communication. Therefore, the control mechanism for a VPC should be able to adjust the underlying network when a tenant changes the network or service deployment of the virtual VPC network. In many cases, a tenant may need to specify how the VPCs are connected to its enterprise cloud networks. For instance, a tenant may want to deploy multiple VPNs to connect the VPC with its private cloud networks and specify the policies to steer the traffics through different VPNs in different conditions. Note that the VPCs that the tenant may be located in different geographic regions and the VPNs to those VPCs may need to be generated at run time. In addition, a VPC, often provides other value added services (e.g., database Services, DNS) for VMs in certain VPCs. The VMs and the value added services could be located in different DCs, or even provided by different vendors. VPNs are configured for the VPCs to provide connection to the internal services in tenant's own DC or organization, and to create and manage VPNs to internal services. The access of VMs to data resources should be controlled. For instance, the VMs in a VPC can access the database services only when the tenant has deployed database into its VPC through the control portal. 5.2.2. Example1 Vadrevu et al. Expires February 3, 2016 [Page 9] Internet-Draft SUPA Model Applicability August 2015 +--------------------+ | DC2 | | +----------------+ | | |Tenant x (vDC) | | | +----------------+ | | | | +----------------+ | | | Tenant 1 (vDC) | | | +----------------+ | +----------|---------+ | | +-------------+ | Cloud | /| |\ / +-------------+ \ / \ / \ +-----------------/--+ +----\---------------+ | DC1 / | | DC3 \ | | +----------------+ | | +----------------+ | | | Tenant 1 (vDC) | | | | Tenant 1 (vDC) | | | +----------------+ | | +----------------+ | | | | | | +----------------+ | | +----------------+ | | | Tenant n (VDC) | | | | Tenant k (vDC) | | | +----------------+ | | +----------------+ | +--------------------+ +--------------------+ Figure 3 Resource Inter-connection for a VPC Tenant When cloud / DC operator signs a contract with customer, resource information such as network bandwidth, storage size, number of CPU, memory size, etc, will be specified. But in deployment, the resources may be located in multiple distributed data centers, and tunnels will be created to inter- connect these resources, which will make it look like one seamless entity - a virtual DC. There could be quite a number of tunnels, and the tunnels are dynamic, either for the reason of load balancing purpose or VM migration, or other reasons. This will make it difficult to configure the service statically or manually, service automation is very necessary. Vadrevu et al. Expires February 3, 2016 [Page 10] Internet-Draft SUPA Model Applicability August 2015 The service management system will have a repository of available resources, including the topology. And also the management system will have the customer specific information (location, SLA, agreed resources, etc). The administrator can send the service requirement to the management system by a high level data model, which can further be mapped to low level detail data models, then finally mapped to configurations of network devices. Target: Provide VPC service to customer A with specified resources and function (storage, computing, DNS, etc) Declarative policy: 1. Allocate the required services on DCs according to a user's profile 2. Services located in multiple distributed DCs must be interconnected via VPNs 3. The VPNs associated to the services provided for a user must match the user's profile in terms of latency, speed and bandwidth 5.2.3. Example2 +----------+ Tenant move to +----------+ | Tenant A | ------------------> | Tenant A | +----------+ another location +----------+ | | | | | | +--------V-------+ _+--------V-------+ | +----------+ | | +----------+ | | | VM for | | VM Migration | | VM for | | | | Tenant A | | -----------------> | | Tenant A | | | +----------+ | if network load | +----------+ | | DC-Location1 | between DCs is low | DC-Location2 | +----------------+ +----------------+ Figure 4 VM Migration if Tenant Move As shown in the above figure, when a VPC tenant move from one location to another, where it is near to another DC, and the network Vadrevu et al. Expires February 3, 2016 [Page 11] Internet-Draft SUPA Model Applicability August 2015 load between the new DC and the previous DC is low, the tenant's VM should be migrated to the new DC in order for better user experience. After the VM is moved to the new DC, the network related to the VM must be updated accordingly. Target: Perform VM migration when user location changed and the network load between the DCs is low ECA Policy: Event: a VPC user's location is changed (near to another DC) Condition: network_load(DC_old, DC_new) < threshold Action: 1. Migrate the VM to the new data center (DC_new) 2. Update the VPNs connecting the user's services 5.3. DC Link Use Case DCs usually have multiple external links, either to other DCs or to the internet. Because of the dynamic nature of network traffic, the load on a link may vary at different times of a day, e.g. link mainly carries enterprise traffic may have a high load in the working hours but less traffic in the night. Some events may also impact the load of links, such as one link is physically damaged and the load in it will go to another link. In order to make full use of the bandwidth of the links, dynamic traffic steering is necessary for SLA meanwhile with full use of network resource. Vadrevu et al. Expires February 3, 2016 [Page 12] Internet-Draft SUPA Model Applicability August 2015 ---------------------------- / \ +--------+ +--------+ | | | | | DC 1 |--------------------| DC 2 | | | | | +--------+ +--------+ \ / \ / \ / \ / \ +--------+ / \| | / | DC 3 | | | +--------+ Figure 5 Multiple Disjoint Links Between DCs Target: DC have multiple external links; when the load on a link is too high, perform traffic steering for better bandwidth resource usage ECA Policy Event: load on a DC link exceeds threshold Condition: multiple disjoint links between DCs Action: steer some traffic to link with low load 5.4. Virtual SP Use Case Virtual network operators usually do not have a complete network, including access network, metro network, and backbone network. They need to rent network from other operators. An example is, a virtual operator do not have the access network, traffic of broadband network subscriber will go through other operators access network, and then be directed to the virtual operators network from the BNG via tunnels. In some other cases, the virtual operators may not have the backbone network, the network islands and DCs will be connected by tunnels. The problem in this case is, virtual network operators have no control over the tunnels and they cannot decide the exact path that the tunnel should go through. In some scenarios, if the tunnel goes through the border of two network operators, or the tunnel goes through an area where network load is too high, the SLA will be a problem. Virtual network operators who run the business in a large geographical region often run into this problem. Due to cost issue, Vadrevu et al. Expires February 3, 2016 [Page 13] Internet-Draft SUPA Model Applicability August 2015 virtual network operators cannot buy service from other operators with critical SLA. A possible solution is, the virtual network operator rent or put some routers in network operators' DCs, and then configure tunnels between the routers and perform traffic steering. In this way, virtual network operators can have control over the tunnels, pin down the path. When a problem is detected, such as QoS of a tunnel is below a threshold, virtual network operator can perform "network wide" optimization, reconfigure the tunnels and/or perform traffic steering. +------------+ +------------+ | vNetwork 1 | | vNetwork 2 | +------------+ +------------+ \ \ \ +--------------+ +--------------+ | +----------+ | tunnel 1 | +----------+ | | | Router 1 | |--------------| | Router 2 | | | +----------+ | | +----------+ | | Operator DC1 | | Operator DC2 | +--------------+ +--------------+ | \ | \ | \ +--------------+ \ | +----------+ | tunnel 2 +------------+ | | Router 2 | |---------------------| vNetwork 3 | | +----------+ | +------------+ | Operator DC3 | +--------------+ Figure 6 Segment Tunnels for Virtual Network Operator If direct tunnel is built between virtual operator's networks (e.g. vNetwork1-to-vNetwork3), route is out of control -- the route may go through network node with problems, or with high load, or cross border of different operators where QoS cannot be guaranteed. In this case, the virtual network operator can configure three tunnels rather than one to connect vNetwork1 to vNetwork3: vNetwork1-to-Router1, Router1-to-Router2, Router2-to-vNetwork3. Vadrevu et al. Expires February 3, 2016 [Page 14] Internet-Draft SUPA Model Applicability August 2015 After the initial network configuration is finished, if any problem is detected in any tunnel, the network management system can perform network wide optimization, taking all the routers into account and working out another set of tunnels if necessary. ECA Policy: Event: QoS parameters < threshold Condition: multiple disjoint tunnels available Action: Network wide tunnel optimization + traffic steering 5.5. Instant VPN Use Case +------------------------+ | SUPA Information Model | +------------------------+ | | +-------------------------------+ | +---------------------------+ | | | SUPA Data Model | | | +---------------------------+ | | +---------------------------+ | | | SUPA Translation Function | | | +---------------------------+ | +-------------------------------+ / /VPN Req Forwarded to Management System / +------+ VPN +------+ +------+ +------+ | CE |-------| PE |------| PE |------| PE | +------+ Req +------+ +------+ +------+ | | | | | | +------+ +------+ +------+ | PE |------| PE |------| PE | +------+ +------+ +------+ Figure 7 Instant VPN Vadrevu et al. Expires February 3, 2016 [Page 15] Internet-Draft SUPA Model Applicability August 2015 Traditionally, when an operator needs to deploy VPN service for an enterprise customer, they will send a service staff to the customer site and make the wire connection between the CE and PE; the service staff will also collect the configuration information, e.g. port/frame/slot of PE, PE ID, etc, and then send the information back to the management system, and the management system will configure the network according to this information together with the customer' information (such as bandwidth, SLA, etc). The problem of this approach is that the service staff needs to collect the connection information and feedback to the management system, and MUST make sure the information matches the actual connection. This operation is error prone. New approach should not count on the physical / geographical information feedback by the service staff, minimize the operation procedures. The CE should send authentication (with credentials) request to the PE, and PE should forward the request to the management system together with port/frame/slot on which the request is received, the PE ID etc. Target: Configure VPN for an enterprise customer to connect its enterprise network with VPC ECA Policy: Event: service management system receive a CE request for VPN creation (forwarded by PE) Condition: Authentication OK Action: Configure VPN based on received request, including user grade and physical info (port/slot/frame/route id, etc, from which the request is received) In the above cases, the advantage of SUPA ECA model is, it can work for different scenarios with a common set of concept: events, conditions, actions, etc. Vadrevu et al. Expires February 3, 2016 [Page 16] Internet-Draft SUPA Model Applicability August 2015 6. Security Considerations Since SUPA models can be used to generate configurations for network elements, the management applications which send models to service management system must go through authentication and authorization. 7. IANA Considerations This memo does not have any requirement to IANA. 8. Acknowledgments This document has benefited from reviews, suggestions, comments and proposed text provided by the following members, listed in alphabetical order: Juergen Schoenwaelder, John Strassner, James Huang This document was prepared using 2-Word-v2.0.template.dot. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [I-D.klyus-supa-proposition] Klyus, M., Strassner, J., "SUPA Value Proposition", draft-klyus-supa-proposition-02 (work in progress), July 4, 2015 [I-D.strassner-supa-generic-policy-info-model] Strassner, J., "Generic Policy Information Model for Simplified Use of Policy Abstractions (SUPA)", draft-strassner-supa- generic-policy-info-model-02, July 4, 2015 [I-D.chen-supa-eca-data-model] Chen, M., Contreras L., Fukushima, M., "ECA Policy YANG Data Model", draft-chen-supa-eca-data- model-00 (work in progress), July 2, 2015 Vadrevu et al. Expires February 3, 2016 [Page 17] Internet-Draft SUPA Model Applicability August 2015 [I-D.ww-sfc-control-plane] Li, H., Wu, Q., et al, "Service Function Chaining (SFC) Control Plane Components & Requirements", draft-ww-sfc-control-plane-06 (work in progress), June 8, 2015 Authors' Addresses Narasimha Vadrevu VN Telecom Consultancy Cupertino, California Email: vadrevun@von20.com Dacheng Zhang Alibaba Group
Email: Dacheng.zdc@alibaba-inc.com Vadrevu et al. Expires February 3, 2016 [Page 18]