Add traffic control service to Neutron SFC

1. www.huawei.com
Security Level:
HUAWEI TECHNOLOGIES CO., LTD.
TCaaS
Traffic Control as a Service
Author/ Email: Ofer Ben-Yacov
Version: V1.0(20160915)

2.  Requirements Overview
 Suggested Solution
 Use cases
 Implementation
Agenda

3. Requirements Overview
Public Cloud Private Cloud
WAN Link
Project/ VM / Policy
Based QoS on WAN
• In Hybrid Cloud scenario, there is a need to do rate limit on the WAN traffic
• Different Projects can have different limits
• Traffic from/to different source/destination within a Project can have different
limit
• Logical groups of VMs can be created (e.g. department) and be configured with
different limits
• Hierarchical limitation support
• Limit Project to X
• Limit VM/Group of VMs in that Project to Y with Y < X

4. Hybrid Cloud Inter-Connectivity
Public Cloud Private Cloud
VPN/MPLS
L2GW
L2GW
VPN/MPLS
• Inter-Cloud connectivity can be with L2 or L3
• Different devices/software can be used
• L2GW for L2
• Software-based VPN (e.g. OpenSWAN) for L3
• MPLS-VPN for L2/L3

5. Current QoS Solution
 Traffic Control is used for
 Rate limiting
 Traffic shaping
 Priority Management
 OpenStack current solution
 Rate limit and Traffic Shaping (QoS) on Neutron port
 Can set QoS on network but implementation is done on the port upon
creation
 Currently there is no solution for
 QoS using classifier
 Logical VM groups (e.g. departments) TC
 Example: giving finance department priority over R&D

6. Current QoS Solution
OVS
CN
C-VM
OVS
CN
S-VM
OVS
CN
C-VM
OVS
CN
C-VM
• QoS on server / client port
• No way to distinguish
between clients at the
server
VxLAN
C-VM Client VM
S-VM Server VM
TCA TC Agent
C-VM
Client-Server Traffic

7. Suggested Solution
Dragonflow-SFC

8. What is SFC?
 SFC let the admin/tenant set a chain of network services such as Traffic
Control / Firewall / Load Balancer
 Use policy (classifier) to select specific traffic to be sent through the chain
 Other traffic uses networks rules
Public Cloud Private Cloud
Service 1 Service 2 Service 3
No Services

9. Why SFC?
 In multi-path links there is a problem limiting traffic
 Traffic that belong to the same Project can take different path
 We need to have a central enforcement point to do the limiting
Public Cloud Private Cloud
Need to limit the sum of
traffic traversing the 2 links

10. Why SFC?
 SFC decuples the service (e.g. TC) from the different
 Devices
 Protocols
 Link types
 SFC withstands future changes to the above
 No need to implement TC for every Device / Technology
Public Cloud Private Cloud

11. Why SFC?
 SFC can be used to chain other services such as
 Firewall
 Load Balancer
 Different chains can include different services
 Different policy can be set to send traffic to different chains
Public Cloud Private CloudTC LB FW

12. Implementation

13. SFC with Dragonflow
 Add SFC application to Dragonflow
 Use Openflow flows to implement services if possible
 Rate limit and traffic shaping are supported by Openflow and OVS
 Add local container to run the service
 In case traffic will need to be routed between Compute Node
use tunnel protocol such as MPLS and later NSH (when it will
be supported by OVS)

14. Compute Node
OVS
SFC with Dragonflow
VM21
Service
Container
(Docker)
DF
Controller
Table0 Table1 Table2
Compute Node
Service
Container
(Docker)
VM11 VM12
OVS
DF
Controller
Table0 Table1 Table2
output:
port-tc-svc
port-tc-svc port-tc-svc
output:
port-tc-svc
Rate
Limit
Flow-based
Service
Injection
VM31

15. Use Cases

16. L2 Traffic
OVS
TCA
CN
C-VM
L2GW
OVS
CN
C-VM
OVS
CN
C-VM
VxLAN
C-VM Client VM
S-VM Server VM
TCA TC Agent
C-VM
Client-Server Traffic
Remote Cloud
Server
L2GW

17. L3 Traffic
OVS
TCA
CN
C-VM
OVS
NN
OVS
CN
C-VM
OVS
CN
C-VM
VxLAN
MPLS
C-VM Client VM
S-VM Server VM
TCA TC Agent
C-VM
Client-Server Traffic
Server
Remote Cloud
Ext Router / VPN

18. Multi-Path
OVS
TCA
CN
C-VM
OVS
CN
C-VM
OVS
CN
C-VM
VxLAN
MPLS
C-VM Client VM
S-VM Server VM
TCA TC Agent
C-VM
Client-Server Traffic
TCA
TCA
L2GW
Remote Cloud
Server
L2GW
L2GW L2GW

19. Intra-Cloud Traffic
OVS
TCA
CN
C-VM
OVS
CN
S-VM
OVS
CN
C-VM
OVS
CN
C-VM
VxLAN
MPLS
C-VM Client VM
S-VM Server VM
TCA TC Agent
C-VM
Client-Server Traffic
SFC can work for local traffic also
TCA
TCA
S-VM

20. Alternative Solutions

21. Networking-SFC
 Use for XaaS that need to be inserted between source and target
 Currently Support:
 LBaaS
 FWaaS
 Traffic is routed between multiple services using MPLS
Source
Target 1
FWaaS Target 2LBaaS
Target 3
Target 4
Direct, no service used VxLAN
chain1
chain1
chain2 chain2 chain2
VxLAN
VxLANMPLS
MPLS

22. Networking-SFC
 Single chain can have multiple instances to be used for
 service load balancing
 High Availability
Target 1
FWaaS
Target 2
LBaaS
VxLAN
MPLS
MPLS
FWaaS LBaaSSource 2
Source 1 MPLS

23. Network-SFC
 Cons
 Low level – require significant knowledge in Neutron
 Currently supports only
 LBaaS
 FWaaS
 No way easy way to introduce new services
 Security Groups disabled (!!!)

24. GBP (Group Based Policy)
 Intent driven model to describe network / security requirement
 Independent from underplaying infrastructure
 Run as Neutron service plugin
 Create rule based service chain

25. Network Function Plugin (NFP)
 Framework in GBP project to handle lifecycle management of network services
that includes creation, deployment, management and resource pooling,
monitoring capabilities of network services.
 BYOF – Bring You Own Function
 Allows any service developed independently to be easily incorporated into the
Service Chain
 https://github.com/openstack/group-based-policy-
specs/blob/master/specs/mitaka/gbp-network-function-plugin-framework.rst

26. GBP
 Pros
 Easy to introduce new services through NFP
 Can be used by users with no network knowledge
 Cons
 Cisco owned. Will be hard to modify.
 Service must be VM instance
 No provider / tenant access control separation

27. Conclusion
 Service Function Chaining (SFC) in Dragonflow
 Cons
 Need to develop from scratch
 Pros
 Already distributed
 DB already included
 Security Groups implemented
 No need for VM
– Flow based services
 High collaboration with Dragonflow
– The feature is wanted
– Huawei interest to improve Dragonflow

28. Thank You