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

Versions: 00

SFC                                                             R. Szabo
Internet-Draft                                                  Ericsson
Intended status: Informational                                B. Sonkoly
Expires: September 22, 2016                                          BME
                                                          March 21, 2016


A Multi-Domain Multi-Technology SFC Control Plane Experiment: A UNIFYed
                                Approach
                  draft-unify-sfc-control-plane-exp-00

Abstract

   This document reports on the experimentation with a combined Network
   Function Virtualization (NFV) orchestrator and Service Function Chain
   (SFC) Control Plane proof of concept prototype.

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 http://datatracker.ietf.org/drafts/current/.

   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 September 22, 2016.

Copyright Notice

   Copyright (c) 2016 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.



Szabo & Sonkoly        Expires September 22, 2016               [Page 1]


Internet-DrafSFC Control Plane Experiment: UNIFYed Approach   March 2016


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terms and Definitions . . . . . . . . . . . . . . . . . . . .   2
   3.  Assumptions . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  SFC Control Plane: An Experimental Design . . . . . . . . . .   3
   5.  Experimental Network Scenario . . . . . . . . . . . . . . . .   9
   5.1.  SFC Control Interfaces  . . . . . . . . . . . . . . . . . .  11
   5.1.1.  C1/C2 Interfaces  . . . . . . . . . . . . . . . . . . . .  11
   5.1.2.  C3 Interface  . . . . . . . . . . . . . . . . . . . . . .  12
   6.  Gap Analysis  . . . . . . . . . . . . . . . . . . . . . . . .  12
   6.1.  SFC Requirements  . . . . . . . . . . . . . . . . . . . . .  12
   6.1.1.  General requirements  . . . . . . . . . . . . . . . . . .  12
   6.1.2.  SFC Control Plane Bootstrapping . . . . . . . . . . . . .  13
   7.  Open Questions  . . . . . . . . . . . . . . . . . . . . . . .  14
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  15
   11. Informative References  . . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   The goal of this report is to provide an insight into a Service
   Function Chain (SFC) control and Network Function Virtualization
   (NFV) orchestration proof of concept implementation and
   experimentation in multi-domain/technology environments.

   The reported concept is based on the EU-FP7 UNIFY project's approach
   [I-D.unify-nfvrg-challenges], [UNIFY-GLOBECOM], which defines joint
   compute and network virtualization and control interfaces
   [I-D.unify-nfvrg-recursive-programming].

   The rest of the document is structured as follows: In Section 2 we
   define the related terminology, which is followed with the listing of
   our assumptions in Section 3.  In Section 4 we derive our design from
   the SFC Control Plane framework.  In Section 5 we outline our
   experimental network scenario.  In Section 6 we analyze the gaps
   between our experimental design and the SFC Control Plane.  Finally,
   in Section 7 we formulate some questions to the community based on
   our learnings.

2.  Terms and Definitions

   The reader should be familiar with the terms defined in [RFC7498] and
   [RFC7665].





Szabo & Sonkoly        Expires September 22, 2016               [Page 2]


Internet-DrafSFC Control Plane Experiment: UNIFYed Approach   March 2016


3.  Assumptions

   We assume a Network Function Virtualization (NFV) environment, where
   Service Functions (SF) of a SFC will map as Virtualized Network
   Functions (VNFs).

   We assume that both Classification and Service Function Forwarding
   (SFF) behavior can be expressed by SDN forwarding rules (match rules
   and actions); if a Classification or a SFF cannot be mapped to match
   and action pairs, then a corresponding control plane SF (VNF) is
   instantiated to analyze and tag the flows into SFP.  (This is not
   different than an SF being SFC aware.)

   We assume the existence of multiple SFC domains as a result of
   technology, administration or ownership considerations.

   We assume that a boundary node can act as ingress/egress for Service
   Function Paths entering/leaving the SFC domain.

   We assume dynamic establishment of SFC; static configuration is not
   considered in this document.

4.  SFC Control Plane: An Experimental Design

   We start with the reference architecture of
   [I-D.ietf-sfc-control-plane]:

























Szabo & Sonkoly        Expires September 22, 2016               [Page 3]


Internet-DrafSFC Control Plane Experiment: UNIFYed Approach   March 2016


                  +----------------------------------------------+
                  |                                              |
                  |               SFC  Control Plane             |
          +-------|                                              |
          |       |                                              |
          C1      +------^-----------^-------------^-------------+
   +---------------------|C3---------|-------------|-------------+
   |      |            +----+        |             |             |
   |      |            |SF1 |        |C2           |C2           |
   |      |            +----+        |             |             |
   | +----V--- --+       |           |             |             |
   | |   SFC     |     +----+      +-|--+        +----+          |
   | |Classifier |---->|SFF1|----->|SFF2|------->|SFF3|          |
   | |   Node A  |<----|    |<-----|    |<-------|    |          |
   | +-----------+     +----+      +----+        +----+          |
   |                     |           |              |            |
   |                     |C2      -------           |            |
   |                     |       |       |     +-----------+ C4  |
   |                     V     +----+ +----+   | SFC Proxy |-->  |
   |                           |SF2 | |SF3 |   +-----------+     |
   |                           +----+ +----+                     |
   |                             |C3    |C3                      |
   |  SFC Data Plane Components  V      V                        |
   +-------------------------------------------------------------+

                   Figure 1: SFC Control Plane: Overview

   Let's map the above architecture to Logical Data Plane Components,
   where classification / forwarding is controlled by SDN forwarding
   behavior control over interface "C" consumed by SFC Controller's C1
   and C2 (see Figure 2).




















Szabo & Sonkoly        Expires September 22, 2016               [Page 4]


Internet-DrafSFC Control Plane Experiment: UNIFYed Approach   March 2016


             +----------------------------------------------+
             |                                              |
             |               SFC  Control Plane             |
         +---|C1                                            |
         |   |      C3    C2         C3     C3  C2      C2  |
         |   +-------+----+-----------+------+---+-------+--+
         |           |    |           |      |   |       |
         |           |C3  |           |C3    |C3 |       |
         |         +---+  |         +---+  +---+ |       |
         |         | S |  |         | S |  | S | |       |
         |         | F |  |         | F |  | F | |       |
         |         | 1 |  |         | 2 |  | 3 | |       |
         |         +---+  |         +---+  +---+ |       |
         |          | |   |          | |     |   |       |
    +----C--+    +--a-b---C+      +--a-b-----d---C+    +-C-------+
    |       |    |  | |    |      |  | |    / \   |    |         |
   [1------>3]->[1->+ +->--3]<-->[1->+ +->-+   +--3]->[1------\  3]
    |       |    |        /|      |\              |    |       \ |
   [2<------4]<-[2--<----/ 4]<---[2 \-<-----------4]<-[2<------- 4]->C4
    |       |    |  SFF1   |      |    SFF2       |    |  SFF3   |
    +-------+    +---------+      +---------------+    +---------+
    SFC Class                                             Proxy
     Node A

       Figure 2: SFC Control Plane with Virtual Data Plane Elements

   If we consider an NFV environment, where SFs are instantiated on
   demand as VNF instances, then the SFC Controller's C3 interfaces to
   SFs map to data plane links, which are situationally used for control
   plane communication.  Such DP configuration is by no means different
   from an SFP.

   However, from SDN forwarding control point of view, traffic
   classification or forwarding is again situational.  Classification
   may encapsulate (label) flows based on given match criteria with
   respect to different protocol headers, while forwarding may simply
   based on matching on the SFC encapsulation labels.  Therefore, in a
   virtual data plane component SFC classification and SFF may be
   merged.  Note, if necessary, port based capability reporting may
   constrain logical use of ports for classification or pure forwarding.
   Ports incapable of any match rule processing revert to port based
   forwarding.

   Figure 3 shows a virtual data plane where Classifications and SFF of
   Figure 2 are combined into a single DP node abstraction.






Szabo & Sonkoly        Expires September 22, 2016               [Page 5]


Internet-DrafSFC Control Plane Experiment: UNIFYed Approach   March 2016


     +----------------------------------------------------+
     |                                                    |
     |               SFC  Control Plane               C2  |
     |                                             C3 | C3|
     |                                               \|/  |
     +------------------------------------------------+---+
                                                      |
                                                      |
           +---+            +---+  +---+              |
           | S |            | S |  | S |              |
           | F +--+      +--+ F |  | F +--+           |
           | 1 |  |      |  | 2 |  | 3 |  |           |
           +---+  |      |  +---+  +---+  |           |
            | |   |      |   | |     |    |           |
      +-----a-b---C------C---d-e-----f----C-------+   |
      |     | |   '......'.. | |..../.\...'...... |   |
   ->[1---->+ +->----------->+ +->-+   \         '3]--+
      |                                 \--->----\|
   <-[2-----<-----------------<-------------<-----4]->C4
      |     SFC Classifier + SFF + SFC Proxy      |
      +-------------------------------------------+

                   Figure 3: SFC Control Plane: Overview

   But there must exist a control component who is responsible for
   instantiating the SFs (VNFs).

























Szabo & Sonkoly        Expires September 22, 2016               [Page 6]


Internet-DrafSFC Control Plane Experiment: UNIFYed Approach   March 2016


        +----------------------------------------------------+
        |                                                    +---+
        |               SFC  Control Plane               C2  |   |
        |                                             C3 | C3|   |
        |                                               \|/  |   |
        +------------------------------------------------+---+   |
                                                         .       |
                                                         .       |
              +---+            +---+  +---+              .       |C
              | S |            | S |  | S |              .       |O
              | F +--+      +--+ F |  | F +--+           .       |O
              | 1 |  |      |  | 2 |  | 3 |  |           .       |R
              +---+  |      |  +---+  +---+  |           .       |D
               | |   |      |   | |     |    |           .       |I
         +-----a-b---C------C---d-e-----f----C-------+   .       |N
         |     | |   '......'.. | |..../.\...'...... |   .       |A
   SFP->[1---->+ +->----------->+ +->-+   \         '3]...SFPc   |T
         |                                 \--->----\|   .       |I
      <-[2-----<-----------------<-------------<-----4]---->C4   |O
         |     SFC Classifier + SFF + SFC Proxy      |   .       |N
         +-------------------------------------------+   .       |
                                                         .       |
                                                         .       |
                                                         .       |
        +------------------------------------------------+---+   |
        |                              NFV Orchestrator /|   |   |
        |                                                |   |   |
        |            Virtualized Infrastructure Manager /    +---+
        |                                                    |
        +----------------------------------------------------+

        ... - SFP for the Control Plane/C3
        --- - SFP for the Tenant Data Plane

              Figure 4: SFC Controller with NFV Orchestrator

   We combined the SFC Control Plane with the NFV Orchestrator and the
   Virtualized Infrastructure Manager (VIM) into a Joint NFV and SFC
   Control API.  The combined control (VNF and SFC) together with the
   virtualized data plane creates a single Big Switch with Big Software
   (BiS-BiS) data and control plane abstraction (see Figure 5.










Szabo & Sonkoly        Expires September 22, 2016               [Page 7]


Internet-DrafSFC Control Plane Experiment: UNIFYed Approach   March 2016


          Joint NFV and SFC Control API
              | U
              |
    +---------|-----------------------------------------+
    |   +-----+-------------------------------------+   |
    |   |                                           |   |
    |   |              SFC  Control Plane           |   |
    |   |              NFV Orchestrator             |   |
    |   |     Virtualized Infrastructure Manager    |   |
    |   +----------------------------------------+--+   |
    |                                            .      |
    |                                             '     |
    |        +---+            +---+  +---+         '    |
    |        | S |            | S |  | S |          '   |
    |        | F +--+      +--+ F |  | F +--+        '  |
    |        | 1 |  |      |  | 2 |  | 3 |  |         ' |
    |        +---+  |      |  +---+  +---+  |          .|
    |         | |   |      |   | |     |    |          .|
    |   +-----a-b---C------C---d-e-----f----C-------+  .|
    |   |     | |   '......'.. | |..../.\...'...... |  .|
   [1--[1---->+ +->----------->+ +->-+   \         '3]..|
    |   |                                 \--->----\|   |
   [2--[2-----<-----------------<-------------<-----4]--4]
    |   |     SFC Classifier + SFF + SFC Proxy      |   |
    |   +-------------------------------------------+   |
    |                                                   |
    +---------------------------------------------------+
                        Big Switch with
                     Big Software (BiS-BiS)
               Data and Control Plane Abstraction

    Figure 5: Joint Data and Control Plane Abstraction for NFV and SFC

   Any technology/administration/ownership domains may consist of an
   arbitrary topology of BiS-BiS virtualized data and control plane
   nodes.  There exists an NFV and SFC data and control plane
   abstraction over which control entities can be recursively connected
   into a hierarchy [I-D.unify-nfvrg-recursive-programming].  An example
   control plane structure hierarchy is shown in Figure 6, where the "U"
   denotes the recurring joint abstraction control interface.











Szabo & Sonkoly        Expires September 22, 2016               [Page 8]


Internet-DrafSFC Control Plane Experiment: UNIFYed Approach   March 2016


                       +---------+
                       |Service  |
                       |Orchestr.|
                       +---------+
                            |
                            V U
                  +-------------------+
                  |      NFV&SFC      |
                  |      Control      |
                  +-------------------+
                 /          |          \
                /           V U         \
               |       +---------+       |
           U   V       | NFV&SFC |       V  U
      +---------+      | Control |      +---------+
      | NFV&SFC |      +---------+      | NFV&SFC |
      | Control |        /  |  \        | Control |
      +---------+    +---   V   ----+   +---------+
           |         |    +----+    |         |
           |         |    |BiS.|    |         |
           V         |    +----+    |         V
          +----+     V   /  .   \   V     +----+
       1  |BiS |    +----+  .   +----+    |BiS |  8
       o--|BiS |----|BiS |------|BiS |----|BiS |--o
          +----+    |BiS |  .   |BiS |    +----+
            .       +----+  .   +----+      .
            .         .     .      .        .
   SFC1 ->-SF1-------SF2----SF3------------SF4-->-o
   SFC2 ->------------------------SFa----------->-o
      [--domain1-][------domain2-------][-domain3--]

               Figure 6: Recurring NFV and SFC Control Plane

5.  Experimental Network Scenario

   Figure 7 shows our network scenario with two layers of SFC
   Controllers corresponding to the technology domains and the
   overarching SFC Controller.

   The Mininet SDN and Click Execution Environment (EE) domain contains
   four OVS switches with two Click EEs attached to two of the four OVS
   switches.  A host emulation is also attached to one of the OVS
   switches.  There is an inter-domain link connecting one of the OVS
   switch to the Transport SDN Domain.

   The transport SDN domain consists of two MikroTik RB2011Ui HW
   OpenFlow switches and is controller by a POX controller integrated
   within the overarching SFC Controller.



Szabo & Sonkoly        Expires September 22, 2016               [Page 9]


Internet-DrafSFC Control Plane Experiment: UNIFYed Approach   March 2016


   The OpenStack domain is a vanilla OpenStack release with an OVS
   switch converting L2 steering to VxLAN connections to the Virtual
   Machines (VMs) running in the compute nodes.

   The Docker host is extended with SFF forwarding, i.e., it natively
   encapsulates/decapsulates frames received over its data plane
   connection to and from the hosted containers.

   In the example SFC request, a L3 Host is connected to a L3 WebServer
   in the forward direction and in the backward path a deep packet
   inspection (DPI), a sniffer, a header compressor (HC) and a header
   de-compressor (HDC) are inserted into the SFC as bump-in-the-wire
   (middlebox) SFs.  (See Figure 7).

   The SFC request to the infrastructure mapping is dynamic and is based
   on i) compute, storage and networking resource availabilities and
   capabilities; ii) constraints contained within the SFC request (e.g.,
   latency, bandwidth, memory, etc. requirements) and iii) operational
   policies (e.g., utilization, energy efficiency, etc.)

   The SFC example mapping shown in Figure 7 are: WebServer and DPI ->
   OpenStack; sniffer -> Docker; HC and HDC -> Mininet.  The example is
   built incrementally by extending the Host -- WebServer connection by
   an additional SF in each step.



























Szabo & Sonkoly        Expires September 22, 2016              [Page 10]


Internet-DrafSFC Control Plane Experiment: UNIFYed Approach   March 2016


                      Tenant
                        :
                     +---------+
                     |SFC&NFV  |
                     |Ctrller G|
                     |Global   |
                     +---------+
                ......' :  :  '.....................
             U .        :  '...........U           :U
      +---------+       :          +---------+   +---------+
      |SFC&NFV  |       :          |SFC&NFV  |   |SFC&NFV  |
      |Ctrller M|       :          |Ctrller D|   |Ctrller O|
      |Mininet  |       :          |Docker   |   |OpenStack|
      +---------+       :          +---------+   +---------+
          :             :               :            :
          :             :               :        +---------+
          :             :               :        |OpenStack|
      +---------+   +---------+         :        |based    |
      |Mininet  |   |Transport|-#----------------|Cloud    |
      |SDN      |-#-|SDN      |    +----:----+   +---------+
      |Click EE |   |Domain   |-#--|Docker   |
      +---------+   +---------+    |Host     |
                                   |         |
   # ENNI reference points         +---------+

   SFC:
     H1--->--------------------->----------------------+WebSrv
      '-HDC--HC---------------<-------Sniffer------DPI-'
                     Host2<------------'

                  Figure 7: Experimental Network Scenario

5.1.  SFC Control Interfaces

5.1.1.  C1/C2 Interfaces

   Since C1/C2 interfaces are combined in our design, it is situational,
   which one is in use.  For example, the classification and the SFP
   encapsulation of the Host's traffic into the SFC is requested for the
   Host's attachment point by Controller G to Controller M.  Controller
   M in turn, determines where such classification can happen and maps
   the request to a network element, where the classification can be
   executed.  For example, if a complex classification is not supported
   at the attachment point, then a port based forwarding is configured
   to convey all the Host's traffic to a classification port.  In our
   case, the classification is executed at the Host's attachment port
   and an SFP encapsulation is assigned.




Szabo & Sonkoly        Expires September 22, 2016              [Page 11]


Internet-DrafSFC Control Plane Experiment: UNIFYed Approach   March 2016


   The SFP encapsulation, however, is split according to the
   Controllers' responsibility domains.  While Controller G is
   responsible the encapsulation for External Network Network Interfaces
   (ENNI) between the different domains, domain Controllers M, D, O are
   responsible for the SFP mapping between their ingress an egress
   points.

   The ENNI encapsulations are technology specific as alignment between
   multiple domains must be achieved.  Such domain specific parameters
   (e.g., supported transport layer encapsulations) are part of the
   domain virtualizations shown to the higher layer control entity.

5.1.2.  C3 Interface

   We use the C3 interface to configure SFs, which must be SFF aware.
   The VMs within the OpenStack domain must terminate/initiate L2 in L3
   tunnels, in our case VxLAN tunnels.

   In the case when SFs are instantiated on demand (part of an NFV
   orchestration together with SFC configuration), then the SF to SFC
   Controller connection must also be established on-demand.  This,
   however, - as one can observer - is no way different compared to SFP
   connecting two or more SFs; one situationally being the SFC
   Controller itself.  Therefore, the control or data plane usage of an
   SFC is situational; in a fully dynamic environment they boil down to
   the same configuration mechanisms.

   Interestingly, conveying SFF forwarding configuration to SFs may
   happen via various platform services.  In our case, when we only used
   the SF's C3 interface to configure the VxLAN endpoints, we used
   OpenStack to VM metadata communication services with an agent in the
   VM pulling VxLAN configuration data.

   However, if a direct C3 control interface is needed between the SF
   and the SFC Controller then a corresponding SFC must be established.

6.  Gap Analysis

6.1.  SFC Requirements

6.1.1.  General requirements

   We assess the requirements of [I-D.ietf-sfc-control-plane] one by
   one:

   "Some deployments require that forwarding within an SFC-enabled
   domain must be allowed even if no control protocols are enabled.
   Static configuration must be allowed."



Szabo & Sonkoly        Expires September 22, 2016              [Page 12]


Internet-DrafSFC Control Plane Experiment: UNIFYed Approach   March 2016


   o  No specific considerations; both the SFs can be Physical Network
      Functions (PNFs) or pre-instantiated VNFs; the forwarding
      configuration may be statically configured.

   "A permanent association between an SFC data plane element with a
   Control Element must not be required; (...)"

   o  No special considerations; both SFs and the forwarding overlay
      works according to their configurations if connection to the
      control entity is lost.

6.1.2.  SFC Control Plane Bootstrapping

   "The interface that is used to feed the SFC control plane with
   service objectives and guidelines is not part of the SFC control
   plane itself. (...)"

   "Locators for classifiers/SFF/SFs/SFC proxies, etc."

   o  In the proposed domain abstraction only classifiers/SFF/SFC
      proxies are visible for the SFC Controller (the rest is not of the
      concern of the SFC Control, hence are hidden); therefore, the
      logical locators for the classifiers/SFF/SFC proxies are
      inherently known

   o  SFs are instantiated by the NFVO logic co-existing with the SFC
      controller.  Therefore, the combined Control Plane inherently
      knows the location of all SFs.

   "SFs serviced by each SFF"

   o  This is the control plane association; hence inherently exists.

   "A list of service function chains, including how they are structured
   and unambiguously identified."

   o  The structure of SFC is created within the SFC Control Plane,
      hence it inherently exists there.

   Status of each SFC: active/pre-deployment phase/etc.(...)"

   o  In the experimental implementation these states are internal to
      the Control Plane and they do not exist below the SFC Controller.
      This is because an SFC Controller configures the underlying
      virtual data plane instead of communicating with SFC intents.
      However, there may exist various configuration targets in the
      could be running, candidate, initial, etc. or other configuration




Szabo & Sonkoly        Expires September 22, 2016              [Page 13]


Internet-DrafSFC Control Plane Experiment: UNIFYed Approach   March 2016


      targets may exist, however, those are independent generic
      configuration targets.

   "A list of classification guidelines and/or rules to bind flows to
   SFCs/SFPs."

   o  In our view, all these parameters are input to the SFC Controller
      and are part of the SFC request.  As such, the goal of the SFC
      Controller is to map such northbound requests to its southbound
      interfaces.  All the requests, the mapping and the southbound
      outputs are inherently stored.

   "Optionally, (traffic/CPU/memory) load balancing objectives at the
   SFC level or on a per node (e.g., per-SF/SFF/SFP proxy) basis."

   o  In our design, the northbound to southbound mapping algorithm
      takes into account these objectives as part of the operational
      policies or explicit tenant requirements contained in the SFC
      request.  It is important to note, that such requirements are
      service agnostic.

   "Security credentials."

   o  In our design, each tenant has its own SFC Control plane interface
      with its full context (policy, access, accounting, security,
      etc.).  Our SFC API is build over the NETCONF protocol [RFC6241]
      relying on a secure transport layer.

   "Context information that needs to be shared on a per SFC basis."

   o  We maintain per tenant context; individual SFCs are situational
      with this respect as a tenant may merge/split SFCs any time.  The
      SFC Controller builds configuration request for the underlying
      layers aggregating all of its tenants' request, therefore SFCs are
      always scoped to control API and does not travel individually
      through the vertical SFC control plane layers.

7.  Open Questions

   o  What is the rationale behind the separation of the SF placement
      and the SFC Control Plane (traffic steering) if the SFC Control
      Plane needs to know the locators of the SF?  In a dynamic
      environment, when SFs are deployed as VNFs, can a joint
      consideration of software and networking resources result in
      better deployments?

   o  What is the rationale behind the coupling of the Service Path
      Header with the Context Headers?  Can the Service Path Header



Szabo & Sonkoly        Expires September 22, 2016              [Page 14]


Internet-DrafSFC Control Plane Experiment: UNIFYed Approach   March 2016


      stripped from the encapsulation before sending it the SF?  Is the
      Context Header service specific?  If separated, can the Service
      Path Header be encoded into the forwarding behavior of the domain
      and yield all SFs SFP (overlay) unaware?

8.  IANA Considerations

   This memo includes no request to IANA.

9.  Security Considerations

   TBD

10.  Acknowledgement

   The research leading to these results has received funding from the
   European Union Seventh Framework Programme (FP7/2007-2013) under
   grant agreement no. 619609 - the UNIFY project.  The views expressed
   here are those of the authors only.  The European Commission is not
   liable for any use that may be made of the information in this
   document.

11.  Informative References

   [I-D.ietf-sfc-control-plane]
              Li, H., Wu, Q., Huang, O., Boucadair, M., Jacquenet, C.,
              Haeffner, W., Lee, S., Parker, R., Dunbar, L., Malis, A.,
              Halpern, J., Reddy, T., and P. Patil, "Service Function
              Chaining (SFC) Control Plane Components & Requirements",
              draft-ietf-sfc-control-plane-03 (work in progress),
              January 2016.

   [I-D.unify-nfvrg-challenges]
              Szabo, R., Csaszar, A., Pentikousis, K., Kind, M., Daino,
              D., Qiang, Z., and H. Woesner, "Unifying Carrier and Cloud
              Networks: Problem Statement and Challenges", draft-unify-
              nfvrg-challenges-03 (work in progress), January 2016.

   [I-D.unify-nfvrg-recursive-programming]
              Szabo, R., Qiang, Z., and M. Kind, "Towards recursive
              virtualization and programming for network and cloud
              resources", draft-unify-nfvrg-recursive-programming-02
              (work in progress), October 2015.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <http://www.rfc-editor.org/info/rfc6241>.



Szabo & Sonkoly        Expires September 22, 2016              [Page 15]


Internet-DrafSFC Control Plane Experiment: UNIFYed Approach   March 2016


   [RFC7498]  Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
              Service Function Chaining", RFC 7498,
              DOI 10.17487/RFC7498, April 2015,
              <http://www.rfc-editor.org/info/rfc7498>.

   [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
              Chaining (SFC) Architecture", RFC 7665,
              DOI 10.17487/RFC7665, October 2015,
              <http://www.rfc-editor.org/info/rfc7665>.

   [UNIFY-GLOBECOM]
              Sonkoly, B., Szabo, R., Jocha, D., Czentye, J., Kind, M.,
              and F-J. Westphal, "UNIFYing Cloud and Carrier Network
              Resources: An Architectural View", Proc. IEEE GLOBECOM
              2015, San Diego, CA, USA GLOBECOM, December 2015.

Authors' Addresses

   Robert Szabo
   Ericsson Research, Hungary
   Irinyi Jozsef u. 4-20
   Budapest  1117
   Hungary

   Email: robert.szabo@ericsson.com
   URI:   http://www.ericsson.com/


   Balazs Sonkoly
   Budapest University of Technology and Economics
   Magyar tudosok krt. 2
   Budapest  1111
   Hungary

   Email: sonkoly@tmit.bme.hu
   URI:   http://www.tmit.bme.hu/















Szabo & Sonkoly        Expires September 22, 2016              [Page 16]


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