Network Working Group                                           C. Zhou
Internet-Draft                                      Huawei Technologies
                                                        L. M. Contreras
Intended status: Informational                               Telefonica
Expires: November 08, 2015                                       Q. Sun
                                                          China Telecom
                                                              P. Yegani
                                                       Juniper Networks
                                                           May 08, 2015

    The Framework of Simplified Use of Policy Abstractions (SUPA)


   Currently, there are network services that impose specific demands
   on a communication network. This document describes the SUPA basic
   architecture, its elements and interfaces.  The main SUPA
   architecture entities are the Service Management (SM) and the
   Network Manager/Controller (NM/NC). The SM is a functional entity
   that creates and runs network services by using a set of NM/NCs. The
   NM/NC is a functional entity that provides one or more of the
   following functions: (1) the generation, maintenance and release of
   network topologies, (2) the generation, maintenance, and release of
   network service-specific abstractions, (3) the mapping between
   network service-specific abstractions and the network topology, and
   (4) the mapping between network service-specific abstractions and
   network device configuration. Both the SM and the NM/NC may be made
   up of multiple distinct entities that collectively perform their

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at Internet-
   Drafts are draft documents valid for a maximum of six months and may
   be updated, replaced, or obsoleted by other documents at any time.
   It is inappropriate to use Internet-Drafts as reference material or
   to cite them other than as "work in progress." This Internet-Draft
   will expire on April 27, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.
   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.

Zhou, et al          Expires August 08, 2015               Page 1

Internet-Draft          SUPA Architecture            January 2015

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( 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.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

Table of Content
1. INTRODUCTION .................................................... 2
2. TERMINOLOGY ..................................................... 3
3. SUPA FRAMEWORK .................................................. 4
4. FRAMEWORK FUNCTIONAL ENTITIES ................................... 6
 4.1. SERVICE MANAGEMENT ........................................... 6
 4.2. NETWORK MANAGER/CONTROLLER ................................... 6
 4.3. NETWORK ELEMENTS ............................................. 7
5. SECURITY CONSIDERATIONS ......................................... 8
6. IANA CONSIDERATIONS ............................................. 8
7. ACKNOWLEDGEMENTS ................................................ 8
8. NORMATIVE REFERENCES ............................................ 8
9. INFORMATIVE REFERENCES .......................................... 8
AUTHORS' ADDRESSES ................................................. 9

1. Introduction

   As the Internet grows, new services are created, new devices are
   connected, and new users use the Internet. These and other factors
   contribute to the significant increase in the amount and type of
   network traffic. This in turn makes network management and
   configuration more and more complicated.

   However, the need for dynamic and real-time configuration changes is
   required. One example is Inter-Data Center (DC) traffic steering and
   tunneling, based on real-time network status. Dedicated network
   management applications are required to automate the complicated and

Zhou, et al          Expires November 08, 2015               Page 2

Internet-Draft          SUPA Architecture            January 2015

   dynamic network configuration present in today's systems. Such
   applications need interoperable data models of network topology,
   network services, and policy rules to support the design, deployment,
   and maintenance of network services. Providing these data models to
   network management applications may provide significant improvements
   in configuration agility, error detection, and uptime for operators.

   However, in order to scale and to ensure configuration change
   consistency, existing network configuration schemes must be
   simplified through the use of abstraction. This increases the
   programmatic control over such systems. Simplified models are able
   to provide a wide range of granularity for various applications and
   network services needs, from the lower-level physical network to
   high-level application services.

   An abstract view of a network infrastructure can be realized using
   one or more network topology data models. Each such topology model,
   whether physical or logical, may be used as its own reusable managed
   object. This enables existing topologies to be reused to create new
   topologies. This applies to models of different layers, including
   the application layer (L7), IP/network layer (L3), and lower layers
   (L0-L2, such as MPLS, SDH, OTN, WDM). The network resources may
   include physical and/or virtual network nodes and links.

   A network service data model is service specific, and usually relies
   on a network topology data model. The network service data model
   defines the behavior of the network service, which is characterized
   by one or more metrics that include performance, dependability, and
   security specifications.

   One method to automate service configuration is to use a policy data
   model. Policy, in conjunction with network service and device data
   models, can be used to tell the Network Manager/Controller (NM/NC)
   how to generate Network Element (NE) configurations using network
   service data models in combination with topology data models. For
   example, this process can be used to choose a path for VPN which
   will involve a set of NE's.

   The main goal of this document is to specify the SUPA reference
   architecture, its elements, and its interfaces.

   YANG data models (e.g., see [RFC6020], [RFC6991]) can be used for
   representing service and topology models.

2. Terminology

   The terminology used in the SUPA problem statement draft
   [ID.karagiannis-supa-problem-statement] also applies to this draft.

   NE                     Network Element
   NC                     Network Controller
   NM                     Network Manager

Zhou, et al          Expires November 08, 2015               Page 3

Internet-Draft          SUPA Architecture            January 2015

   NM/NC  Network Manager/Controller
   SM                     Service Management

3. SUPA Framework

           |   Service Management   |
           | +--------------------+ |
           | | Policy Data Model  | |
           | +--------------------+ |
           | +--------------------+ |
           | | Service Management | |
           | | Data Model         | |
           | +--------------------+ |
                       |    NETCONF/RESTCONF
               |                             |
               |                             |
+----------------------------+   +----------------------------+
| Network Manager/Controller |   | Network Manager/Controller |
| +------------------------+ |   | +------------------------+ |
| |    Network Resource    | |   | |    Network Resource    | |
| |       Data Model       | |   | |       Data Model       | |
| +------------------------+ |   | +------------------------+ |
+----------------------------+   +----------------------------+
         |   |   |                         |   |   |
         |   |   |                         |   |   |
         |   |   |                         |   |   |
        NE1 NE2 NEn                       NE1 NE2 NEn

                   Figure 1 SUPA Framework

   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.
        Policy Data Model
        Model of policy rules for managing the network service and
        mapping services dynamically to the network topology and
        network resources. Policy data models are used to describe
        high level service requirements, such as routing requirements.

        Example of policy data model can be found in [ID.draft-
        strassner-supa-generic-policy-info-model] and [ID.draft-bi-

        There can be various types of policies, including service
        specific policies and network-wide policies. There can be a

Zhou, et al          Expires November 08, 2015               Page 4

Internet-Draft          SUPA Architecture            January 2015

        centralized entity managing the network-wide policies, which
        may be called as policy manager. The policy manager can be
        located in the SM or in a separate location.

        Policy data models now considered by SUPA are generic policy
        data model, ECA (event, condition, action) as described in
        SUPA charter. The work may be extended in the future.

        Service Management Data Model
        Model of the network service (e.g., VPNs) and the network
        resources required by the network service to be correctly
        deployed and executed on the physical and/or virtual topology.

        Example of service management data model can be found in

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

        Example of network resource data model can be found in

        SUPA will not define network resource data model, 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 Network Manager/Controller
   (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
   resource data model. NM/NC may also communication with traditional
   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.

Zhou, et al          Expires November 08, 2015               Page 5

Internet-Draft          SUPA Architecture            January 2015

   Service Management (SM) will send policy data model and service
   management data model, which will in conjunction with network
   resource data model be mapped to detail NEs' configurations by
   network manager / controller.

4. Framework Functional Entities

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

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

   The NM/NC contains a set of data models, functions and APIs,

Zhou, et al          Expires November 08, 2015               Page 6

Internet-Draft          SUPA Architecture            January 2015

   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-

   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-

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

   SUPA will specify mechanisms, in order to enable the NEs to interact
   with either local or remote network management systems. The

Zhou, et al          Expires November 08, 2015               Page 7

Internet-Draft          SUPA Architecture            January 2015

   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.

5. Security Considerations

   Security is a key aspect of any protocol that allows state
   installation and extracting of detailed configuration states. More
   investigation remains to fully define the security requirements,
   such as authorization and authentication levels.

6. IANA Considerations

   No IANA considerations.

7. Acknowledgements

   The authors of this draft would like to thank the following persons
   for the provided valuable feedback: Diego Lopez, Jose Saldana,
   Spencer Dawkins, Jun Bi, Xing Li, Chongfeng Xie, Benoit Claise, Ian
   Farrer, Marc Blancet, Zhen Cao, Hosnieh Rafiee, Mehmet Ersue,
   Mohamed Boucadair, Jean Francois Tremblay, Tom Taylor, Tina Tsou,
   Georgios Karagiannis, John Strassner, Raghav Rao, Jing Huang.

   Early version of this draft can be found here:
   At the early stage of SUPA, we think quite some issues are left open,
   it is not so suitable to call this draft as "architecture". We would
   like to rename it to "framework". Later there may be a dedicated
   architecture document.

8. Normative References

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

9. Informative References

   [I2RS] Interface to the Routing System (i2rs) charter,

Zhou, et al          Expires November 08, 2015               Page 8

Internet-Draft          SUPA Architecture            January 2015

   [ID.draft-ietf-netconf-restconf] A. Bierman, M. Bjorklund, K. Watsen,
   R. Fernando, "RESTCONF Protocol", IETF Internet draft (work in
   progress), draft-ietf-netconf-restconf-04, January 2015

   [ID.karagiannis-supa-problem-statement] G. Karagiannis, Q. Sun, L. M.
   Contreras, P. Yegani, JF Tremblay, " Problem Statement for
   Simplified Use of Policy Abstractions (SUPA)" IETF Internet Draft
   (work in progress)", draft-karagiannis-supa-problem-statement-06,
   March 2015.

   [ID.draft-cheng-supa-ddc-use-cases] Y. Cheng, JF. Tremblay, J. Bi
   , L. M. Contreras, "Use Case for Distributed Data Center in SUPA",
   IETF Internet draft (Work in progress), draft-cheng-supa-ddc-use-
   cases-06, April 2015

   [ID. draft-zaalouk-supa-vpn-service-management-model] D. Zhang, A.
   Zaalouk, K. Pentikousis, Y. Cheng, "VPN Service Management YANG Data
   Model", IETF Internet draft (Work in progress), draft-zaalouk-supa-
   vpn-service-management-model-03, April 2015

   [ID.draft-strassner-supa-generic-policy-info-model] J. Strassner,
   "Generic Policy Model for Simplified Use of Policy Abstractions
   (SUPA)", IETF Internet draft (Work in progress), April, 2015

   [ID.draft-bi-supa-policy-model] J. Bi, R. Tadepalli, M. Hayashi,
   "DDC Service Policy YANG Data Model", IETF Internet draft (Work in
   progress), March, 2015

   [ID.draft-pentikousis-supa-mapping] K. Pentikousis, D. Zhang,
   "Simplified Use of Policy Abstractions (SUPA): Configuration and
   Policy Mapping", IETF Internet draft (Work in progress), draft-
   pentikousis-supa-mapping-04, March 2015

   [NETCONF] Network Configuration (netconf) charter,

   [RFC6020] M. Bjorklund, "YANG - A Data Modeling Language for the
   Network Configuration Protocol (NETCONF)", RFC 6020, October 2010.

   [RFC6991]  J. Schoenwaelder, "Common YANG Data Types", RFC 6991,
   July 2013.

   [RFC6241] R. Enns, M. Bjorklund, J. Schoenwaelder, A. Bierman,
   "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011.

   Authors' Addresses

   Cathy Zhou
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen 518129
   P.R. China

Zhou, et al          Expires November 08, 2015               Page 9

Internet-Draft          SUPA Architecture            January 2015


   Luis M. Contreras
   Telefonica I+D
   Ronda de la Comunicacion, Sur-3 building, 3rd floor
   Madrid  28050

   Qiong Sun
   China Telecom
   No.118 Xizhimennei street, Xicheng District
   Beijing 100035
   P.R. China


   Parviz Yegani
   1133 Innovation Way
   Sunnyvale, CA 94089

Zhou, et al          Expires November 08, 2015              Page 10