Require support for provider:network_type gtp for supporting mobile netwok
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/
# 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-
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'
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- Prakash Ramchandran
- Direction:
- Needs approval
- Assignee:
- Prakash Ramchandran
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
- Armando Migliaccio
Whiteboard
Only the openvswitch plugin currently supports GRE networks, provided that the host's Linux kernel supports the required Open vSwitch features. The proposal here is to modify openvswitch plugin to support a new provider:
yong sheng gong: can u give us an arch about how to use openstack (nova, quantum) in this env?
Currently the plan is to limit this to GTP-U or data-plane implementation only. Having said that the idea is to simply allow few simple commands like create, update, delete , list / show, transport the packets through gtp-u tunnels.
The likely attributes a gtp-u tunnel will have are:
- source IP address
- source GTPu tunnel id
- destination IP address
- destination GTPu tunnel id
Since this will be part of Havana release we would add this to quantum network APIs and Nova compute will need corresponding additions to support the API calls as part of Network calls.
This are very early comments. Still question remains if we do part of plumbing at user level lib and part at kernel level and will have to check into Linux versions currently used for support on library fronts for firewall.
If you have any suggestions please feel free to participate in this Blueprint to support what makes sense for your organization and this is a community efforts, so most welcome to join the debate and discussions to get the blueprint right.
