O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Testbeds IntErconnections with L2 overlays - SRv6 for SFC

530 visualizações

Publicada em

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.

Publicada em: Internet
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

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

×