Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Testbeds IntErconnections with L2 overlays - SRv6 for SFC

364 views

Published on

This demo shows a Service Function Chaining (SFC) scenario across different testbeds, based on SRv6 (Segment Routing over IPv6).
We first show the design and automatic deployment of an arbitrary Layer 2 overlay network topology over multiple SoftFIRE testbeds. The we show a Service Function Chaining scenario based on IPv6 Segment Routing.

Published in: Internet
  • Be the first to comment

  • Be the first to like this

Testbeds IntErconnections with L2 overlays - SRv6 for SFC

  1. 1. TIE-SR Testbeds IntErconnections with L2 overlays - SRv6 for SFC SoftFIRE challenge 3rd Fed4FIRE+ Engineering Conference – March 15th 2018, Paris, France Stefano Salsano(1, 2), Pier Luigi Ventre(1), Paolo Lungaroni(1), Francesco Lombardo(1), Claudio Pisa(1), Ahmed Abdelsalam(3), Mohammad Mahdi Tajiki(4) (1) CNIT, Italy; (2)Univ. of Rome Tor Vergata, Italy; (3) GSSI, Italy; (4) Univ. of Tarbiat Modares, Iran.
  2. 2. TIE-SR scope and contributions • The TIE-SR demo shows a Service Function Chaining (SFC) scenario across different testbeds, based on SRv6 (Segment Routing over IPv6). 1) Automatic design and deployment of an arbitrary Layer 2 Overlay network topology over multiple SoftFIRE testbeds 2) Service Function Chaining scenario based on IPv6 Segment Routing 2
  3. 3. SRv6 – Segment Routing over IPv6 • SRv6 works by carrying a segment list (a list of IPv6 addresses) in the IPv6 header. • SRv6 can be used as underlay or overlay technology and it extends the capability of the networking layer, allowing to put “network programs” in the packet headers. • SRv6 can become a key enabler for the Future Internet Architecture, where a high level of flexibility is a required. – The 3GPP has recently started a study item considering SRv6 as a candidate for user plane in 5G. – The IETF DMM WG is also currently discussing SRv6. • SRv6 is natively supported in recent Linux kernels 3
  4. 4. Outline 1) Automatic design and deployment of an arbitrary Layer 2 Overlay network topology over multiple SoftFIRE testbeds 2) Service Function Chaining scenario based on IPv6 Segment Routing 4
  5. 5. Outline 1) Automatic design and deployment of an arbitrary Layer 2 Overlay network topology over multiple SoftFIRE testbeds 2) Service Function Chaining scenario based on IPv6 Segment Routing 5
  6. 6. Web Interface 6
  7. 7. Phase 1 - Automatic design and development… • A set of VMs (ON – Overlay Nodes) are deployed in SoftFIRE • VXLAN tunnels are setup to build the L2 overlay topology among VMs • Dynamic Routing is supported with OSPFv3 (Linux quagga/ospf6d) in each VM. Layer 3 IPv6 addressing is automatically configured. • Within each VM, a set of terminals and Overlay Virtual Network Functions (O-VNF) is deployed using Linux netns or LXD containers 7
  8. 8. Example topology 8
  9. 9. TIE-SR phase 1 workflow 9 OpenBaton .csar OpenStack (ADS testbed) OpenStack (Surrey testbed) .csar (1) .csar generation (2) Preparation for deployment (3) Deployment on the Experiment Manager TIE-SR backend VM VM VM VM (4) Contact backend during setup (5) Event notification: end of deployment
  10. 10. TIE-SR phase 1 workflow 10 OpenBaton OpenStack (ADS testbed) OpenStack (Surrey testbed) TIE-SR backend VM VM VM VM Monitoring manager
  11. 11. TIE-SR phase 1 workflow 11 OpenBaton OpenStack (ADS testbed) OpenStack (Surrey testbed) TIE-SR backend VM VM VM VM (6) Configure / clean buttons (7) Configure scripts
  12. 12. 12 Openstack Networking Overlay Level Experiment X Experiment X L2 Tunnel (VXLAN) TIE-SR testbeds over SoftFIRE infrastructure ADSTestbed SurreyTestbed Experiment Y TIE-SR backend
  13. 13. Outline 1) Automatic design and deployment of an arbitrary Layer 2 Overlay network topology over multiple SoftFIRE testbeds 2) Service Function Chaining scenario based on IPv6 Segment Routing 13
  14. 14. Phase 2 - SFC scenario based on IPv6 SR • We create an SRv6 domain on top of the overlay network. – ads2, surrey2: edge nodes of the SR domain – ads1 and surrey1: internal NFV nodes, they can run VNFs – All terms are outside the SR domain. 14 SRv6 Domain
  15. 15. SRv6 policies • Traffic going to term4 will follow the shortest path calculated by the OSPFv3 Routing daemon. • We create two SRv6 policies on the ingress node (ads2) as follows: 1. Traffic going to term3 will follow an SRv6 TE policy <<term1 -> ads1 -> surrey2 -> term3>> 2. Traffic going to term2 will follow an SRv6 SFC policy <<term1 -> ads1 -> nfv1 -> surrey2 -> term2>> • We have snort (SRv6-aware) running in an LXD VNF1 and configured to give alert for ICMP packets. 15 SRv6 Domain
  16. 16. SRv6 policies • Traffic going to term4 will follow the shortest path calculated by the OSPFv3 Routing daemon. • We create two SRv6 policies on the ingress node (ads2) as follows: 1. Traffic going to term3 will follow an SRv6 TE policy <<term1 -> ads1 -> surrey2 -> term3>> 2. Traffic going to term2 will follow an SRv6 SFC policy <<term1 -> ads1 -> nfv1 -> surrey2 -> term2>> • We have snort (SRv6-aware) running in an LXD VNF1 and configured to give alert for ICMP packets. 16 SRv6 Domain fd04:1::1 fd04:2::1 fd04:3::1
  17. 17. SRv6 policies • Traffic going to term4 will follow the shortest path calculated by the OSPFv3 Routing daemon. • We create two SRv6 policies on the ingress node (ads2) as follows: 1. Traffic going to term3 will follow an SRv6 TE policy <<term1 -> ads1 -> surrey2 -> term3>> 2. Traffic going to term2 will follow an SRv6 SFC policy <<term1 -> ads1 -> nfv1 -> surrey2 -> term2>> • We have snort (SRv6-aware) running in an LXD VNF1 and configured to give alert for ICMP packets. 17 SRv6 Domain fd04:1::1 fd04:2::1 fd04:3::1
  18. 18. SRv6 policies • Traffic going to term4 will follow the shortest path calculated by the OSPFv3 Routing daemon. • We create two SRv6 policies on the ingress node (ads2) as follows: 1. Traffic going to term3 will follow an SRv6 TE policy <<term1 -> ads1 -> surrey2 -> term3>> 2. Traffic going to term2 will follow an SRv6 SFC policy <<term1 -> ads1 -> nfv1 -> surrey2 -> term2>> • We have snort (SRv6-aware) running in an LXD VNF1 and configured to give alert for ICMP packets. 18 SRv6 Domain fd04:1::1 fd04:2::1 fd04:3::1
  19. 19. SDN based approach for setting policies • Finally, we show that SRv6 policies can be set in an edge node using a controller (SDN based approach) • The controller changes the policy periodically (e.g. every 20 seconds) – <ads2, vnf1, surrey2> – <ads2, vnf1, vnf2, surrey2> – <ads2, vnf2, surrey2> – <ads2, surrey2> 19 SRv6 Domain fd04:1::1 fd04:2::1 fd04:3::1
  20. 20. Thank you. Questions? Contacts Stefano Salsano University of Rome Tor Vergata stefano.salsano@uniroma2.it The tools we developed will be released as Open Source, now they are available on demand, just ask us! 20

×