Upload
ofer-ben-yaacov
View
60
Download
0
Embed Size (px)
Citation preview
www.huawei.com
Security Level:
HUAWEI TECHNOLOGIES CO., LTD.
TCaaS
Traffic Control as a Service
Author/ Email: Ofer Ben-Yacov
Version: V1.0(20160915)
Requirements Overview
Public Cloud Private CloudWAN 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
Hybrid Cloud Inter-Connectivity
Public Cloud Private Cloud
VPN/MPLS
L2GWL2GW
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
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
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
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 CloudService 1 Service 2 Service 3
No Services
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
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
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
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)
Compute Node
OVS
SFC with Dragonflow
VM21Service
Container
(Docker)
DF
Controller
Table0 Table1 Table2
Compute Node
Service
Container
(Docker)VM11 VM12
OVSDF
Controller
Table0 Table1 Table2output:
port-tc-svc
port-tc-svc port-tc-svc
output:
port-tc-svc
Rate
Limit
Flow-based
Service
Injection
VM31
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
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
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
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
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 4Direct, no service used VxLAN
chain1
chain1
chain2 chain2 chain2
VxLAN
VxLANMPLS
MPLS
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
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 (!!!)
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
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
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
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