SUPA Configuration and Policy Mapping
draft-pentikousis-supa-mapping-00

Internet Working Group                               K. Pentikousis, Ed.
Internet Draft                                                     EICT
Intended status: Informational                                Junru Lin
Expires: March 27, 2015                                      Yiyong Zha
                                                    Huawei Technologies
                                                     September 23, 2014

              SUPA Configuration and Policy Mapping
                draft-pentikousis-supa-mapping-00

Abstract

   Nowadays, the underlying network infrastructure grows in scale and
   complexity, which make it challenging for network operators to manage
   and configure the network. Deploying policy or configuration based
   on an abstract view of the underlying network is much better than
   manipulating each individual network element, however, in this case,
   the policy and configuration cannot be recognized by the network
   devices. This document describes guidelines for mapping configuration
   and policy into device-level configuration. The SUPA framework
   overview and primary procedures of mapping are proposed. Moreover, an
   exemplary mapping scenario is provided to illustrate the mechanism
   involved.

Status of this Memo

   This Internet-Draft is submitted to IETF 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 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 March 27, 2014.

Pentikousis, et al.     Expires March 27, 2015                 [Page 1]
Internet-Draft  SUPA Configuration and Policy Mapping  September 2014

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
   (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 ............................................. 2
   2.   Terminology .............................................. 3
   3.   Configuration and Policy Mapping.......................... 3
      3.1. Overview .............................................. 4
      3.2. Mapping Procedure...................................... 5
      3.3. SUPA Mapping Example................................... 6
   4.   Security Considerations.................................. 10
   5.   IANA Considerations...................................... 10
   6.   References .............................................. 10
      6.1. Normative References.................................. 10
      6.2. Informative References................................ 11
   7.   Acknowledgements ........................................ 11

1. Introduction

   As the underlying network infrastructure grows, and new services and
   traffic are rapidly increased, it becomes significantly more
   challenging than in the past to maintain the network and deploy new
   services. Configuration automation can provide significant benefits
   in deployment agility. Shared Unified Policy Automation (SUPA)
   [draft-zhou-supa-architecture-00] attempts to achieve this
   configuration automation by introducing multi-level abstractions. In
   SUPA, the definition of a standardized model for a network topology
   graph, which could be used to describe topologies at any functional
   layer, and information model of various application services and
   functions allow the network operators to manipulate the network
   infrastructure as a whole rather than individual devices. Well-
   designed abstractions are able to provide a wide range of granularity

Pentikousis, et al.     Expires March 27, 2015                 [Page 2]
Internet-Draft  SUPA Configuration and Policy Mapping  September 2014

   for various applications needs, from the lower-level physical network
   to high-level application services. However, these information models
   cannot be directly utilized by network elements, thus a mapping
   mechanism is necessary to bridge the gap between these information
   models and network element-recognized configuration.

   SUPA employs the Application-Based Policy Decision (ABPD) block, an
   entity used between the network services and the network elements to
   provide and maintain the application-based policies. ABPD supports
   the SUPA interface/protocol and is a software repository, which
   stores the information associated with each network element. The
   mapping mechanism could be part of ABPD to help ABPD to map the
   classified application based models, which include the classified
   application based policies, into specific network management
   policies, i.e., device-level configuration models, which are used
   by the communication network.

2. Terminology

   This document uses the following terms:

   Network element: a physical or virtual entity that can be locally
   managed and operated.

   Network service system (NSS): enhanced Operational Support System
   (OSS) which runs services that enable a provider to monitor, control,
   analyze and manage the services in a communication network.

   SUPA: Shared Unified Policy Automation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3. Configuration and Policy Mapping

   This section introduces a framework for mapping configuration and
   policy in the context of a network with several network elements and
   one or more network service systems.

Pentikousis, et al.     Expires March 27, 2015                 [Page 3]
Internet-Draft  SUPA Configuration and Policy Mapping  September 2014

3.1. Overview

   The SUPA framework for mapping network-level configuration into
   specific network management and controlling policies is illustrated
   in Figure 1. It consists of i) network service systems, ii) a network
   management & control system and iii) network elements.

     +-------------------------+         +-------------------------+ ---
     | +-----------------+     |         | +-----------------+     |  |
     | | Network Service |     |         | | Network Service |     |  |
     | +-----------------+     |         | +-----------------+     |  |
     | | Network Level   | ... |         | | Network Level   | ... |  |
     | | Configuration   |     |         | | Configuration   |     |  |
     | +-----------------+     |   ...   | +-----------------+     |  |
     |                         |         |                         |  |
     |                         |         |                         |  |
     |   Network Service       |         |   Network Service       |  |
     |      System             |         |     System              |  |
     +----------^--------------+         +----------^--------------+  |
                |                                   |           Network
                +-----------------+-----------------+             Level
                                  |  NETCONF/RESTCONF                 |
                   +--------------v-----------------+                 |
                   |                +--------------+|                 |
                   | +------------+ |              ||                 |
                   | |  Topology  | |Policy/       ||                 |
                   | +------------+ |Configuration ||                 |
                   |                +--------------+|                 |
   Network management &   +-----------------+       |                 |
   control systems |      |    Mapping      |       +-------------------
                   |      +-----------------+       |                 |
                   |  +---------------------------+ |                 |
                   |  | Device-level Configuration| |                 |
                   |  +---------------------------+ |                 |
                   +-------------------^------------+            Device
                                       |                          Level
                   +-------------------+-----------------+            |
     CLI/I2RS/     |                       CLI/I2RS/     |            |
   NETCONF/RESTCONF|                  NETCONF/RESTCONF   |            |
                   |                                     |            |
     +-------------v---------------+        +------------v---------+  |
     |                             |        |                      |  |
     |                             |   ...  |                      |  |
     | Network Element             |        | Network Element      |  |
     +-----------------------------+        +----------------------+----

   Figure 1: SUPA configuration and policy mapping overview

Pentikousis, et al.     Expires March 27, 2015                 [Page 4]
Internet-Draft  SUPA Configuration and Policy Mapping  September 2014

   A network service system (NSS) manages and programs the underlying
   network elements indirectly based on the abstract view of the network
   infrastructure. In practice, this means that the network service
   systems can, among others, configure the underlying network as a
   whole rather than as a set of individual network elements. As a
   result the diversity of the actual network elements in active
   operation is abstracted, which allows the NSS to manage and program
   the network in a simpler, more maintainable and efficient way. On the
   other end of the spectrum, the network elements can continue regular
   operation without having to become cognizant of the fact that
   configuration is applied at the network level.

   In order to bridge the gap between configuration from the network
   service systems and network elements, the network management and
   control system has to provide a mapping mechanism which translates
   the configuration settings from network level to the device level.
   This document considers three modules in the network management and
   control system to support such a mapping mechanism, as follows.

   First, a topology module maintains the topology of the network
   infrastructure and provides topology information in the specific
   network layer as the network service expects. It also provides the
   necessary information of each network element when mapping
   configuration from the network-level to device-level. Second, the
   application/policy configuration module receives the network-level
   configuration and acts as the primary input of the mapping mechanism.
   Third, the device configuration produces the output of the mapping
   mechanism and is responsible for distributing the device-level
   configuration to the corresponding network elements.

   In this framework, one would expect the introduction and use of
   algorithms/strategies for specific network services which can
   automatically generate device-level configuration based on the NSS
   policies/configurations. Note, however, that said
   algorithms/strategies are out of the scope of this document.

3.2. Mapping Procedure

   Firstly, the network service system acquires the topology information
   from the topology module in the network management & control system
   if it needs some knowledge of the underlying network to specify
   policies/configurations. Then, the network service system posts the
   policies/configurations to the network management & control system.

   Secondly, in the network management & control system,
   algorithms/strategies for specific network services generate a series

Pentikousis, et al.     Expires March 27, 2015                 [Page 5]
Internet-Draft  SUPA Configuration and Policy Mapping  September 2014

   of detailed configurations from the network level
   policy/configuration, and decide which network element the
   configurations need to be deployed based on the topology module. From
   the topology module, the interfaces supported by a specific network
   element, e.g. [RFC6020], [RESTCONF], [I-D.ietf-i2rs-architecture] or
   CLI (Command Line Interface), can be confirmed. Then, the device
   configuration module distributes the detailed configuration to the
   corresponding network elements, according to the mechanisms that the
   network elements interfaces support. Finally, the network elements
   receive and use the device-level configurations.

3.3. SUPA Mapping Example

   Figure 2 illustrates a simple example in which interoperability
   between SUPA and IP traffic engineering (IPTE) in an inter-data
   center (inter-DC) environment is considered.

   For the purposes of this example, let us focus on the dynamic
   configuration of the IP path between the seven illustrated DCs,
   labeled A, B, ..., G, based on the policies. First of all, we would
   like the IP path to be created based on certain constraints. Secondly
   we would like to map it to the device-level connections. In this
   scenario, there are two paths from DC A to DC B. Typical IP shortest-
   path routing would choose path A(1.1.1.1)->B(2.2.2.2). However, under
   certain conditions, such as, for instance, when the bandwidth between
   A and B is not suitable, the NSS can decide that is better to steer
   traffic from path (A, B) to path (A, C, B).

   Figure 2 depicts the layer 3 topology of the underlying network. The
   network service system attempts to steer traffic from path (A, B) to
   path (A, ..., C, ..., B). At first, NSS needs some information about
   A, B and C to determine the new path in the configuration. This
   information can be obtained from the topology information model.
   Topology for a network-level configuration loses some device-level
   details for the sake of conciseness; it also can be represented as a
   different network layer as the application expects. Secondly, the
   network service system sends the information to the network
   management and control system using a protocol such as NETCONF or
   RESTCONF.

                    +-----------------------+
                    | +-----------------+   |
                    | |   IPTE Service  |   |
                    | +-----------------+   |
                    | |     IPTE        |   |
                    | | Configuration   |   |

Pentikousis, et al.     Expires March 27, 2015                 [Page 6]
Internet-Draft  SUPA Configuration and Policy Mapping  September 2014

                    | +-----------------+   |
                    |       NSS             |
                    +----------^------------+
                               |
                               | NETCONF/RESTCONF
                               |
                +--------------v---------------+
                |                              |
                |                              |
                |     Network management       |
                |     control systems          |
                |                              |
                |                              |
                |                              |
                +--------------^---- ----------+
                               |  CLI/I2RS
                               |
              +----------------v--------------------+
              |                                     |

           1.1.1.1                              2.2.2.2
          +------+                              +------+
          |  A   +------------------------------+  B   +-----+
          +-+--+-+                              +---.--+     |
            |  |                                    |        |
           ++  |                                    |        |
           |   +---+                                |    +---+--+
           |       |                                |    |   G  |
       +---+--+    |                                |    +---+--+
       |  F   |    |                                |        |
       +------+    |             +------+       +---+--+     |
                   |        +----+  C   +-------+  E   +-----+
                   |        |    +------+       +------+
                   |        |     3.3.3.3        5.5.5.5
                +--+---+    |
                |  D   +----+
                +------+
                4.4.4.4

        Figure 2: Bandwidth usage optimization for DC Interconnection

   Figure 3 presents the requirements for traffic steering: the traffic
   needs to be steered to DC B whose IP address is 2.2.2.2/24, the new
   path must start at DC A, terminate at DC B and go through DC C,  and
   the available bandwidth of the new path must more than 10 Mb/s. This
   configuration is derived from the IP TE YANG model described in
   [draft-xxx-supa-configuration-model-00].

Pentikousis, et al.     Expires March 27, 2015                 [Page 7]
Internet-Draft  SUPA Configuration and Policy Mapping  September 2014

     <ipteFlow>
        <ipteFlowName>ddc_flow</ipteFlowName>
        <bandwidth>10000</bandwidth>
        <pathPrefixs>
          <pathPrefix >
            <prefix>2.2.2.2</prefix>
            <maskLength>32</maskLength>
          </pathPrefix>
        </pathPrefixs>
        <paths>
          <path>
            <pathName>path_1</pathName >
            <pathType>auto</pathType >
            <pathNodes>
              <pathNode>
                <nodeId>1.1.1.1</nodeId>
                <nodeRole>ingress</nodeRole>
                <sequence>1</sequence>
              </pathNode>
              <pathNode>
                <nodeId>3.3.3.3</nodeId>
                <nodeRole> transit </nodeRole>
                <sequence>2</sequence>
              </pathNode>
              <pathNode>
                <nodeId>2.2.2.2</nodeId>
                <nodeRole> egress </nodeRole>
                <sequence>3</sequence>
              </pathNode>
            </pathNodes>
          </path >
        </paths>
     </ipteFlow>
   Figure 3: Example traffic steering requirements

   Based on this configuration, the network management and control
   system has to configure each device on the new path-path2, not only
   the devices specified by the configuration such as, B, C, but also
   the devices in the underlying network which must be reconfigured,
   such as in D and E. The topology information is also necessary to
   decide which device ought to be configured.

   In this example, the network-level configuration cannot be deployed
   in the devices directly, it needs to be mapped or translated to
   device-level configuration. For example, in this scenario, the
   networking device (ingress/egress router) of node A, B, C, D, and E

Pentikousis, et al.     Expires March 27, 2015                 [Page 8]
Internet-Draft  SUPA Configuration and Policy Mapping  September 2014

   support configuration with ACL using CLI. In this instance the
   configuration of each node is:

   node A:  next hop of packet from 1.1.1.1 to 2.2.2.2/24 is node D:

     {
     system view
     acl number 2002
     rule permit ip source 1.1.1.1 0.0.0.0 destination 2.2.2.0 0.0.0.255
     quite
     route policy ddc-example permit node 10
     if-match acl 2002
     apply ip-address next-hop 4.4.4.4
     quit
     }

   Node D: next hop of packet from 1.1.1.1 to 2.2.2.2/24 is node C:

     {
     system view
     acl number 2002
     rule permit ip source 1.1.1.1 0.0.0.0 destination 2.2.2.0 0.0.0.255
     quite
     route policy ddc-example permit node 10
     if-match acl 2002
     apply ip-address next-hop 3.3.3.3
     quit
     }

   Node C: next hop of packet from 1.1.1.1 to 2.2.2.2/24 is node E:

     {
     system view
     acl number 2002
     rule permit ip source 1.1.1.1 0.0.0.0 destination 2.2.2.0 0.0.0.255
     quite
     route policy ddc-example permit node 10
     if-match acl 2002
     apply ip-address next-hop 5.5.5.5
     quit
     }

   Node E: next hop of packet from 1.1.1.1 to 2.2.2.2/24 is node B:

Pentikousis, et al.     Expires March 27, 2015                 [Page 9]
Internet-Draft  SUPA Configuration and Policy Mapping  September 2014

     {
     system view
     acl number 2002
     rule permit ip source 1.1.1.1 0.0.0.0 destination 2.2.2.0 0.0.0.255
     quite
     route policy ddc-example permit node 10
     if-match acl 2002
     apply ip-address next-hop 2.2.2.2
     quit
     }

   If the nodes support an I2RS interface, then an I2RS client [I-
   D.ietf-i2rs-architecture] is introduced in the "Device Configuration"
   module. This module will communicate with a number of routers using
   an asynchronous protocol, sets or collects state to/from those
   routers. When configuring node A, B, C, D and E, the network
   management & control system only needs to send the configurations to
   the I2RS client. The configuration of node A and node C set rules to
   steer traffic, whose source IP is 1.1.1.1 and destination IP is
   2.2.2.2/24, to node D and node E respectively. The detailed contents
   and format can be found in [I-D.hares-i2rs-info-model-policy].

   Once nodes A, B, C, D and E have received their respective
   configurations (from the I2RS client or via CLI), the device-level
   configuration is deployed and the traffic is steered as the network
   service system expects.

4. Security Considerations

   Security considerations will be discussed in an upcoming revision of
   this document.

5. IANA Considerations

   TBD

6. References

6.1. Normative References

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

Pentikousis, et al.     Expires March 27, 2015                [Page 10]
Internet-Draft  SUPA Configuration and Policy Mapping  September 2014

6.2. Informative References

   [draft-zaalouk-supa-configuration-model-00] Adel Zaalouk,
   K.Pentikousis, W. Liu, "YANG Data Model for Configuration of Shared
   Unified Policy Automation (SUPA)" (work in progress), September 2014.

   [draft-zhou-supa-architecture-00] C. Zhou, T.Tsou, D.Lopez,
   G.Karagiannis and Q.Sun "The Architecture for Shared Unified Policy
   Automation (SUPA)", draft-zhou-supa-architecture-00, (work in
   progress), September 2014.

   [I-D.ietf-i2rs-architecture] Atlas, A., Halpern, J., Hares, S., Ward,
   D., and T. Nadeau, "An Architecture for the Interface to the
   RoutingSystem", draft-ietf-i2rs-architecture-05 (work in progress),
   July 2014.

   [I-D.hares-i2rs-info-model-policy] Hares, S. and W. Wu, "An
   Information Model for Networkpolicy", draft-hares-i2rs-info-model-
   policy-03 (work in progress), July 2014.

   [RESTCONF] Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando,
   "RESTCONF Protocol", draft-ietf-netconf-restconf-01 (work in
   progress), July 2014.

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

7. Acknowledgements

   This document has benefited comments, suggestions, and proposed text
   provided by Cathy Zhou and Will Liu (listed in alphabetical order).

Pentikousis, et al.     Expires March 27, 2015                [Page 11]
Internet-Draft  SUPA Configuration and Policy Mapping  September 2014

   Authors' Addresses

   Kostas Pentikousis (editor)
   EICT GmbH
   Torgauer Strasse 12-15
   Berlin  10829
   Germany
   Email: k.pentikousis@eict.de

   Junru Lin
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129
   P.R. China
   Email: linjunru@huawei.com

   Yiyong Zha
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129
   P.R. China
   Email: zhayiyong@huawei.com

Pentikousis, et al.     Expires March 27, 2015                [Page 12]