1. Ready-to-Deploy Service Function Chaining for Mobile Networks
IEEE NetSoft‘16
Ready-to-Deploy Service Function Chaining for Mobile Networks
Roberto Bifulco, NEC Labs Europe
Anton Matsiuk, NEC Labs Europe
Alessio Silvestro, NEC Labs Europe

2. Network function deployment
Today: Change network topology
put the middlebox on path
Network
Function
However network functions are still deployed

3. Network Function Virtualization

4. Let’s chain all together
Dynamic on-demand composition
Service Function Chaining (SFC)
Network
Function
Network
Function
Network
Function
Network
Function

5. Classification Traffic Steering Challenges
Assign network flows to function chains
Scalability is the main issue
Traffic Steering
Move packets from one function to the next
Requires coordination of bi-directional flows
May require re-classification after a function has been applied

6. SFC in Standards SFC in Research Related work 1/2
RFC7498 Problem statement
RFC7665 Architecture
Network Service Header (NSH) …
SFC in Research
SIMPLE, SIGCOMM ‘13
FlowTags, NSDI ‘14
StEERING, ICNP ‘13
SoftCell, CoNext ’13

7. Unfulfilled Requirement:
Related work 2/2
Very good solutions!!
But…
Changes to the network hardware
Changes to the network functions
Changes to the network architecture
Unfulfilled Requirement:
a solution should introduce minimum impact on the legacy infrastructure

8. CATENAE
Ready-to-Deploy Service Function Chaining

9. Let’s change topic…

10. User traffic is carried in IP tunnels (GTP tunnels)
The case of SGi-LANs
User traffic is carried in IP tunnels (GTP tunnels)
Operator’s services are deployed in a L2 domain (SGi-LAN)
Network flows always start in the upstream direction
A NAT is always deployed
GTP
Tunnel
NAT

11. CATENAE architecture
No modifications
to the network

12. CATENAE’s classifier NAT No modifications to the network
Classifier scalability
NAT

13. Workaround IP routing Issues: In CATENAE: Traffic Steering
Tunneling is the straightforward solution
Issues:
VLAN is not an option
MPLS is expensive
Higher layers tunneling, e.g. VXLAN, impacts performance
In CATENAE:
Traffic steering is enforced by the software switches
Only MAC address rewriting is used

14. Traffic Steering in CATENAE
Each (software) switch in the chain knows the next hop for a given chain
E.g., the classifier knows all the first chains’ functions
Network flows reclassification & MAC addresses rewriting after each function
Fake per-function VLANs to handle opaque functions
Traffic steering in CATENAE does not use tunneling, instead it relies on rewriting mac addresses.
Recall that the L2 headers are in fact used only internally in the Sgi-LAN, so we can change them as we wish as long as we don’t break the system!
In CATENAE each software switch knows which one is the next hop for a given chain, for example

15. Traffic steering: how it works…
SFC Controller input: chain description
E.g., Flow identifier: SRC_IP= , Functions: [F1,F2]
The SFC Controller knows:
Functions information
switch identifier, switch’s port number
Function MAC address
If the function modifies packet headers (opaque or transparent)

16. Switch connected to a transparent function
Packet received from the SGi-LAN:
Lookup DST MAC ADDRESS  Send to corresponding function
Packet received from the Function:
Re-classify the packet  Rewrite SRC and DST MAC ADDRESSES
SGi-LAN
Classifier F1

17. Switch connected to an Opaque function (After a transparent function)
Packet received from the SGi-LAN:
Classify packet  Set fake-VLAN and send to corresponding function
Packet received from the Function:
Lookup VLAN  use generated SRC MAC address, rewrite SRC and DST MAC ADDRESSES
SGi-LAN F2

18. Switch connected to a function after an opaque function
Packet received from the SGi-LAN:
Lookup SRC MAC Addr  Set fake-VLAN and send to corresponding function
SGi-LAN F3

19. Implementation

20. SFC Controller Virtual Network Functions:
Implementation
SFC Controller
RYU SDN Framework, ~100 LoC in python
Virtual Network Functions:
Emulated with click and node.js using Linux containers

21. No per-packet overheads
Evaluation
No forwarding delays
Chains execution do not involve control plane actions
No per-packet overheads
No encapsulation required
Classifier scalability
Only upstream flows are processed (10-15% of total traffic)
Support for millions of flow classification entries in software hash tables
Simple integration in legacy networks
No “global” VLANs
No specialized hardware (switches and NICs)

22. Chains creation throughput

23. Conclusions
CATENAE is an effective system for supporting Service Function Chaining in today’s networks
Takeaways:
General Purpose Infrastructure != General Purpose Solution
System-level solutions solve unsolvable problems!