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

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

Network Function Virtualization

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

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

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

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

CATENAE Ready-to-Deploy Service Function Chaining

Let’s change topic…

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

CATENAE architecture No modifications to the network

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

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

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

Traffic steering: how it works… SFC Controller input: chain description E.g., Flow identifier: SRC_IP=10.0.0.2, 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)

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

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

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

Implementation

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

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)

Chains creation throughput

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!