Skip to main content

Applicability of SUPA
draft-vadrevu-supa-applicability-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Narasimha Rao Vadrevu , Dacheng Zhang
Last updated 2015-07-22
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-vadrevu-supa-applicability-00
Network Working Group                                      N. Vadrevu
Internet Draft                                  VN Telecom Consultancy
Intended status: Informational                                 D. Zhang
Expires: January 2016                                     Alibaba Group
                                                         July 23, 2015

                           Applicability of SUPA
                    draft-vadrevu-supa-applicability-00

Abstract

   SUAP 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.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents

xxx                   Expires January 23, 2016                [Page 1]
Internet-Draft        SUPA Model Applicability               July 2015

   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 January 23, 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. Framework ................................................... 3
   4. SUPA Model Applicability .................................... 5
      4.1. ECA Data Model ......................................... 5
         4.1.1. SES Use Case ...................................... 5
            4.1.1.1. Scenario ..................................... 5
            4.1.1.2. Generic Policy Information Models ............ 7
            4.1.1.3. Programmatic approach - SUPA modeling......... 8
         4.1.2. DDC Use Case ...................................... 8
         4.1.3. Instant VPN ....................................... 8
      4.2. Declarative Data Model.................................. 9
   5. Security Considerations .................................... 11
   6. IANA Considerations ........................................ 11
   7. Acknowledgments ............................................ 11
   8. References ................................................. 11
      8.1. Normative References .................................. 11
      8.2. Informative References ................................ 11

xxx                   Expires January 23, 2016                [Page 2]
Internet-Draft        SUPA Model Applicability               July 2015

   Authors' Addresses ............................................ 12

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. Framework

xxx                   Expires January 23, 2016                [Page 3]
Internet-Draft        SUPA Model Applicability               July 2015

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

xxx                   Expires January 23, 2016                [Page 4]
Internet-Draft        SUPA Model Applicability               July 2015

   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.

4. SUPA Model Applicability
4.1. ECA Data Model

4.1.1. SES Use Case

4.1.1.1. Scenario

xxx                   Expires January 23, 2016                [Page 5]
Internet-Draft        SUPA Model Applicability               July 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

xxx                   Expires January 23, 2016                [Page 6]
Internet-Draft        SUPA Model Applicability               July 2015

   network topology maintenance and mapping data models to detail
   network configurations.

   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

4.1.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

xxx                   Expires January 23, 2016                [Page 7]
Internet-Draft        SUPA Model Applicability               July 2015

4.1.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

   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.

4.1.2. DDC Use Case

    A data center can provide various services, such as video host, VMs,
    etc. In order to provide better user experience, the contents may be
    located in multiple geographically distributed data centers so that
    the user can get service from a nearby location. The content
    distribution between data centers is necessary, an example is, for a
    social video service provider, they need to copy videos uploaded by
    users to all the data centers. Another example is, cloud operator
    may needs to migrate VMs from one location to another. This kind of
    operation usually will require a lot of bandwidth. To avoid
    consuming too much network resource in the busy hours, it is usually
    done in the non-busy hours, such as 1 or 2 o'clock in the morning.

    Example:

     Event: time of the day

     Condition: now is Evening

     Action:

         Configure a VPN for VM migration for 2 hours

4.1.3. Instant VPN

       Provide VPN connection for Customer A when receiving a request.

xxx                   Expires January 23, 2016                [Page 8]
Internet-Draft        SUPA Model Applicability               July 2015

       (Figure to be added)

       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.

     Example:

          Event: receive customer VPN service request

          Condition: YES (received valid request)

          Action:

             Configure VPN service for the customer

     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.

4.2. Declarative Data Model
    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

xxx                   Expires January 23, 2016                [Page 9]
Internet-Draft        SUPA Model Applicability               July 2015

    protocol level or network device level detail, but just the service
    requirements itself.

    Example1:

       All SNMP agents in my network should drop all SNMP traffic unless
       it is originating or targeted to the management network

       The management system will expand this requirement according to
       the network topology which is provided by other systems, and get
       a list of all the involved network elements which should be
       configured.

       The SNMP traffic can be identified by the TCP/UDP port 161/162;
       and if the traffic is originating or targeted to management can
       be identified by the source or destination address or the traffic,
       but, which is out of scope of SUPA.

       With the above information, the management system can generate
       and install configurations to all the related network elements.
       The administrator does not have to specify any protocol level or
       network device level details during network management.

   Example: Virtual DC

       Request: Create a virtual DC for customer B with specified
       resource (BW, storage, compute)

       (Figure to be added)

       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.

       The service management system will have a repository of available
       resources, including the topology. And also the management system

xxx                   Expires January 23, 2016               [Page 10]
Internet-Draft        SUPA Model Applicability               July 2015

       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.

5. 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.

6. IANA Considerations

   This memo does not have any requirement to IANA.

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

8. References

8.1. Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

8.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

xxx                   Expires January 23, 2016               [Page 11]
Internet-Draft        SUPA Model Applicability               July 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

   [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
   <Address>

   Email: Dacheng.zdc@alibaba-inc.com

xxx                   Expires January 23, 2016               [Page 12]