Bug 1042609

Summary: [RFE][neutron]: Require support for provider:network_type gtp for supporting mobile netwok
Product: Red Hat OpenStack Reporter: RHOS Integration <rhos-integ>
Component: RFEsAssignee: RHOS Maint <rhos-maint>
Status: CLOSED UPSTREAM QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: markmc, yeylon
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
URL: https://blueprints.launchpad.net/neutron/+spec/provider-network.type-gtp
Whiteboard: upstream_milestone_none upstream_status_unknown upstream_definition_obsolete
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-19 16:56:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description RHOS Integration 2013-12-13 00:29:43 UTC
Cloned from launchpad blueprint https://blueprints.launchpad.net/neutron/+spec/provider-network.type-gtp.

Description:

The GRE tunneling is good start, but the 32 bit Tunnel ID (TEID) used for GPRS Tunneling Protocol (GTP) used in mobile network is entirely different. Refer to GPRS Tunneling Protocol wiki in specification URL.
GTP network - A virtual network realized as network packets encapsulated using GTP.  GTP networks are also referred to as "GTP tunnels". GTP tunnel packets are routed by the host's IP routing table, so GTP networks are not associated by OpenStack Networking with specific physical networks.
They are similar to GRE Tunnels in terms of using 32 bit Tunnel ID, but their realization requires implementation of GTPv1-C  for GPRS/UMTS and GTPv2-C for LTE control plane signalling   and GTP-U for  all types of cellular data plane traffic.

Idea here is to take ovsplugin code under  ... /quantum/plugins/openvswitch and modify the codes under  constatnts.py and add the new netwok_type gtp.

# Values for network_type
TYPE_FLAT = 'flat'
TYPE_VLAN = 'vlan'
TYPE_GRE = 'gre'
TYPE_GTP='gtp' # this we will addto constants.py under common... /quantum-2013.2.b1/quantum/plugins/openvswitch/common
TYPE_LOCAL = 'local'
TYPE_NONE = 'none'

Once that is done then the issue comes to what will plugin code and agent code to change to implement the following use case.

.........................................      ....................................................
| KVM1                             |     | KVM2                                         |
I  VM11    VM12      ...      |    |    VM21 VM22 ...                       |
|........................................|     |....................................................|

Use case 1:
eg. VM11 and VM12 on same KVM1 have ip of p.q.r.s and p.q.r.t  and the TEID field whihh gre uses can be used in case the network_type is 'gtp' instead of 'gre'

Use case 2:
e.g. VM11 and  VM22 are say the endpoints is question with ip address
p.q.r.s and w.x.y.z and the OVS plugin and agents are smart enough to go across hypervisors assuming each hypervisor (KVM?) has the corresponding ovsplugin installed and configured with support for  gtp-u tunnels.

What should KVM1 & KVM2 support?
I am assuming that iptables configuration will take care of UDP ports assignments at KVM level for required bindings for GTP-U. If i requires any other changes in kernel or VM will need further analysis and change in design. Since the calls between PLUGINS and AGENT is RPC based on Topic Exchange, the cross module interaction will be addressed to changes to other modules to support 'gtp' very much like 'gre'

Specification URL (additional information):

http://en.wikipedia.org/wiki/GPRS_Tunnelling_Protocol