Release1/network_types_in_RO.md

   1 # Network types in RO #
   2
   3 ## Proposer ##
   4 - Gerardo García (Telefónica)
   5 - Alfonso Tierno (Telefónica)
   6
   7 ## Type ##
   8 **Requirement**
   9
  10 ## Target MDG/TF ##
  11 RO
  12
  13 ## Description ##
  14 Current network types in RO describe the actual enforcement done in the host bridges/switches and
  15 in the physical switches. This feature suggests changing the network types in RO functions and
  16 databases to describe, instead of the actual enforcement, the functional behaviour.
  17
  18 Today network types in RO are:
  19
  20 - ptp, for point-to-point networks (E-Line) enforced in an underlay switching infrastructure. VM
  21 interfaces must be either port passthrough or SR-IOV.
  22 - data, for L2 networks (E-LAN) enforced in an underlay switching infrastructure. VM interfaces
  23 must be data plane interfaces (either port passthrough or SRIOV).
  24 - bridge, for L2 networks (E-LAN) enforced in a Linux Bridge or OVS-based virtual switch. VM
  25 interfaces are based on virtio interfaces.
  26
  27 New network types would be:
  28
  29 - "E-Line", for E-Line networks, independently on the kind of enforcement in place. E-Line networks
  30 are L2 point-to-point networks which meet that whatever frames come from a network port goes to the
  31 other network port, and viceversa, no matter the MAC addresses behind.
  32 - "E-LAN", for E-LAN networks, independently on the kind of enforcement in place.E-LAN networks are
  33 L2 point-to-multipoint networks where the destination network port is determined by the destination
  34 MAC address.
  35
  36 Both kinds of networks would have a parameter related to the type of enforcement (e.g. virtual
  37 networks or underlay) that could be specified by the NS builder or by the VNF builder to make the
  38 enforcement explicit. If specified, the specific network configuration will be done either via
  39 virtual networks (Linux bridges or virtual switches, depending on the technology used by VIM) or
  40 via underlay switching infrastructure. If unspecified, the enforcement will depend on the actual
  41 interfaces being connnected. For the moment, with the current state of the art in VIMs, it is
  42 assumed that:
  43
  44 - An E-Line network cannot connect VM interfaces based on virtio, but can only connect data plane
  45 interfaces (port passthorugh or SRIOV).
  46 - An E-LAN network can only connect VM interfaces of the same type: either virtio interfaces or
  47 dataplane interfaces.
  48
  49 As an example, if 3 virtio-based VM interfaces are connected in an NS or VNF to an E-LAN network,
  50 the enforcement will be done via virtual networks based on Linux bridges or OVS, depending on the
  51 specific technology used by the VIM, but they won't be connected via the underlay switching. On the
  52 other hand, if 2 virtio-based VM interfaces and 1 SRIOV are intended to be connected in an NS, this
  53 will be rejected by the RO at instantiation time. This behaviour could be changed in the future if
  54 the state of the art in VIMs evolve.
  55
  56 In addition, E-LAN networks can have extra parameters to be passed to the VIM during network
  57 creation such as L3 configuration parameters (e.g. DHCP enabling, DHCP range, FW enabling, FW rules
  58 to be applied, IPv4 subnet and mask, etc.). The internal data structures in RO should allow room
  59 for potential addition of new parameters, but the specification of these extra parameters is out of
  60 the scope of this feature request.
  61
  62 The following changes are devised in RO:
  63
  64 - openmano\_schemas.py: changes in schemas to support the new types of networks and their
  65 parameters.
  66 - nfvo.py: changes in all functions where actions are taken over networks (network creation in the
  67 context of a VNF or an NS, network deployment in VIM, read network information, etc.).
  68 - MySQL DB: changes in tables related to networks at VNF or NS level.
  69 - nfvo\_db: changes in functions to update the DB tables accordingly.
  70 - http\_server.py: changes in REST methods dealing with networks (Create, Read and Update
  71 operations) to take into account the changes in schemas, nfvo functions and nfvo_db functions.
  72
  73 Further investigation will be required to measure precisely the implications in code development.
  74
  75 Changes in RO will affect its north-bound interface, thus implying changes in SO and also
  76 potentially in the data models for VNF and NS. If this feature is accepted, additional requirements
  77 and specs might be required in the SO to guarantee interoperability between RO and SO.
  78
  79 ## Demo or definition of done ##
  80 The following tests are suggested:
  81 - Success test for an NS deployment with single-VM VNFs. The NS will have at least 2 VNFs connected
  82 with E-LAN and E-Line networks.
  83 - Success test for an NS deployment with a multi-VM VNF. The multi-VM VNF will have at least 2 VMs
  84 connected with E-LAN and E-Line networks.
  85 - Failure test for an NS deployment with single-VM VNFs. The NS will have at least 2 VNFs connected
  86 with E-LAN and E-Line networks. The type of interfaces connected to the E-LAN or to the E-Line
  87 networks will lead to a failure.
  88 - Failure test for an NS deployment with a multi-VM VNF. The multi-VM VNF will have at least 2 VMs
  89 connected with E-LAN and E-Line networks. The type of interfaces connected to the E-LAN or to the E-Line networks will lead to a failure.
  90