Service Function Chaining (SFC) uses software-defined networking (SDN) capabilities to create a service chain of connected network services (such as L4-7 like firewalls, network address translation [NAT], intrusion protection) and connect them in a virtual chain. This capability can be used by network operators to set up suites or catalogs of connected services that enable the use of a single network connection for many services, with different characteristics. networking-sfc is a service plugin of Openstack neutron. The talk will go over the architecture, implementation, use-cases and latest enhancements to networking-sfc (the APIs and implementation to support service function chaining in neutron). About the speaker: Farhad Sunavala is currently a principal architect/engineer working on Network Virtualization, Cloud service, and SDN technologies at Huawei Technology USA. He has led several wireless projects in Huawei including virtual EPC, service function chaining, etc. Prior to Huawei, he worked 17 years at Cisco. Farhad received his MS in Electrical and Computer Engineering from University of New Hampshire. His expertise includes L2/L3/L4 networking, Network Virtualization, SDN, Cloud Computing, and mobile wireless networks. He holds several patents in platforms, virtualization, wireless, service-chaining and cloud computing. Farhad was a core member of networking-sfc.

1. Security Level:
Service Function Chaining in
Openstack Neutron
Farhad Sunavala
Principal Engineer, Huawei

2. 2
Agenda
1. Service Chaining – What, why, use cases, architecture, etc.
2. Openstack Neutron networking-sfc
• Architecture
• Configuration Model
• CLI
• Flows
• Use Cases
• Related projects
• Final Thoughts
3. Q & A

3. 3
Service Chain
What ?
All SFC documents - https://datatracker.ietf.org/wg/sfc/documents/
Problem Statement for Service Function Chaining - https://datatracker.ietf.org/doc/rfc7498/

4. 4
Service Chain
Why ? (Use Cases)
https://datatracker.ietf.org/wg/sfc/documents/
Mobile Networks, Mobile Network Gi LAN, Fixed Broadband, Data Centers, vCPE (E.g. ATT’s uCPE -
Universal Customer Premises Equipment)

5. 5
SFC – Traditional Way using PNFs (HW Boxes)
SFC – Subscriber Based SFC using VNFs

6. 6
SFC Architecture
RFC 7665

7. 7
Openstack Neutron networking-sfc
Documentation
https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining
https://docs.openstack.org/networking-sfc/latest/
Initial release
First stable release, bug fixes, minor API changes,
sfc commands changed to openstackclient, symmetric chain parameter in
API, OVS SFC agent as L2 agent extension,
symmetric port-chains, port-pair support for correlation=mpls

8. 8
Openstack Neutron SFC Architecture

9. 9
Service Chain Configuration Model

10. 10
Service Chain Objects

11. 11
Service Chain CLI
port pair (ingress and egress neutron ports of VNF)
openstack sfc port pair create –ingress <ingress> --egress <egress> <pp1-name>
openstack sfc port pair create –ingress >ingress> --egress <egress> <pp2-name>
port pair group (load-balancer for like VNFs)
openstack sfc port pair group create –port-pair <pp1-name> --port-pair <pp2-name> <ppg-name>
flow classifier (classifier details)
openstack sfc flow classifier create –source-ip-prefix <source-ip-prefix> --destination-ip-prefix <destination-ip-prefix> <fc-name>
port chain
openstack sfc port chain create –flow-classifier <fc-name> --port-pair-group <ppg-name> <pc-name>
port-pair consists of neutron port for ingress and egress.
Hence, any entity (Virtual or Physical) which can be described by a neutron port, can be easily inserted or
removed from the service chain.

12. 12
networking-sfc Flows
src
sf
sf2
dst
10.0.0.310.0.0.4
10.0.0.10
10.0.0.6
root@fs-10-145-105-66:~/configs# ovs-ofctl dump-flows -O OpenFlow13 br-int table=0
cookie=0xb524b28024063844, duration=10.116s, table=0, n_packets=0, n_bytes=0, priority=30,icmp,in_port=8,nw_src=10.0.0.4,nw_dst=10.0.0.3 actions=group:1
Classify
Loadbalance
root@fs-10-145-105-66:~/configs# ovs-ofctl dump-groups -O OpenFlow13 br-int
group_id=1,type=select,bucket=actions=set_field:fa:16:3e:75:cb:ad->eth_dst,resubmit(,5),bucket=actions=set_field:fa:16:3e:07:f3:5f->eth_dst,resubmit(,5)
Tag
root@fs-10-145-105-66:~/configs# ovs-ofctl dump-flows -O OpenFlow13 br-int table=5
cookie=0xb524b28024063844, duration=781.070s, table=5, n_packets=0, n_bytes=0, priority=0,ip,dl_dst=fa:16:3e:75:cb:ad actions=push_mpls:0x8847,
set_field:511->mpls_label,set_mpls_ttl(255),push_vlan:0x8100,set_field:4097->vlan_vid,resubmit(,10)
cookie=0xb524b28024063844, duration=781.065s, table=5, n_packets=0, n_bytes=0, priority=0,ip,dl_dst=fa:16:3e:07:f3:5f actions=push_mpls:0x8847,
set_field:511->mpls_label,set_mpls_ttl(255),push_vlan:0x8100,set_field:4097->vlan_vid,resubmit(,10)

13. 13
Use cases - networking-sfc
Simplest case - Same tenant
src1
VNF11
VNF13
VNF12
VNF21
VNF22
VNF31
VNF32
VNF34
VNF33
dst
classify +
loadbalance +
tag
untag +
classify +
loadbalance +
tag
untag +
Normal
forwarding
src2
untag +
classify +
loadbalance +
tag

14. 14
Use cases - networking-sfc
Different tenants –no problem, use RBACs (role based access control)
src1
VNF11
VNF13
VNF12
VNF21
VNF22
VNF31
VNF32
VNF34
VNF33
dst
Classification +
loadbalancing
Classification +
loadbalancing
Classification +
loadbalancing
Normal
forwarding
src2
Shared network

15. 15
Use cases - networking-sfc
VNF containers - No problem, use kuryr
src1
VNF11
VNF13
VNF12
VNF21
VNF22
VNF31
VNF32
VNF34
VNF33
dst
Classification +
loadbalancing
Classification +
loadbalancing
Classification +
loadbalancing
Normal
forwarding
src2
Containers orchestrated by Docker Swarm / k8s,
networked using kuryr

16. 16
Use cases - networking-sfc
Nested containers in a VM – no problem, use VLAN aware VMs
br-tun br-tun
VM2
patch-int
patch-tun
br-trunk
Bridge
C1
10.0.0.9/24
C2
10.0.0.3/24
C3
10.0.1.4/24
vl100 vl200 vl300
trunk
Vl100,vl200,vl300
vl1
10.0.0.100/2410.0.0.4
vl1
vl100
vl200
vl300
vl1
vl1
vl1
vl4
br-int br-int
patch-tun
patch-int
VM3
10.0.0.101/24
vl1
vl1
vl1
vl4

17. 17
Use cases - networking-sfc
Multiple Openstack implementations / site licensing – no problem, use Openstack TriCircle
https://wiki.openstack.org/wiki/Tricircle

18. 18
Use cases - networking-sfc
Use neutron provided services like FWaaS, LBaaS, VPNaaS as VNFs in the service chain.
Integrate PNFs (Physical Network Functions) with VNFs as part of a service chain using L2GW.
Support for Service Graphs branching and reclassification.

19. 19
networking-sfc related projects
1. ONOS SDN Controller with networking-sfc integration
https://wiki.onosproject.org/pages/viewpage.action?pageId=4163192
https://docs.openstack.org/networking-onos/latest/devref/sfc_driver.html
2. ODL SDN Controller with networking-sfc integration
https://wiki.opendaylight.org/images/3/37/OpenDaylight-Summit-2016-OpenStack-SFC-Support.pdf
https://docs.openstack.org/networking-odl/ocata/specs/sfc-driver.html
3. Networking-sfc / OVN Driver
https://docs.openstack.org/networking-sfc/latest/contributor/sfc_ovn_driver.html
https://www.youtube.com/watch?v=PUZzhRxc6iA
4. Tacker with networking-sfc integration.
https://specs.openstack.org/openstack/tacker-specs/specs/newton/tacker-networking-sfc.html

20. 20
Final thoughts
networking-sfc uses MPLS tags for chaining due to lack of NSH support in openvswitch.
Openvswitch 2.8.0 (released August 31st 2017) has experimental NSH support.
http://openvswitch.org/releases/NEWS-2.8.0
• Experimental NSH (Network Service Header) support in userspace datapath.
• Used generic encap and decap actions to implement encapsulation and decapsulation of NSH header.
• IETF NSH draft - https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/
As networking-sfc and releated projects provide full NSH support now,
support for service-aware functions will hopefully become more commonplace.

21. 21
Questions
???

22. Copyright©2016 Huawei Technologies Co., Ltd. All Rights Reserved.
The information in this document may contain predictive statements including, without
limitation, statements regarding the future financial and operating results, future product
portfolio, new technology, etc. There are a number of factors that could cause actual
results and developments to differ materially from those expressed or implied in the
predictive statements. Therefore, such information is provided for reference purpose
only and constitutes neither an offer nor an acceptance. Huawei may change the
information at any time without notice.
Thank You.