[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 draft-ietf-teas-actn-info-model

Network Working Group                                         Young Lee
Internet Draft                                                   Huawei

Intended status: Informational                           Sergio Belotti
                                                          Alcatel-Lucent
Expires: January 2016
                                                            Dhruv Dhody
                                                                 Huawei

                                                     Daniele Ceccarelli
                                                               Ericsson

                                                          Bin Young Yun
                                                                   ETRI

                                                           July 2, 2015



  Information Model for Abstraction and Control of Transport Networks

                  draft-leebelotti-teas-actn-info-00.txt


Abstract

   This draft provides an information model for abstraction and control
   of transport networks.



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




Lee-Belotti            Expires January 2, 2016                 [Page 1]


Internet-Draft             ACTN Info Model                   March 2015


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 2, 2015.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document.  Code Components extracted from this
   document must include Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.


Table of Contents


   1. Introduction...................................................2
   2. ACTN Applications..............................................3
         2.1.1. Coordination of Multi-destination Service
         Requirement/Policy..........................................5
         2.1.2. Application Service Policy-aware Network Operation...7
         2.1.3. Network Function Virtualization Service Enabled
         Connectivity................................................9
         2.1.4. Dynamic Service Control Policy Enforcement for
         Performance and Fault Management...........................10
         2.1.5. E2E VN Survivability and Multi-Layer (Packet-Optical)
         Coordination for Protection/Restoration....................12
   3. ACTN common interfaces information model......................13
   4. References....................................................18
      4.1. Informative References...................................18
   5. Contributors..................................................18
   Contributors' Addresses..........................................18
   Authors' Addresses...............................................18

1. Introduction

   This draft provides information model for the requirements
   identified in the ACTN requirements [ACTN-Req] and the ACTN



Lee-Belotti            Expires January 2, 2016                 [Page 2]


Internet-Draft             ACTN Info Model                   March 2015


   interfaces identified in the ACTN architecture and framework
   document [ACTN-Frame].

   The ACTN reference architecture identified a three-tier control
   hierarchy as depicted in Figure 1:

   - Customer Network Controllers (CNC)
   - Multi-Domain Service Coordinator (MDSC)
   - Physical Network Controllers (PNC).


   VPN customer         NW Mobile Customer     ISP NW service Customer
       |                         |                           |
   +-------+                 +-------+                   +-------+
   | CNC-A |                 | CNC-B |                   | CNC-C |
   +-------+                 +-------+                   +-------+
         \___________            |             ____________ _/
          ----------             | CMI          ------------
                     \           |            /
                      +-----------------------+
                      |         MDSC          |
                      +-----------------------+
            _________/           |            \_________
            --------             | MPI          ------------____
           /                     |                          \
   +-------+                 +-------+                   +-------+
   |  PNC  |                 |  PNC  |                   |  PNC  |
   +-------+                 +-------+                   +-------+




               Figure 1. A Three-tier ACTN control hierarchy



   The two interfaces with respect to the MDSC, one north of the MDSC
   and the other south of the MDSC are referred to as CMI (CNC-MDSC
   Interface) and MPI (MDSC-PNC Interface), respectively. It is
   intended to model these two interfaces with one common model.



2. ACTN Applications

   This section provides the scope of the ACTN applicability to support
   the following applications identified in [ACTN-Req].


Lee-Belotti            Expires January 2, 2016                 [Page 3]


Internet-Draft             ACTN Info Model                   March 2015


   - Coordination of Multi-destination Service Requirement via Service
     Policy (Section 2.2.1)
   - Application Service Policy-aware Network Operation (section 2.2.2)
   - Network Function Virtualization Service Enabled Connectivity
     (2.2.3)
   - Dynamic Service Control Policy Enforcement for Performance/Fault
     Management (Section 2.2.4)
   - E2E VN Survivability and Multi-Layer (Packet-Optical) Coordination
     for Protection/Restoration (Section 2.2.5)








































Lee-Belotti            Expires January 2, 2016                 [Page 4]


Internet-Draft             ACTN Info Model                   March 2015


2.1.1. Coordination of Multi-destination Service Requirement/Policy

                             +----------------+
                             |       CNC      |
                             |   (Global DC   |
                             |   Operation    |
                             |    Control)    |
                             +--------+-------+
                                      | |  Service Requirement/Policy:
                                      | |  - Endpoint/DC location info
                                      | |  - Endpoint/DC dynamic
                                      | |    selection policy
                                      | |    (for VM migration, DR, LB)
                                      | v
                            +---------+--------+
                            |  Multi-domain    | Service policy-driven
                            |Service Controller| dynamic DC selection
                            +-----+---+---+----+
                                  |   |   |
                                  |   |   |
                 +----------------+   |   +----------------+
                 |                    |                    |
           +-----+-----+       +-----+------+      +------+-----+
           |   PNC for |       |  PNC for   |      |  PNC for   |
           | Transport |       | Transport  |      | Transport  |
           | Network A |       | Network B  |      | network C  |
           +-----------+       +------------+      +------------+
                 |                    |                   |
+---+      ------               ------              ------       +---+
|DC1|--////      \\\\       ////      \\\\      ////      \\\\---+DC4|
+---+ |              |     |              |    |              |  +---+
      |     TN A     +-----+     TN B     +----+      TN C    |
      /              |     |              |    |              |
     / \\\\      ////     / \\\\      ////      \\\\      ////
   +---+   ------        /      ------    \         ------ \
   |DC2|                /                  \                \+---+
   +---+               /                    \                |DC6|
                     +---+                   \ +---+         +---+
                     |DC3|                    \|DC4|
                     +---+                     +---+

                                                DR: Disaster Recovery
                                                LB: Load Balancing
             Figure 2: Service Policy-driven Data Center Selection
   Figure 2 shows how VN service policies from the CNC are incorporated
   by the MDSC to support multi-destination applications. Multi-


Lee-Belotti            Expires January 2, 2016                 [Page 5]


Internet-Draft             ACTN Info Model                   March 2015


   destination applications refer to applications in which the
   selection of the destination of a network path for a given source
   needs to be decided dynamically to support such applications.

   Data Center selection problems arise for VM mobility, disaster
   recovery and load balancing cases. VN's service policy plays an
   important role for virtual network operation. Service policy can be
   static or dynamic. Dynamic service policy for data center selection
   may be placed as a result of utilization of data center resources
   supporting VNs. The MSDC would then incorporate this information to
   meet the service objective of this application.






































Lee-Belotti            Expires January 2, 2016                 [Page 6]


Internet-Draft             ACTN Info Model                   March 2015


2.1.2. Application Service Policy-aware Network Operation

                           +----------------+
                           |       CNC      |
                           |   (Global DC   |
                           |   Operation    |
                           |    Control)    |
                           +--------+-------+
                                    | | Application Service Policy
                                    | | - VNF requirement (e.g.
                                    | |   security function, etc.)
                                    | | - Location profile for each VNF
                                    | v
                          +---------+--------+
                          |  Multi-domain    |  Dynamically select the
                          |Service Controller|  network destination to
                          +-----+---+---+----+  meet VNF requirement.
                                |   |   |
                                |   |   |
                +---------------+   |   +----------------+
                |                   |                    |
         +------+-----+       +-----+------+      +------+-----+
         |   PNC for  |       |  PNC for   |      |  PNC for   |
         | Transport  |       | Transport  |      | Transport  |
         | Network A  |       | Network B  |      | network C  |
         |            |       |            |      |            |
         +------------+       +------------+      +------------+
                |                   |                    |
{VNF b}         |                   |                    |  {VNF b,c}
+---+      ------               ------              ------     +---+
|DC1|--////      \\\\       ////      \\\\      ////      \\\\-|DC4|
+---+ |              |     |              |    |              |+---+
     |      TN A      +---+     TN B       +--+      TN C      |
      /              |     |              |    |              |
     / \\\\      ////     / \\\\      ////      \\\\      ////
   +---+   ------        /      ------    \         ------ \
   |DC2|                /                  \                \\+---+
   +---+               /                    \                 |DC6|
    {VNF a}         +---+                    +---+            +---+
                    |DC3|                    |DC4|      {VNF a,b,c}
                    +---+                    +---+
            {VNF a, b}                      {VNF a, c}

         Figure 3: Application Service Policy-aware Network Operation




Lee-Belotti            Expires January 2, 2016                 [Page 7]


Internet-Draft             ACTN Info Model                   March 2015


   This scenario is similar to the previous case in that the VN service
   policy for the application can be met by a set of multiple
   destinations that provide the required virtual network functions
   (VNF). Virtual network functions can be, for example, security
   functions required by the VN application. The VN service policy by
   the CNC would indicate the locations of a certain VNF that can be
   fulfilled. This policy information is critical in finding the
   optimal network path subject to this constraint. As VNFs can be
   dynamically moved across different DCs, this policy should be
   dynamically enforced from the CNC to the MDSC and the PNCs.







































Lee-Belotti            Expires January 2, 2016                 [Page 8]


Internet-Draft             ACTN Info Model                   March 2015


2.1.3. Network Function Virtualization Service Enabled Connectivity

                           +----------------+
                           |       CNC      |
                           |   (Global DC   |
                           |   Operation    |
                           |    Control)    |
                           +--------+-------+
                                    | | Service Policy
                                    | | (e.g., firewall, traffic
                                    | | optimizer)
                                    | |
                                    | v
                          +---------+--------+
                          |  Multi-domain    | Select network
                          |Service Controller| connectivity subject to
                          +-----+---+---+----+ meeting service policy
                                |   |   |
                                |   |   |
                +---------------+   |   +----------------+
                |                   |                    |
         +------+-----+       +-----+------+      +------+-----+
         |   PNC for  |       |  PNC for   |      |  PNC for   |
         | Transport  |       | Transport  |      | Transport  |
         | Network A  |       | Network B  |      | network C  |
         |            |       |            |      |            |
         +------------+       +------------+      +------------+
                |                   |                    |
                |                   |                    |
+---+      ------               ------              ------     +---+
|DC1|--////      \\\\       ////      \\\\      ////      \\\\-|DC4|
+---+ |              |     |              |    |              |+---+
     |      TN A      +---+     TN B       +--+      TN C      |
      /              |     |              |    |              |
     / \\\\      ////     / \\\\      ////      \\\\      ////
   +---+   ------        /      ------    \         ------ \
   |DC2|                /                  \                \\+---+
   +---+               /                    \                 |DC6|
                    +---+                    +---+            +---+
                    |DC3|                    |DC4|
                    +---+                    +---+


           Figure 4: Network Function Virtualization Service Enabled
                                 Connectivity



Lee-Belotti            Expires January 2, 2016                 [Page 9]


Internet-Draft             ACTN Info Model                   March 2015


   Network Function Virtualization Services are usually setup between
   customers' premises and service provider premises and are provided
   mostly by cloud providers or content delivery providers. The context
   may include, but not limited to a security function like firewall, a
   traffic optimizer, the provisioning of storage or computation
   capacity where the customer does not care whether the service is
   implemented in a given data center or another.

   These services may be hosted virtually by the provider or physically
   part of the network. This allows the service provider to hide his
   own resources (both network and data centers) and divert customer
   requests where most suitable. This is also known as "end points
   mobility" case and introduces new concepts of traffic and service
   provisioning and resiliency (e.g., Virtual Machine mobility).


2.1.4. Dynamic Service Control Policy Enforcement for Performance and
     Fault Management

        +------------------------------------------------+
        |           Customer Network Controller          |
        +------------------------------------------------+
        1.Traffic|  /|\4.Traffic           | /|\
        Monitor& |   |  Monitor            |  | 8.Traffic
        Optimize |   |  Result   5.Service |  | modify &
        Policy   |   |             modify& |  | optimize
                \|/  |       optimize Req.\|/ | result
        +------------------------------------------------+
        |         Mult-domain Service Controller         |
        +------------------------------------------------+
        2. Path  |  /|\3.Traffic           |  |
        Monitor  |   | Monitor             |  |7.Path
        Request  |   | Result     6.Path   |  | modify &
                 |   |            modify&  |  | optimize
                \|/  |       optimize Req.\|/ | result
        +------------------------------------------------+
        |          Physical Network Controller           |
        +------------------------------------------------+

         Figure 5: Dynamic Service Control for Performance and Fault
                                 Management

   Figure 5 shows the flow of dynamic service control policy
   enforcement for performance and fault management initiated by
   customer per their VN. The feedback loop and filtering mechanism
   tailored for VNs performed by the MDSC differentiates this ACTN


Lee-Belotti            Expires January 2, 2016                [Page 10]


Internet-Draft             ACTN Info Model                   March 2015


   scope from traditional network management paradigm. VN level dynamic
   OAM data model is a building block to support this capability.















































Lee-Belotti            Expires January 2, 2016                [Page 11]


Internet-Draft             ACTN Info Model                   March 2015


2.1.5. E2E VN Survivability and Multi-Layer (Packet-Optical)
     Coordination for Protection/Restoration

                        +----------------+
                        |   Customer     |
                        |   Network      |
                        |   Controller   |
                        +--------*-------+
                                 *  |     E2E VN Survivability Req.
                                 *  |     - VN Protection/Restoration
                                 *  v        - 1+1, Restoration, etc.
                          +------*-----+   - End Point (EP) info.
                          |            |
                          |    MDSC    | MDSC enforces VN survivability
                          |            | requirement, determining the
                          |            | optimal combination of Packet/
                          +------*-----+ Opticalprotection/restoration,
                                 *       Optical bypass, etc.
                                 *
                                 *
              **********************************************
              *               *             *              *
         +----*-----+    +----*----+   +----*-----+   +----*----+
         |PNC for   |    |PNC for  |   |PNC for   |   |PNC for  |
         |Access N. |    |Packet C.|   |Optical C.|   |Access N.|
         +----*-----+    +----*----+   +----*-----+   +---*-----+
              *             --*---          *             *
              *          ///      \\\       *             *
            --*---      |   Packet   |      *         ----*-
         ///      \\\   |    Core    +------+------///      \\\
        |  Access    +----\\      ///       *     |   Access   |
        |  Network   |      ---+--          *     |   Network  |  +---+
        |\\\      ///          |            *      \\\      ///---+EP6|
        |   +---+-  |          |       -----*         -+---+      +---+
      +-+-+     |   |          +----///      \\\       |   |
      |EP1|     |   +--------------+  Optical   |      |   |  +---+
      +---+     |                  |    Core    +------+   +--+EP5|
              +-+-+                 \\\      ///              +---+
              |EP2|                    ------ |
              +---+                     |     |
                                     +--++   ++--+
                                     |EP3|   |EP4|
                                     +---+   +---+

      Figure 6: E2E VN Survivability and Multi-layer Coordination for
                        Protection and Restoration



Lee-Belotti            Expires January 2, 2016                [Page 12]


Internet-Draft             ACTN Info Model                   March 2015


   Figure 6 shows the need for E2E protection/restoration control
   coordination that involves CNC, MDSC and PNCs to meet the VN
   survivability requirement. VN survivability requirement and its
   policy need to be translated into multi-domain and multi-layer
   network protection and restoration scenarios across different
   controller types. After an E2E path is setup successfully, the MSDC
   has a unique role to enforce policy-based flexible VN survivability
   requirement by coordinating all PNC domains.

   As seen in Figure 6, multi-layer (i.e., packet/optical) coordination
   is a subset of this E2E protection/restoration control operation.
   The MDSC has a role to play in determining an optimal
   protection/restoration level based on the customer's VN
   survivability requirement. For instance, the MDSC needs to interface
   the PNC for packet core as well as the PNC for optical core and
   enforce protection/restoration policy as part of the E2E
   protection/restoration. Neither the PNC for packet core nor the PNC
   for optical core is in a position to be aware of the E2E path and
   its protection/restoration situation. This role of the MSDC is
   unique for this reason. In some cases, the MDSC will have to
   determine and enforce optical bypass to find a feasible reroute path
   upon packet core network failure which cannot be resolved the packet
   core network itself.

   To coordinate this operation, the PNCs will need to update its
   domain level abstract topology upon resource changes due to a
   network failure or other factors. The MSDC will incorporate all
   these update to determine if an alternate E2E reroute path is
   necessary or not based on the changes reported from the PNCs. It
   will need to update the E2E abstract topology and the affected CN's
   VN topology in real-time. This refers to dynamic synchronization of
   topology from Physical topology to abstract topology to VN topology.

   MDSC will also need to perform the path restoration signaling to the
   affected PNCs whenever necessary.



3. ACTN common interfaces information model

   This section provides ACTN common interface information model to
   support primitives between controllers: CNC-MDSC and MDSC-PNC.

   The basic primitives are required between the controllers. It is
   described between a client controller and a server controller. A
   client-server relationship is recursive between a CNC and a MDSC and
   between a MDSC and a PNC. In the CMI interface, the client is a CNC


Lee-Belotti            Expires January 2, 2016                [Page 13]


Internet-Draft             ACTN Info Model                   March 2015


   while the server is a MDSC. In the MPI interface, the client is a
   MDSC and the server is a PNC. At a minimum, the following primitives
   should be supported:

   - Virtual Network (VN) Instantiate/Modify/Delete
   - VN Topology Update (Push Model)

   <VN> ::= <VN Identifier>

            <VN Action>

            <End-Point List>

            <VN Topology Metric>

            <Traffic-Matrix>

            <VN Survivability>

            <VN Status>

            <VN Topology>



   Where

   <VN Identifier> is an identifier that identifies a particular VN.

   <VN Action> is an indicator if this <VN> is for (i) instantiate,
   (ii) modify; (iii) delete. There may be a case where a query of a VN
   is necessary before an instantiate request. This is subject to
   further investigation.

   <End-Point List> ::= (<Interface Identifier>

                        [<Client Capability>])...

                        <Location Service Profile>

                        <End-Point Dynamic Selection Policy>



      Where



Lee-Belotti            Expires January 2, 2016                [Page 14]


Internet-Draft             ACTN Info Model                   March 2015


         It is assumed that a list of interface identifiers has been
         known to the server prior to the VN Query message flow.


         <Client Capability> ::= <Client Interface Capability>

                                    [<Client-specific Policy>]

                        The Client Capability comprises the client interface
         capability (e.g., maximum interface bandwidth, etc.) and other
         client-specific policy information.



         <Client-specific Policy> ::= <End-Client Policy> |

                                   <Network-Client Policy>

         Where

         <End-Client Policy> pertains to end-client policies which
         specify the end-client related service/operational policies.
         Details of this field will be supplied in a later revision.

         <Network-Client Policy> pertains to the policies related to
         multi-domain network operation assumed by the MDSC. For
         example, domain selection preference in the context of multi-
         domain networks is a network-client policy. Details of this
         field will be supplied in a later revision.



      <Location Service Profile> describes the End-Point Location's
      support for certain Virtual Network Functions (VNFs) (e.g.,
      security function, firewall capability, etc.).


      <End-Point Dynamic Selection Policy> describes if the End-Point
      can support load balancing, disaster recovery or VM migration.



   <VN Topology Metric> ::= <VN Topology Type>

                               <VN Topology Cost>



Lee-Belotti            Expires January 2, 2016                [Page 15]


Internet-Draft             ACTN Info Model                   March 2015


                               [<VN Topology Preference>]

                               [<VN Topology Objective Function>]

         Where

         <VN Topology Type> ::= <Path Vector> | <Graph>

         <VN Topology Cost> describes a particular cost associated with
         the VN Topology link/path such as reservable bandwidth,
         maximum link/path capacity, latency, etc.

         <VN Topology Preference> describes if the request is

           .  a single vs. a bulk request,
           .  VN diversity preference (in case of a bulk request,
               whether VNs should be disjoint or not),
           .  SRLG is required in describing link/path topology, or
           .  Others TDB.


         <VN Topology Objective Function> indicates a specific
         objective function for computing a path vector. This only
         applies when the VN Topology Type is a path vector.





   <Traffic-Matrix> ::= <End-Point List>

                        <Connectivity Type>

                        <Connectivity Metric>

   Where

      <Connectivity Type> ::= <P2P> | <P2MP> | <MP|MP> | <MP|P>

                                 <Multi-destination>



      <Connectivity Matric> ::= <Bandwidth>



Lee-Belotti            Expires January 2, 2016                [Page 16]


Internet-Draft             ACTN Info Model                   March 2015


                                [<Latency>]



   <VN Survivability> ::= <VN Protection Level>

                          <VN Survivability Policy>



   Where

      <VN Protection Level> ::= <No Protection> | <1+1> | <1:N>

      <VN Survivability Policy> ::= <Local Reroute Allowed>

                                    [<Domain Preference>]

                                    <Push Allowed>

                                    <Incremental Update>

      Where

          <Local Reroute Allowed> is a delegation policy to the Server
          to allow or not a local reroute fix upon a failure of the
          primary LSP.

          <Domain Preference> is only applied on the MPI where the MDSC
          (client) provides a domain preference to each PNC (server).

          <Push Allowed> is a policy that allows a server to trigger an
          updated VN topology upon failure without an explicit request
          from the client.

          <Increment Update> is another policy that triggers an
          increment update from the server.

   <VN Status> is the status indicator whether the VN has been
   successfully instantiated/modified/deleted in the server network or
   not in response to <VN Action>.

   <VN Topology> describes the resulting VN topology. Details of <VN
   Topology> are TDB.

   <VN Connectivity Topology> describes the instantiated VN property.
   Details are TBD.


Lee-Belotti            Expires January 2, 2016                [Page 17]


Internet-Draft             ACTN Info Model                   March 2015




4. References

    4.1. Informative References



   [ACTN-Req] Y. Lee, et al., "Requirements for Abstraction and Control
             of Transport Networks", draft-lee-teas-actn-requirements-
             00.txt, work in progress.

   [ACTN-Frame]   D. Ceccarelli, et al., "Framework for Abstraction and
             Control of Transport Networks", draft-ceccarelli-teas-
             actn-framework, work in progress.

5. Contributors

Contributors' Addresses

Authors' Addresses

   Young Lee
   Huawei Technologies
   5340 Legacy Drive
   Plano, TX 75023, USA
   Phone: (469)277-5838
   Email: leeyoung@huawei.com

   Sergio Belotti
   Alcatel Lucent
   Via Trento, 30
   Vimercate, Italy
   Email: sergio.belotti@alcatel-lucent.com

   Dhruv Dhoddy
   Huawei Technologies
   Email: dhruv.ietf@gmail.com


   Daniele Ceccarelli
   Ericsson
   Torshamnsgatan,48
   Stockholm, Sweden
   Email: daniele.ceccarelli@ericsson.com




Lee-Belotti            Expires January 2, 2016                [Page 18]


Internet-Draft             ACTN Info Model                   March 2015


   Bin Young
   ETRI
   Email: byyun@etri.re.kr













































Lee-Belotti            Expires January 2, 2016                [Page 19]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/