From: garciadeblas Date: Tue, 14 Jun 2016 21:54:35 +0000 (+0200) Subject: Network types in RO X-Git-Url: https://osm.etsi.org/gitweb/?p=osm%2FFeatures.git;a=commitdiff_plain;h=dd60020ecf39b52836c59f35fac00aad889da2ba Network types in RO Signed-off-by: garciadeblas --- diff --git a/Release1/network_types_in_RO.md b/Release1/network_types_in_RO.md new file mode 100644 index 0000000..ea008ec --- /dev/null +++ b/Release1/network_types_in_RO.md @@ -0,0 +1,90 @@ +# Network types in RO # + +## Proposer ## +- Gerardo García (Telefónica) +- Alfonso Tierno (Telefónica) + +## Type ## +**Requirement** + +## Target MDG/TF ## +RO + +## Description ## +Current network types in RO describe the actual enforcement done in the host bridges/switches and +in the physical switches. This feature suggests changing the network types in RO functions and +databases to describe, instead of the actual enforcement, the functional behaviour. + +Today network types in RO are: + +- ptp, for point-to-point networks (E-Line) enforced in an underlay switching infrastructure. VM +interfaces must be either port passthrough or SR-IOV. +- data, for L2 networks (E-LAN) enforced in an underlay switching infrastructure. VM interfaces +must be data plane interfaces (either port passthrough or SRIOV). +- bridge, for L2 networks (E-LAN) enforced in a Linux Bridge or OVS-based virtual switch. VM +interfaces are based on virtio interfaces. + +New network types would be: + +- "E-Line", for E-Line networks, independently on the kind of enforcement in place. E-Line networks +are L2 point-to-point networks which meet that whatever frames come from a network port goes to the +other network port, and viceversa, no matter the MAC addresses behind. +- "E-LAN", for E-LAN networks, independently on the kind of enforcement in place.E-LAN networks are +L2 point-to-multipoint networks where the destination network port is determined by the destination +MAC address. + +Both kinds of networks would have a parameter related to the type of enforcement (e.g. virtual +networks or underlay) that could be specified by the NS builder or by the VNF builder to make the +enforcement explicit. If specified, the specific network configuration will be done either via +virtual networks (Linux bridges or virtual switches, depending on the technology used by VIM) or +via underlay switching infrastructure. If unspecified, the enforcement will depend on the actual +interfaces being connnected. For the moment, with the current state of the art in VIMs, it is +assumed that: + +- An E-Line network cannot connect VM interfaces based on virtio, but can only connect data plane +interfaces (port passthorugh or SRIOV). +- An E-LAN network can only connect VM interfaces of the same type: either virtio interfaces or +dataplane interfaces. + +As an example, if 3 virtio-based VM interfaces are connected in an NS or VNF to an E-LAN network, +the enforcement will be done via virtual networks based on Linux bridges or OVS, depending on the +specific technology used by the VIM, but they won't be connected via the underlay switching. On the +other hand, if 2 virtio-based VM interfaces and 1 SRIOV are intended to be connected in an NS, this +will be rejected by the RO at instantiation time. This behaviour could be changed in the future if +the state of the art in VIMs evolve. + +In addition, E-LAN networks can have extra parameters to be passed to the VIM during network +creation such as L3 configuration parameters (e.g. DHCP enabling, DHCP range, FW enabling, FW rules +to be applied, IPv4 subnet and mask, etc.). The internal data structures in RO should allow room +for potential addition of new parameters, but the specification of these extra parameters is out of +the scope of this feature request. + +The following changes are devised in RO: + +- openmano\_schemas.py: changes in schemas to support the new types of networks and their +parameters. +- nfvo.py: changes in all functions where actions are taken over networks (network creation in the +context of a VNF or an NS, network deployment in VIM, read network information, etc.). +- MySQL DB: changes in tables related to networks at VNF or NS level. +- nfvo\_db: changes in functions to update the DB tables accordingly. +- http\_server.py: changes in REST methods dealing with networks (Create, Read and Update +operations) to take into account the changes in schemas, nfvo functions and nfvo_db functions. + +Further investigation will be required to measure precisely the implications in code development. + +Changes in RO will affect its north-bound interface, thus implying changes in SO and also +potentially in the data models for VNF and NS. If this feature is accepted, additional requirements +and specs might be required in the SO to guarantee interoperability between RO and SO. + +## Demo or definition of done ## +The following tests are suggested: +- Success test for an NS deployment with single-VM VNFs. The NS will have at least 2 VNFs connected +with E-LAN and E-Line networks. +- Success test for an NS deployment with a multi-VM VNF. The multi-VM VNF will have at least 2 VMs +connected with E-LAN and E-Line networks. +- Failure test for an NS deployment with single-VM VNFs. The NS will have at least 2 VNFs 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. +- Failure test for an NS deployment with a multi-VM VNF. The multi-VM VNF will have at least 2 VMs +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. +