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

Versions: 00

ALTO WG                                                        D. Lachos
Internet-Draft                                             C. Rothenberg
Intended status: Informational                                   Unicamp
Expires: September 12, 2019                               March 11, 2019


                   Multi-domain E2E Network Services
                draft-lachosrothenberg-alto-md-e2e-ns-00

Abstract

   Evolving networking scenarios (e.g., 5G) are considering the
   provision of value-added and on-demand end-to-end (E2E) network
   services in multi-domain (multi-operator/multi-technology)
   environments.  This document presents different initiatives, mainly
   within standardization efforts and research projects, working on E2E
   network services across multiple domains.  Problem statement and a
   layered network model are also described.  In addition, this document
   raises an initial proposal towards a new ALTO service in support of
   E2E network service requirements.  Finally, another important
   objective of this document is to begin a discussion about motivating
   use cases in scope of the ALTO WG after the re-chartering process.

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 https://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 12, 2019.

Copyright Notice

   Copyright (c) 2019 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
   (https://trustee.ietf.org/license-info) in effect on the date of



Lachos & Rothenberg    Expires September 12, 2019               [Page 1]


Internet-Draft             Multi-domain E2E NS                March 2019


   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.  Context and Motivation  . . . . . . . . . . . . . . . . . . .   3
     2.1.  Standardization Activities  . . . . . . . . . . . . . . .   3
       2.1.1.  IETF  . . . . . . . . . . . . . . . . . . . . . . . .   3
       2.1.2.  ETSI  . . . . . . . . . . . . . . . . . . . . . . . .   4
       2.1.3.  MEF . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.2.  Research projects . . . . . . . . . . . . . . . . . . . .   5
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Network Function Placement Decisions  . . . . . . . . . .   6
     3.2.  Network Inventory . . . . . . . . . . . . . . . . . . . .   6
     3.3.  Publishing Information  . . . . . . . . . . . . . . . . .   6
   4.  Network Function Virtualization Architectures and
       Infrastructures . . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  Layered Network Model . . . . . . . . . . . . . . . . . .   8
   5.  ALTO Extension: E2E Network Service Requirements
       Representation  . . . . . . . . . . . . . . . . . . . . . . .  10
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  12
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   The fifth generation (5G) of cellular networks is not only considered
   an evolution but a revolution in the field of information and
   communication technologies [WHITE-PAPER-5G].  5G will support the
   creation of new and novel End-to-End (E2E) services, applications and
   complex use case scenarios, such as massive Internet of Things,
   extreme real-time communications, broadband access everywhere, higher
   user mobility.  All these scenarios and services are triggering a
   modification in the way telecommunications sector deploy new network
   services, shifting from a commonly manual and long process to a
   flexible and programmable process.

   In this context, cloud computing , Software Defined Networking (SDN),
   and Network Function Virtualization (NFV) arise as technological



Lachos & Rothenberg    Expires September 12, 2019               [Page 2]


Internet-Draft             Multi-domain E2E NS                March 2019


   pillars to achieve the necessary function programmability, network
   programmability, and resource virtualization during the provision of
   E2E network services.

   The delivery of an E2E network service, or simply E2E service, often
   requires VNFs and their specific order [RFC7665].  Network operators
   start offering to their customers the possibility of configuring
   network services with specific requirements in terms of resources
   (e.g., cpu, memory, hard-disk) and performance objectives (e.g.,
   bandwidth, latency) [VNF-PLAC].  Such demands are usually composed by
   distributed resources which are expected to available across multiple
   domains with different technology and/or administration.

   This document offers an overview of standardization activities and
   research projects, including problem statement, behind building E2E
   services traversing different domains (technological and/or
   administrative).  Moreover, from a layered network model, it is
   proposed a potential ALTO extension related to E2E Network Service
   requirements representation based on the ETSI NFV MANO data model.

   The overall rationale of this document is to arouse discussions into
   the ALTO WG concerning potential new items to be considered for the
   re-charter.

2.  Context and Motivation

   Different standardization efforts (e.g., IETF, MEF, ETSI) and
   research projects activities (e.g., 5GEx [H2020.5GEX], 5G-Transformer
   [H2020-5G-TRANSFORMER], T-NOVA [T-NOVA]) have been focused on multi-
   domain network service chaining.  Standardization is essential to
   provide recommendations to create interoperable architectures with
   standardized protocols, and solutions (being developed by different
   projects) are addressing a diverse range of requirements to provide
   network services provided using multiple domains.

   This section briefly describes, on the one hand, main standardization
   efforts delivering collections of norms and recommendations, while on
   the other hand it also provides an overview of several projects
   formed to develop network services across multiple domains.

2.1.  Standardization Activities

2.1.1.  IETF

   SFC that span domains owned by single or multiple administrative
   entities are being proposed.  The Hierarchical Service Function
   Chaining (hSFC) [RFC8459], for example, defines an architecture to
   deploy SFC in large networks.  This RFC proposes to decompose the



Lachos & Rothenberg    Expires September 12, 2019               [Page 3]


Internet-Draft             Multi-domain E2E NS                March 2019


   network into smaller domains (domains under the control of a single
   organization).  Another proposed initiative is [DRAFT-HH-MDSFC] that
   describes SFC crossing different domains owned by various
   organizations (e.g., ISPs) or by a single organization with
   administration partitions.  The proposed architecture uses a SFC
   eXchange Platform (SXP) to collect and exchange information
   (topology, service states, policies, etc.) between different
   organizations and it works both in centralized (Multiple SFC domains
   connected by a logical SXP) and distributed (SXP server as a broker)
   environments.

   More recently, the IETF ALTO WG started to discuss the uses of ALTO
   as an information model for representing network resource and
   services in multi-domain scenarios:

   o  [DRAFT-ALTO-BROKER-MDO] proposes an ALTO-based Broker-assisted
      architecture where a broker plane works as a coordinator between a
      set of top-level control planes, i.e., Domain Orchestrators (DOs)
      and Multi-Domain Orchestrators (MdOs).  The ALTO services (with
      the proposed extensions) provides abstract maps with a simplified,
      yet enough information view about MdOs involved in the federation.
      This information includes the abstract network topology, resource
      availability (e.g., CPUs, Memory, and Storage) and capabilities
      (e.g., supported network functions).

   o  [DRAFT-ALTO-UNICORN] presents Unicorn, a resource orchestration
      framework for multi-domain, geo-distributed data analytics.  This
      work resorts in ALTO as the information model to support the
      accurate, yet privacy-preserving resource discovery across
      different domains.  The key information to be provided by the use
      of ALTO including different types of resources, e.g., the
      computing, storage, and networking resources.

   o  [DRAFT-MD-SFC-ALTO] describes different standardization activities
      and research projects addressing the challenges posed by Service
      Function Chaining (SFC) across multiple domains (specifically,
      multiple administrative domains).  In addition, this document
      presents an initial approach to realize inter-domain service
      chaining leveraging the ALTO protocol.  Finally, another important
      concern of this document is to initiate a discussion (ALTO, SFC as
      well as 9other WGs) regarding if, how, and under what conditions
      ALTO can be useful to improve the multi-domain SFC process.

2.1.2.  ETSI

   The ETSI NFV ISG is paving the way toward viable architectural
   options supporting the efficient placement of functions in different
   administrative domains.  More specifically, the document



Lachos & Rothenberg    Expires September 12, 2019               [Page 4]


Internet-Draft             Multi-domain E2E NS                March 2019


   [ETSI-NFV-IFA028] reports different NFV MANO architectural approaches
   with use cases related to network services provided using multiple
   administrative domains.  Besides, it gives a non-exhaustive list of
   key information to be exchanged between administrative domains
   (monitoring parameters, topology view, resource capabilities, etc.)
   and recommendations related to security to permit the correct and
   proper operation of the final service.

2.1.3.  MEF

   With its work on the Service Operations Specification MEF
   55 [MEF-SOE-MEF55], MEF has defined a reference architecture and
   framework for describing functional management entities (and
   interfaces between them) needed to support Lifecycle Service
   Orchestration (LSO).  This LSO architecture enables automated
   management and control of E2E connectivity services across multiple
   operator networks.  The automated service management includes
   fulfillment, control, performance, assurance, usage, security,
   analytics, and policy capabilities that make it possible, for
   example, expanding the footprint of service providers to interact
   with potentially several operators to manage and control the access
   portions of E2E services.

2.2.  Research projects

   Several projects include an architectural model integrating NFV
   management with SDN control capabilities to address the challenges
   towards flexible, dynamic, cost-effective, and on-demand service
   chaining.

   [H2020.5GEX] aims to integrate multiple administrations and
   technologies through the collaboration between operators in the
   context of emerging 5G networking. [VITAL][T-NOVA] follow a
   centralized approach where each domain advertises its capabilities to
   a federation layer which will act as a broker.  In order to avoid one
   network operator per country or regions, [H2020-5G-NORMA] proposes
   the use of management and control into a single virtual domain.
   Also, the 5G-Transformer project [H2020-5G-TRANSFORMER] is defining
   flexible slicing and federation of transport networking and computing
   resources across multiple domains.  The NECOS project [H2020-NECOS],
   focused on the realization of E2E multi-domain cloud network slicing,
   proposes an architectural approach with slice information interfaces
   for resource exposure and resource discovery during slice
   provisioning.  In addition , the architecture includes a slice
   marketplace interface between domain orchestrators and a marketplace
   broker.





Lachos & Rothenberg    Expires September 12, 2019               [Page 5]


Internet-Draft             Multi-domain E2E NS                March 2019


3.  Problem Statement

3.1.  Network Function Placement Decisions

   An E2E service request specify virtual nodes (a set of required VNFs)
   as well as virtual links (the order in which they must be executed).
   Virtual nodes are deployed in virtual machines hosted by different
   physical servers, and virtual links correspond to physical paths that
   connect those servers hosting VNFs.  Both virtual nodes and virtual
   links are limited resources and both may also be located on different
   technological domains in a single administration and even crossing
   multiple administrations [VNF-MOB][SFC-ORC].  So that the placement
   decision problem involves to discover "best" candidate resources and
   "best" feasible paths between such resources.

3.2.  Network Inventory

   Placement decisions are a fundamental step for the management and
   orchestration of network services.  Management systems (e.g., DOs,
   MdOs) need to maintain an inventory of the network providing a real-
   time representation or view of available infrastructure resources,
   software resources, and their relationships.  However, The size of a
   network inventory can be very large in scenarios, such as distributed
   cloud and edge computing.  As a result, management systems experiment
   scalability problems processing large amounts of data to decide where
   to instantiate a service or part of the service.  Therefore, building
   a network inventory, under these circumstances, needs aggregation
   mechanisms to reduce time for discovery of resources and to simplify
   and optimize management of them.

3.3.  Publishing Information

   Once a network inventory is built, a mechanism for publishing
   information is also necessary so that the network inventory can
   provide a simplified, yet enough network information view to
   management systems.  In order to retrieve such information to perform
   placement decisions, a communication protocol between management
   systems and network inventory is also necessary.

   Therefore, on the one hand, network information (e.g., network
   locations, costs between them, endhost properties) needs to be
   advertised to the network applications and, on the other hand,
   network applications (e.g., DOs, MdOs) needs to describe their
   requirements and obtain information about resources that suit such
   requirements.






Lachos & Rothenberg    Expires September 12, 2019               [Page 6]


Internet-Draft             Multi-domain E2E NS                March 2019


4.  Network Function Virtualization Architectures and Infrastructures

   With the introduction of NFV, network functions (e.g., switches,
   routers, firewalls), and also complex network functions (e.g., EPC)
   are able to be virtualized and implemented as a collection of virtual
   machines (VMs) deployed over the virtualized infrastructure.  In
   turn, the virtualized infrastructure is instantiated on a substrate
   network.

   In this context, one of the most accepted NFV architectural
   frameworks is the proposed by the ETSI ISG NFV working
   group [ETSI-NFV-WHITEPAPER].  Figure 1 [DRAFT-MD-VIRT] shows this NFV
   reference architecture.  On the left, we can see the data plane:
   NFVIs hardware/software, VNFs, and optional element management
   systems.  On the right, we see the control plane: VIM which is
   something like Openstack or Kubernetes, virtual network function
   managers, and the NFV Orchestrator on the top.


































Lachos & Rothenberg    Expires September 12, 2019               [Page 7]


Internet-Draft             Multi-domain E2E NS                March 2019


                                                  +--------------------+
   +-------------------------------------------+  | ----------------   |
   |                 OSS/BSS                   |  | | NFV          |   |
   +-------------------------------------------+  | | Orchestrator +-- |
                                                  | ---+------------ | |
   +-------------------------------------------+  |    |             | |
   |  ---------     ---------     ---------    |  |    |             | |
   |  | EM 1  |     | EM 2  |     | EM 3  |    |  |    |             | |
   |  ----+----     ----+----     ----+----    |  | ---+----------   | |
   |      |             |             |        |--|-|    VNF     |   | |
   |  ----+----     ----+----     ----+----    |  | | manager(s) |   | |
   |  | VNF 1 |     | VNF 2 |     | VNF 3 |    |  | ---+----------   | |
   |  ----+----     ----+----     ----+----    |  |    |             | |
   +------|-------------|-------------|--------+  |    |             | |
          |             |             |           |    |             | |
   +------+-------------+-------------+--------+  |    |             | |
   |         NFV Infrastructure (NFVI)         |  |    |             | |
   | -----------    -----------    ----------- |  |    |             | |
   | | Virtual |    | Virtual |    | Virtual | |  |    |             | |
   | | Compute |    | Storage |    | Network | |  |    |             | |
   | -----------    -----------    ----------- |  | ---+------       | |
   | +---------------------------------------+ |  | |        |       | |
   | |         Virtualization Layer          | |--|-| VIM(s) +-------- |
   | +---------------------------------------+ |  | |        |         |
   | +---------------------------------------+ |  | ----------         |
   | | -----------  -----------  ----------- | |  |                    |
   | | | Compute |  | Storage |  | Network | | |  |                    |
   | | | hardware|  | hardware|  | hardware| | |  |                    |
   | | -----------  -----------  ----------- | |  |                    |
   | |          Hardware resources           | |  |  NFV Management    |
   | +---------------------------------------+ |  | and Orchestration  |
   +-------------------------------------------+  +--------------------+


                Figure 1: ETSI MANO Reference Architecture

4.1.  Layered Network Model

   Based on the ETSI NFV reference architecture, a layered network model
   is identified: Network Service layer, VNF layer, and Resource Layer.
   This model allows a separation of network relationships in different
   levels of abstraction.  For example, network services can be queried
   at different levels of abstraction or we can map service paths in
   different layers (from an abstract to a more concrete layer).

   In Figure 2, we have a network service with a set of interconnected
   VNFs.  This network service topology is represented by the Network
   Service layer.



Lachos & Rothenberg    Expires September 12, 2019               [Page 8]


Internet-Draft             Multi-domain E2E NS                March 2019


   A VNF is typically divided into a set of virtual function components
   (VFCs) which comprise the VNF Layer.  Each VFC is an application
   running within a single VM or container.

   In case of the resource layer, we have virtual layer and physical
   layer.  The virtual layer represents the virtual overlay network and
   the physical layer represents the substrate network.  Virtualized
   infrastructures (e.g., VMs, virtual routers) are instantiated on a
   physical infrastructure.










































Lachos & Rothenberg    Expires September 12, 2019               [Page 9]


Internet-Draft             Multi-domain E2E NS                March 2019


          +----------+
          |          |
          | +------+ |
  Network | | NFVO | |    +-----+    +------+     +------+     +------+
  Service | +---+--+ |    | SRC +--->-|VNF1 +---->+ VNF2 +---->+ DST  |
  Layer   |     |    |    +-----+    +--+---+     +------+     +------+
          |     |    |                  |
  +--------------------------------------------------------------------+
          |     |    |                  |
          |     |    |     +------------v------------------+
          |     |    |     |           VNF1                |
          |     |    |     +-------+-----+--------------+--+
          | +---+--+ |             |     |              |     Repeat for
  VNF     | | VNFM | |             |     |              |     each VNF
  Layer   | +---+--+ |   +----+    |     |    +----+  +-+--+
          |     |    |   |VFC +----+     +----+VFC |  |VFC |
          |     |    |   +-+--+               +-+--+  +-+--+
          |     |    |     |                    |       |
  +-------+----------+-------------------------------------------------+
                |          |                    |       |             V
          |     |    |     |                    |       |             i
          |     |    |   +-+-+     +---+      +-+-+   +-+-+    +---+  r
          |     |    |   |VM |     |VM |      |VM |   |VM |    |VM |  t
          |     |    |   +-+-+     ++--+      +-+-+   +-+-+    ++--+  u
          |     |    |     |        |           |       |       |     a
          |     |    |     |  +---+ |           |       |       |     l
          | +---+-+  |     |  |VM | |           |       |       |
  Resource| | VIM |  |     |  ++--+ |           |       |       |
  Layer   | +-----+  |     |   |    |     +-----v-------v--+    |     P
          |          |     |   |    | XXXX| Host/Hypervisor|XXX |     h
          |          |     |   |    | X   +----------------+  X |     y
          |          |     |   |    | X                       X |     s
          |          | +---v--->  +-v-X---+              +----X-v+    i
          |          | | Host/ +  | Host/ XXXXXXXXXXXXXXX| Host/ |    c
          |  NFV     | | Hyp   XXX| Hyp   +              | Hyp   |    a
          |  MANO    | +-------+  +-------+              +-------+    l
          +----------+


                Figure 2: ETSI MANO Reference Architecture

5.  ALTO Extension: E2E Network Service Requirements Representation

   From the layered network model described in the previous section, we
   are considering an ALTO extension related to E2E Network Service
   requirements representation.  An initial proposal has been presented
   in the ALTO-based Broker-assisted MdO draft [DRAFT-ALTO-BROKER-MDO]
   where network applications (as ALTO clients) can specify a set of



Lachos & Rothenberg    Expires September 12, 2019              [Page 10]


Internet-Draft             Multi-domain E2E NS                March 2019


   basic E2E service requirements to an ALTO server in order to obtain
   candidate resources (domains) and candidate paths.

   This initial E2E service requirement representation is inspired on
   the ETSI NFV MANO data model [ETSI-NFV-MAN001].  This model defines
   network services as a composition of network functions including the
   specification of deployment and operational requirements.  Such
   specifications are captured in templates called Network Service
   Descriptor (NSD) and Virtual Network Function Descriptor (VNFD) that
   contain (relatively) static information used in the process of on-
   boarding network services and VNFs, respectively.

   o  High level objects in a NSD include (among others)
      [ETSI-NFV-MAN001][OSM-DM]:

      *  Constituent VNFs: List of VNFDs that are part of the network
         service.

      *  VNF Dependencies: This describes dependencies between VNFs.
         For example, the order in which the VNFs inside a network
         service should be started.

      *  Network service Connection Points: Each network service has one
         or more external connection points (which act as endpoints)
         used to link two network services or to link external networks.

      *  Virtual Links: List of Virtual Link Descriptors (VLDs) that
         describe how VNFs (in the NSD) are connected.

   o  High level objects in a VNFD include (among others)
      [ETSI-NFV-MAN001][OSM-DM]:

      *  Constituent VDUs: List of virtual deployment units (VDUs) in a
         specific VNF.  Each VDU (also referred to VFC) describes the
         VM/Container capabilities (e.g., CPU, RAM, disks).

      *  VDU Dependencies: List of VDU dependencies used for determining
         the order of startup for VDUs.

      *  VNF Connection Points: List of external connection points used
         for connecting a VNF to other VNFs or to external networks.

      *  Internal VLDs: List of internal virtual links to connect
         various VDUs/VFCs.







Lachos & Rothenberg    Expires September 12, 2019              [Page 11]


Internet-Draft             Multi-domain E2E NS                March 2019


6.  IANA Considerations

   This document includes no request to IANA.

7.  Security Considerations

   TBD.

8.  Acknowledgments

   This work is supported by the Innovation Center of Ericsson S.A.,
   Brazil (grant agreement UNI.64).  This document however does not
   necessary represent Ericsson's official viewpoint.

9.  References

9.1.  Normative References

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

   [RFC8459]  Dolson, D., Homma, S., Lopez, D., and M. Boucadair,
              "Hierarchical Service Function Chaining (hSFC)", RFC 8459,
              DOI 10.17487/RFC8459, September 2018,
              <https://www.rfc-editor.org/info/rfc8459>.

9.2.  Informative References

   [DRAFT-ALTO-BROKER-MDO]
              Perez, D. and C. Rothenberg, "ALTO-based Broker-assisted
              Multi-domain Orchestration", draft-lachosrothenberg-alto-
              brokermdo-02 (work in progress), March 2018.

   [DRAFT-ALTO-UNICORN]
              Xiang, Q., Le, F., Yang, Y., Newman, H., and d.
              duhaizhou@gmail.com, "Unicorn: Resource Orchestration for
              Multi-Domain, Geo-Distributed Data Analytics", draft-
              xiang-alto-multidomain-analytics-01 (work in progress),
              March 2018.

   [DRAFT-HH-MDSFC]
              Li, G., Li, G., Li, T., Xu, Q., and H. Zhou, "Hybrid
              Hierarchical Multi-Domain Service Function chaining",
              draft-li-sfc-hhsfc-04 (work in progress), April 2018.





Lachos & Rothenberg    Expires September 12, 2019              [Page 12]


Internet-Draft             Multi-domain E2E NS                March 2019


   [DRAFT-MD-SFC-ALTO]
              Perez, D., Xiang, Q., Rothenberg, C., and Y. Yang, "Multi-
              domain Service Function Chaining with ALTO", draft-lachos-
              multi-domain-sfc-alto-00 (work in progress), July 2018.

   [DRAFT-MD-VIRT]
              Bernardos, C., Contreras, L., Vaishnavi, I., Szabo, R.,
              Li, X., Paolucci, F., Sgambelluri, A., Martini, B.,
              Valcarenghi, L., Landi, G., Andrushko, D., and A. Mourad,
              "Multi-domain Network Virtualization", draft-bernardos-
              nfvrg-multidomain-05 (work in progress), September 2018.

   [ETSI-NFV-IFA028]
              ETSI, "Report on architecture options to support multiple
              administrative domains V3.1.1", Jan 2018,
              <http://www.etsi.org/deliver/etsi_gr/NFV-
              IFA/001_099/028/03.01.01_60/gr_NFV-IFA028v030101p.pdf>.

   [ETSI-NFV-MAN001]
              ETSI, "Network Functions Virtualisation (NFV); Management
              and Orchestration", Dec 2014,
              <https://www.etsi.org/deliver/etsi_gs/NFV-
              MAN/001_099/001/01.01.01_60/gs_nfv-man001v010101p.pdf>.

   [ETSI-NFV-WHITEPAPER]
              ETSI, "Network Functions Virtualisation - White Paper 2",
              Oct 2013,
              <https://portal.etsi.org/NFV/NFV_White_Paper2.pdf>.

   [H2020-5G-NORMA]
              H2020, "5G-NORMA -- 5G Novel Radio Multiservice adaptive
              network Architecture", 2015, <https://5gnorma.5g-ppp.eu/>.

   [H2020-5G-TRANSFORMER]
              H2020, "5G-Transformer -- 5G Mobile Transport Platform for
              Vertical", 2017, <http://5g-transformer.eu/>.

   [H2020-NECOS]
              H2020 EU-Brazil, "NECOS -- Novel Enablers for Cloud
              Slicing", 2018, <http://www.h2020-necos.eu/>.

   [H2020.5GEX]
              Bernardos, C., Dugeon, O., Galis, A., Morris, D., Simon,
              C., and R. Szabo, "5G Exchange (5GEx)-- Multi-domain
              Orchestration for Software Defined Infrastructures",
              focus vol. 4, no.5, p.2, 2015.





Lachos & Rothenberg    Expires September 12, 2019              [Page 13]


Internet-Draft             Multi-domain E2E NS                March 2019


   [MEF-SOE-MEF55]
              Metro Ethernet Forum, "Lifecycle Service Orchestration
              (LSO): Reference Architecture and Framework", Mar 2016,
              <https://www.mef.net/Assets/Technical_Specifications/PDF/
              MEF_55.pdf>.

   [OSM-DM]   Open Source MANO, "OSM - Data Model", 2016,
              <https://osm.etsi.org/wikipub/index.php/
              Release_0_Data_Model_Details>.

   [SFC-ORC]  Sun, G., Li, Y., Liao, D., and V. Chang, "Service Function
              Chain Orchestration across Multiple domains: A Full Mesh
              Aggregation Approach", IEEE Transactions on Network and
              Service Management 1175--1191, 2018.

   [T-NOVA]   FP7 project T-NOVA, "T-NOVA Project, Network Functions as
              a Service over Virtualised Infrastructures", 2014,
              <http://www.t-nova.eu/>.

   [VITAL]    VITAL PROJECT H2020, "VITAL -- VIrtualized hybrid
              satellite-TerrestriAl systems for resilient and fLexible
              future networks", 2015, <http://www.ict-vital.eu/>.

   [VNF-MOB]  Patel, A., Vutukuru, M., and D. Krishnaswamy, "Mobility-
              aware VNF placement in the LTE EPC", IEEE Conference on
              Network Function Virtualization and Software Defined
              Networks (NFV-SDN) 1--7, 2017.

   [VNF-PLAC]
              Slim, F., Guillemin, F., Gravey, A., and Y. Hadjadj-Aoul,
              "Towards a dynamic adaptive placement of virtual network
              functions under ONAP", IEEE Conference on Network Function
              Virtualization and Software Defined Networks (NFV-SDN)
              210--215, 2017.

   [WHITE-PAPER-5G]
              NetWorld2020, ETP, "5g: Challenges, research priorities,
              and recommendations", Journal: Joint White Paper
              September, 2014.

Authors' Addresses










Lachos & Rothenberg    Expires September 12, 2019              [Page 14]


Internet-Draft             Multi-domain E2E NS                March 2019


   Danny Alex Lachos Perez
   University of Campinas
   Av. Albert Einstein 400
   Campinas, Sao Paulo  13083-970
   Brazil

   Email: dlachosp@dca.fee.unicamp.br
   URI:   https://intrig.dca.fee.unicamp.br/danny-lachos/


   Christian Esteve Rothenberg
   University of Campinas
   Av. Albert Einstein 400
   Campinas, Sao Paulo  13083-970
   Brazil

   Email: chesteve@dca.fee.unicamp.br
   URI:   https://intrig.dca.fee.unicamp.br/christian/

































Lachos & Rothenberg    Expires September 12, 2019              [Page 15]


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