From cc8b3ec9eeb2f76c5fd4f6cc8ec5f480fabee098 Mon Sep 17 00:00:00 2001 From: ZhaoBo Date: Thu, 4 Jan 2018 13:00:20 +0800 Subject: [PATCH] Spec for VPN service support Qos This is the spec for the VPN Qos. Paritial-Bug: #1727578 Change-Id: I5f94b89d2e11734385b58e5e5edf55d149b9f38a Depends-On: If40305044c9dfe0024b64bd3921232bb0a6c9372 --- specs/rocky/vpn-services-support-qos.rst | 311 +++++++++++++++++++++++ 1 file changed, 311 insertions(+) create mode 100644 specs/rocky/vpn-services-support-qos.rst diff --git a/specs/rocky/vpn-services-support-qos.rst b/specs/rocky/vpn-services-support-qos.rst new file mode 100644 index 000000000..9483ca488 --- /dev/null +++ b/specs/rocky/vpn-services-support-qos.rst @@ -0,0 +1,311 @@ +.. + This work is licensed under a Creative Commons Attribution 3.0 Unported + License. + + http://creativecommons.org/licenses/by/3.0/legalcode + +======================== +VPN Services Support QoS +======================== + +https://bugs.launchpad.net/neutron/+bug/1727578 + +Currently, there is no way to set VPN services' bandwidth. This specification +proposed a way to set the VPN services' bandwidth limit. + + +Problem Description +=================== + +Currently, Neutron VPNaaS provides site to site VPN services, but its bandwidth +consumption is not regulated, as the VPN tunnel will cost the bandwidth from +the outside public bandwidth provided by the ISP or other organizations. That +means it is not free. The OpenStack provider or users should pay for the +limited bandwidth. So it is necessary for saving the resources. + +Currently, physical device configurations outside OpenStack environment cannot +be modified by OpenStack, but we can shape the outgoing traffic. VPN services +provide the security guarantee, but it shouldn't abuse the bandwidth of +underlay network that it will affects other traffic. + +Use Case +-------- + +Consider that an OpenStack public cloud has been deployed in a real data +center. A cloud enterprise user has a requirement in which one of the +applications should connect to its private network 20.0.0.0/24, but for other +traffic flows, still use the original network functionality provided by +OpenStack. The network topology diagram is shown below:: + + + + +--------------------+ + |DataCenter + |VM1 | | |external network + |nic IP: 10.0.0.11 | | +-------------------------------+ | +----+ + |default via 10.0.0.1+---+ |Default Router | | | | + | | +-----------------+Interface: 10.0.0.1 +------+ | | + +--------------------+ | |gw: 172.24.4.11 | | | | + OpenStack | |route: 20.0.0.0/24 via 10.0.0.5| | | | + private . | | | | | | + network . | +-------------------------------+ | | | + | | | | + subnet: 10.0.0.0/24 | | | | + +--------------------+ | | | | + |VM2 | | +--------+ |Internet + |nic IP: 10.0.0.12 | | | | | + |default via 10.0.0.1+---+ | | | + | | | | | | + +--------------------+ | | | | + | | | | + . | +--------------------------------+ | | | +-------------------------------+ + . | |VPN Router | | | | |Vendor GW Router | + | |Interface: 10.0.0.5 | | | | |peer vpn service running | + +-----------------+gw: 172.24.4.12 +-----+ | +-------+hold private subnet 20.0.0.0/24| + +--------------------+ | |VPN service running | | | | | | + |VMX | | | | | | | | | + |nic IP: 10.0.0.13 | | +--------------------------------+ | +----+ +-------------------------------+ + |default via 10.0.0.1+---+ | + | | | | + +--------------------+ | | + | | + + + + +As this diagram shows, the enterprise user owned many VMs in the private +network and the allocated IPs are from the private subnet 10.0.0.0/24. There +are two routers connected, ``Default Router`` is used for the normal network +functions, such as NAT, Floating IP, Routing. ``VPN Router`` is mainly used for +VPN traffic process, also contains NAT and route for other traffic. Both of the +routers are attached to the external network which is the physical underlay +network in the real data center. The VPN Router in OpenStack and Vendor GW +Router in other site maintain a VPN peer relationship across the Internet. + +There are two scenarios towards the VM outgoing traffic: + +1. VMs in the OpenStack private network access the normal websites, first send + the network packets to its gateway which is located on the + ``Default Router``. Then send to the Internet by the data center devices. +2. VMs in the OpenStack private network access the other site private network + 20.0.0.0/24, still first send the network packets to its gateway 10.0.0.1, + then check the route tables, the nexthop of 20.0.0.0/24 is 10.0.0.5 which + is located on ``VPN Router``. The network traffic will be sent based on the + existing VPN tunnel to Vendor private site. + +Like the diagram shows, the QoS Policy should be set on the qg-XX port of the +VPN router for limiting the outgoing VPN traffic. + +This spec focuses on the QoS of VPN outgoing traffic, so for neutron-vpnaas, +this spec will focus on the Router related with VPN services. And for the +general use cases which is that VPN service usually setup across the Internet +in tunnel mode, we will only introduce the QoS support on tunnel type VPN +services. + + +Proposed Change +=============== + +We propose the ``VPN Service`` resource accepts the Neutron QoS Policy. Once +the ``ipsec site connection`` is created, the QoS Policy will be applied on the +VPN router's qg-XX port, as the ESP encapsulation will use the qg-XX port's IP +to access other sites. + +So there are three parts that require to work: + +1. DB related changes, including new table ``qos_vpnservice_policy_bindings`` + addition and data model change. +2. API changes, including extend the API to accept the Neutron QoS Policy. +3. Introduce a new l3 agent extension to extend the ability to process the QoS + policy installation on the router. + +Alternatives +------------ + +* Accept the QoS parameters and implement the QoS function on our own. +* Apply QoS Policy on the Router interface directly, but this would affect the + west-east traffic. + +Data model impact +----------------- +In this spec, the QoS data model and function will be provided by Neutron, so +``vpnservices`` table need to maintain the relationship with Neutron QoS +Policy. + +The following new table is added as part of the VPN QoS feature:: + + CREATE TABLE `qos_vpnservice_policy_bindings` ( + `vpn_service_id` varchar(36) NOT NULL, + `qos_policy_id` varchar(36) NOT NULL, + UNIQUE KEY `vpn_service_id` (`vpn_service_id`), + KEY `qos_policy_id` (`qos_policy_id`), + CONSTRAINT `qos_vpn_service_policy_bindings_ibfk_1` FOREIGN KEY ( + `qos_policy_id`) REFERENCES `qos_policies` (`id`) ON DELETE CASCADE, + CONSTRAINT `qos_vpn_service_policy_bindings_ibfk_2` FOREIGN KEY ( + `vpn_service_id`) REFERENCES `vpnservices` (`id`) ON DELETE CASCADE + ); + +REST API impact +--------------- + +Proposed attribute:: + + EXTEND_FIELDS = { + 'qos_policy_id':{'allow_post': True, 'allow_put': True, + 'validate': {'type:uuid': None}, + 'is_visible': True, + 'default': None} + } + + +Some samples in ``VPN service`` create/update. Users are allowed to pass +``qos_policy_id``. + +Create/Update ``VPN service`` Request:: + + POST /v2.0/vpn/vpnservices + { + "vpnservice": { + "subnet_id": null, + "qos_policy_id": "a36c20d0-18e9-42ce-88fd-82a35977ee8c", + "router_id": "66e3b16c-8ce5-40fb-bb49-ab6d8dc3f2aa", + "name": "myservice", + "admin_state_up": true + } + } + + Response: + { + "vpnservice": { + "router_id": "66e3b16c-8ce5-40fb-bb49-ab6d8dc3f2aa", + "status": "PENDING_CREATE", + "name": "myservice", + "external_v6_ip": "2001:db8::1", + "admin_state_up": true, + "subnet_id": null, + "project_id": "10039663455a446d8ba2cbb058b0f578", + "tenant_id": "10039663455a446d8ba2cbb058b0f578", + "external_v4_ip": "172.32.1.11", + "id": "5c561d9d-eaea-45f6-ae3e-08d1a7080828", + "description": "", + "qos_policy_id": "a36c20d0-18e9-42ce-88fd-82a35977ee8c" + } + } + + PUT /v2.0/vpn/vpnservices/{service_id} + { + "vpnservice": { + "name": "NEW VPN SERVICE NAME", + "description": "Updated description", + "qos_policy_id": "a36c20d0-18e9-42ce-88fd-82a35977ee8c" + } + } + + Response: + { + "vpnservice": { + "router_id": "881b7b30-4efb-407e-a162-5630a7af3595", + "status": "ACTIVE", + "name": "NEW VPN SERVICE NAME", + "admin_state_up": true, + "subnet_id": null, + "project_id": "26de9cd6cae94c8cb9f79d660d628e1f", + "tenant_id": "26de9cd6cae94c8cb9f79d660d628e1f", + "id": "41bfef97-af4e-4f6b-a5d3-4678859d2485", + "description": "Updated description", + "qos_policy_id": "a36c20d0-18e9-42ce-88fd-82a35977ee8c" + } + } + + +QoS Policy Application Details +------------------------------ + +The reason for introducing this, for example, we change the use case below, we +deploy the vpn service on the ``Default Router``, delete the ``VPN Router``. +That means the general traffic and VPN traffic will pass through the +``Default Router``, then we apply the Neutron QoS policy on the qg-XX port of +the ``Default Router``, it will limit all the bandwidth, so the VPN's bandwidth +may have a lower performance, or we can say it is not consistent with +expectations. + +Currently, Neutron provides the QoS function but not for some interest streams. +Here we will focus on the VPN traffic. For this function, we will combine +the ``iptables`` and ``tc`` together. The reason for choosing them is that, +``iptables`` could mark the VPN interest stream by the ipsec VPN transform +protocols(such as esp, ah-esp protocols), the interface that the packets +will go out and the local encapsulated IP if running in tunnel mode. Also we +need to shape the vpn traffic before send out to the underlay network, so some +new ``iptables`` rules will be installed on mangle table in the router's +namespace. Also the ``fwmark`` is eaiser to extend, such as ipchains. + +And we will introduce a new ``tc`` wrapper which will use ``htb`` and it will +provides classification algorithm. Then developers can easily implement other +complex traffic control. That means we will extend the current tc_lib in +Neutron repo. And ``vpn_qos`` will based on this. + +Just like above description, a new L3 agent extension will be introduced like +fip_qos done. We suggest to name it ``vip_qos``, it will install the +appropriate ``iptables`` rules in the router's namespace which binds with +``VPN service``. Then users or managers could use the QoS function to the +``Default Router`` and not affect other network streams. + + +Security impact +--------------- +None + +Notifications impact +-------------------- +No expected change. + +Other end user impact +--------------------- +Users will be able to specify qos_policy during create/update ``VPN service``. + +Performance Impact +------------------ +It will save the bandwidth of the underlay network in data center. + +Other deployer impact +--------------------- +None + +Developer impact +---------------- +Developer may use the new ``tc`` wrapper to do other things, as it is powerful +to support other stream control functionality. +But there may be a conflict with openstack/neutron-classifier, as it provides +defining the traffic. So we may reconsider that if possible. + +Implementation +============== + +Assignee(s) +----------- +zhaobo + +Work Items +---------- +* Add the DB model and extend the table column. +* Extend VPN API to accept QoS policy. +* Extend new tc wrapper which support classification algorithm based on + traffic classifier feature. +* Extend new L3 agent extension ``vip_qos``. +* Add API validation code to validate access/existence of the qos_policy which + created in Neutron. +* Add UTs to Neutron-vpnaas. +* Add API tests. +* Update CLI to accept QoS fields. +* Documentation work. + +Dependencies +============ +None + +Testing +======= +Unit tests, functional tests, API tests and scenario tests are necessary. + +Documentation Impact +==================== +The Neutron API reference will need to be updated. + +References +==========