of 25
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.

SDN Traffic Engineering with Segment Routing The Next Evolution. Cengiz Alaettinoglu

Category:

Medicine, Science & Technology

Publish on:

Views: 3 | Pages: 25

Extension: PDF | Download: 0

Share
Description
SDN Traffic Engineering with Segment Routing The Next Evolution Cengiz Alaettinoglu Traffic Engineering (TE) Minimize the worst link u1liza1on Alleviate traffic conges1on Be9er/longer use of equipment/port/fiber
Transcript
SDN Traffic Engineering with Segment Routing The Next Evolution Cengiz Alaettinoglu Traffic Engineering (TE) Minimize the worst link u1liza1on Alleviate traffic conges1on Be9er/longer use of equipment/port/fiber Route traffic around congested links Put traffic on non-shortest paths Copyright 2017 Packet Design. All rights reserved. 2 Evolution of Traffic Engineering Offline traffic engineering Op1mal, but not adap1ve On-device traffic engineering Adap1ve, but not op1mal So#ware defined networking Best of both worlds, yet simpler; simplicity enabled by: Segment rou1ng Push-based telemetry SDN Traffic Engineering applica1on Copyright 2017 Packet Design. All rights reserved. 3 Offline Traffic Engineering Topology model Traffic demand matrix Op1miza1on algorithm computes routes so that the worst link u1liza1on is minimized Linear programming Copyright 2017 Packet Design. All rights reserved. 4 Pros/Cons of Offline Traffic Engineering Very good link u1liza1on values Network model is hard to keep accurate Traffic demand matrix is hard to compute Op1miza1on algorithm is very slow Hours to days Can not adapt to failures Too many tunnels (N 2 ) Some paths may be surprisingly long Copyright 2017 Packet Design. All rights reserved. 5 On-Device Traffic Engineering RSVP-TE/CSPF Routers flood available bandwidth of links in IGP Each router Sets up one (or more) tunnels to other routers Monitors the u1liza1on of these tunnels (auto-bandwidth) Triggers re-op1miza1on when u1liza1on changes Uses CSPF (constraint-based shortest path first) to compute the paths Signals the path and reserves bandwidth using RSVP Copyright 2017 Packet Design. All rights reserved. 6 Pros/Cons of On-Device Traffic Engineering Not so good link u1liza1on values Each router is selfish in op1miza1on No network-wide op1miza1on Network model is readily available Traffic demand matrix is easy with auto-bandwidth CSPF is fast Can adapt to failures Too many tunnels (N 2 ) Some paths may be surprisingly long Flooding available bandwidth impacts IGP, par1cularly convergence 1me Race condi1ons a\er failures Long-lived FRR RSVP-TE overhead is high due to N 2 tunnels Protocol and management overhead Copyright 2017 Packet Design. All rights reserved. 7 Example Deployments Small Medium Large Routers ,900 Links 300 2,000 8,000 Tunnels 1,600 20, ,000 Majority of the tunnels have very small amount of traffic No TE needed Copyright 2017 Packet Design. All rights reserved. 8 Link / Tunnel Distribution Most links carry a small number of tunnels Small number of links carry a lot of tunnels Copyright 2017 Packet Design. All rights reserved. 9 A Tunnel Path - Before, During and After a Link Failure :04: :04: :14:00 A wide-area link fails at :04: It was carrying 327 tunnels from 22 head-end routers The tunnel above fails to op1mize, but why? Copyright 2017 Packet Design. All rights reserved. 10 Re-Optimization after Link Failure 22 head-end routers get a signal via RSVP-TE and try to re-op1mize Race to available bandwidth Each router op1mizes for itself It does not know what the other 21 routers need It doesn t even know there are other routers/tunnels interested in this bandwidth 9 tunnels fail to op1mize 5 head-end routers The example tunnel is one of the unlucky ones This could have been avoided with network-wide op:miza:on! Copyright 2017 Packet Design. All rights reserved. 11 What Happens to the Traffic? Traffic now takes the IGP path (green arrows) Tunnel needed 34Mbps which is not available anywhere in the network The IGP path too does not have this bandwidth available Conges1on kicks in Copyright 2017 Packet Design. All rights reserved. 12 Another Tunnel is Stuck on its FRR What happens when a tunnel fails to op1mize and it is FRR protected? FRR is stuck Usually no reserva1ons are made on FRR paths Conges1on will kick in Copyright 2017 Packet Design. All rights reserved. 13 N 2 Tunnels - Beyond Human Manageability It is not just 9 tunnels that are down 1204 down tunnels is too many for any operator to figure out the root cause If these tunnels are for traffic engineering, can we really say we are successfully doing traffic engineering? It is 1me for so\ware/devops to manage the network Copyright 2017 Packet Design. All rights reserved. 14 AN SDN APPROACH Copyright 2017 Packet Design. All rights reserved. 15 What Do We Really Need? Real-1me model Alleviate conges1on, especially a\er a link failure Create as few tunnels as necessary Very small signaling overhead Very small IGP overhead Do not want IGP dynamics due to available bandwidth changes Network-wide op1miza1on Simple to deploy and operate Copyright 2017 Packet Design. All rights reserved. 16 SDN Promises a Solution Segment rou1ng (SR) replaces RSVP Provides uncompromised func1onality Simple control plane with very low overhead Push-based telemetry for traffic matrices YANG model based Frees IGP SDN controller is part of the network control plane Has real-1me topology Enables manipula1ng paths on the devices using standard south bound protocols Traffic Engineering becomes an SDN applica1on Op1mizes paths network-wide As few tunnels as necessary Copyright 2017 Packet Design. All rights reserved. 17 Segment Routing Segment rou1ng simplifies IP/MPLS control plane No need to run LDP or RSVP-TE Func1onality is not compromised Can forward traffic on non-shortest paths for traffic engineering Detour, bypass FRR (fast re-route), and IP LFA protec1on Secondary paths SLA-conforming service specific paths (e.g. L2/L3 VPNs) SDN programmability Copyright 2017 Packet Design. All rights reserved. 18 TE Needs Shortest and Non-Shortest Paths; SR Can Encode Any Path A B V W X Y C D Z 1 Segment (shortest IGP path) Go to Z on shortest path (node segment) A B V W X Y A B V W X Y C C D D Z Z 3 Segments Go to C on shortest path Go to X on link 3 (adjacency segment) Go to Z on shortest path 5 Segments Go to B on shortest path Go to W on shortest path Go to Y on shortest path Go to D on shortest path Go to Z on shortest path Copyright 2017 Packet Design. All rights reserved. 19 Push-Based Telemetry Eases Traffic Demand Matrix Generation How much customer traffic enters the network in Hanoi and is des1ned for Tokyo? Demand does not change based on internal rou1ng Tradi1onally, NetFlow is used for this and can s1ll be used Push- and model-based telemetry have very promising features, including real-1me traffic visibility Copyright 2017 Packet Design. All rights reserved. 20 YANG Model Pushed by Ingress Routers +--ro traffic-collector +--ro afs +--ro af* [af-name] +--ro counters +--ro prefixes +--ro prefix* +--ro ipaddr? +--ro mask? string string +--ro label? Tc-oper-local-label +--ro base-counter-sta1s1cs +--ro transmit-packets-per-second-switched? uint64 +--ro transmit-bytes-per-second-switched? uint64 +--ro count-history* +--ro event-start-1mestamp? uint64 +--ro event-end-1mestamp? uint64 +--ro transmit-number-of-packets-switched? uint64 +--ro transmit-number-of-bytes-switched? uint64 +--ro is-valid? boolean +--ro traffic-matrix-counter-sta1s1cs +--ro transmit-packets-per-second-switched? uint64 +--ro transmit-bytes-per-second-switched? uint64 +--ro count-history* +--ro event-start-1mestamp? uint64 +--ro event-end-1mestamp? uint64 +--ro transmit-number-of-packets-switched? uint64 +--ro transmit-number-of-bytes-switched? uint64 +--ro is-valid? boolean +--ro prefix? string Similar content to NetFlow for traffic matrix genera1on Misses port/proto level detail Pushed from the routers Few seconds to minutes Efficient transfer of data Binary encoded using ProtoBuf Copyright 2017 Packet Design. All rights reserved. 21 Traffic Engineering as an SDN App. SDN applica1on manages traffic demand Current as well as future reserva1ons IGP does not have to signal available bandwidth Push-based telemetry or NetFlow-based matrices can be generated SDN applica1on computes paths and allocates bandwidth Centraliza1on yields network-wide resource op1miza1on Creates the fewest tunnels necessary SDN applica1on adapts to failures and repairs SDN controller provides real-1me topology view No race condi1ons a\er failures and repairs Segment rou1ng can be used for network simplifica1on SDN controller makes this an abstrac1on for the applica1on RSVP-TE can s1ll be used where SR is not available Copyright 2017 Packet Design. All rights reserved. 22 Reducing the N 2 Tunnels Only generates tunnels for traffic going over congested links Tunnels no longer need to be configured a priori at the routers Only create them if they will have a posi1ve impact Special case: Under normal condi1ons don t generate any tunnels Under failure condi1ons generate enough to alleviate conges1on Do not create tunnels when IGP path sa1sfies the constraints Easy to implement in so\ware with a global view, but hard to do one device at a 1me Copyright 2017 Packet Design. All rights reserved. 23 Illustration 1 Gbps links Two elephant flows 850Mbps west to east 500Mbps north to south Lots of mice flows Copyright 2017 Packet Design. All rights reserved. 24 Concluding Remarks SDN simplifies running a traffic engineered network Applica1on is the SDN revolu1on SDN applica1on needs enablers from the infrastructure Controller Segment rou1ng (or RSVP-TE when not available) Push-based telemetry NETCONF/YANG, PCEP, and other southbound protocols Copyright 2017 Packet Design. All rights reserved. 25
Search Related
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks