SDN Traffic Engineering with Segment Routing · Evolution of Traffic Engineering Oﬄine traﬃc...

SDN Traffic Engineering with Segment Routing

The Next Evolution

Cengiz Alaettinoglu

Traffic Engineering (TE)

Minimizetheworstlinku1liza1on•  Alleviatetrafficconges1on•  Be9er/longeruseofequipment/port/fiber

Routetrafficaroundcongestedlinks•  Puttrafficonnon-shortestpaths

Copyright © 2017 Packet Design. All rights reserved. 2

Evolution of Traffic Engineering

Offlinetrafficengineering•  Op1mal,butnotadap1veOn-devicetrafficengineering•  Adap1ve,butnotop1malSo#waredefinednetworking•  Bestofbothworlds,yetsimpler;simplicityenabledby:

•  Segmentrou1ng•  Push-basedtelemetry•  SDNTrafficEngineeringapplica1on


Offline Traffic Engineering

TopologymodelTrafficdemandmatrixOp1miza1onalgorithmcomputesroutessothattheworstlinku1liza1onisminimized•  Linearprogramming


Pros/Cons of Offline Traffic Engineering


Verygoodlinku1liza1onvalues

NetworkmodelishardtokeepaccurateTrafficdemandmatrixishardtocomputeOp1miza1onalgorithmisveryslow•  HourstodaysCannotadapttofailuresToomanytunnels(N2)Somepathsmaybesurprisinglylong

On-Device Traffic Engineering RSVP-TE/CSPF

RoutersfloodavailablebandwidthoflinksinIGPEachrouter•  Setsupone(ormore)tunnelstootherrouters•  Monitorstheu1liza1onofthesetunnels(auto-bandwidth)•  Triggersre-op1miza1onwhenu1liza1onchanges•  UsesCSPF(constraint-basedshortestpathfirst)tocomputethepaths

•  SignalsthepathandreservesbandwidthusingRSVP


Pros/Cons of On-Device Traffic Engineering


Notsogoodlinku1liza1onvalues•  Eachrouterisselfishinop1miza1on

•  Nonetwork-wideop1miza1on

NetworkmodelisreadilyavailableTrafficdemandmatrixiseasywithauto-bandwidthCSPFisfastCanadapttofailuresToomanytunnels(N2)SomepathsmaybesurprisinglylongFloodingavailablebandwidthimpactsIGP,par1cularlyconvergence1meRacecondi1onsa\erfailures

•  Long-livedFRRRSVP-TEoverheadishighduetoN2tunnels

•  Protocolandmanagementoverhead

Example Deployments

Small Medium Large

Routers 75 450 1,900

Links 300 2,000 8,000

Tunnels 1,600 20,500 132,000


•  Majorityofthetunnelshaveverysmallamountoftraffic

•  NoTEneeded

Link / Tunnel Distribution


MostlinkscarryasmallnumberoftunnelsSmallnumberoflinkscarryalotoftunnels

A Tunnel Path - Before, During and After a Link Failure

Awide-arealinkfailsat2015-12-2712:04:05.200490•  Itwascarrying327tunnelsfrom22head-endroutersThetunnelabovefailstoop1mize,butwhy?


2015-12-2712:04:05.200490

2015-12-2712:04:05

2015-12-2712:14:00

Re-Optimization after Link Failure


22head-endroutersgetasignalviaRSVP-TEandtrytore-op1mize•  RacetoavailablebandwidthEachrouterop1mizesforitself•  Itdoesnotknowwhattheother21routersneed•  Itdoesn’tevenknowthereareotherrouters/tunnelsinterestedinthis

bandwidth9tunnelsfailtoop1mize•  5head-endrouters•  TheexampletunnelisoneoftheunluckyonesThiscouldhavebeenavoidedwithnetwork-wideop:miza:on!

What Happens to the Traffic?

TrafficnowtakestheIGPpath(greenarrows)Tunnelneeded34MbpswhichisnotavailableanywhereinthenetworkTheIGPpathtoodoesnothavethisbandwidthavailable•  Conges1onkicksin


Another Tunnel is Stuck on its FRR

Whathappenswhenatunnelfailstoop1mizeanditisFRRprotected?•  FRRisstuck•  Usuallynoreserva1onsaremadeonFRRpaths•  Conges1onwillkickin


N2 Tunnels - Beyond Human Manageability

Itisnotjust9tunnelsthataredown1204downtunnelsistoomanyforanyoperatortofigureouttherootcause•  Ifthesetunnelsarefortrafficengineering,canwereallysayweare

successfullydoingtrafficengineering?•  Itis1meforso\ware/devopstomanagethenetwork


ANSDNAPPROACH


What Do We Really Need?

Real-1memodel•  Alleviateconges1on,especiallya\eralinkfailureCreateasfewtunnelsasnecessary•  Verysmallsignalingoverhead•  VerysmallIGPoverhead

•  DonotwantIGPdynamicsduetoavailablebandwidthchanges

Network-wideop1miza1onSimpletodeployandoperate


SDN Promises a Solution

Segmentrou1ng(SR)replacesRSVP•  Providesuncompromisedfunc1onality•  SimplecontrolplanewithverylowoverheadPush-basedtelemetryfortrafficmatrices•  YANGmodelbased•  FreesIGPSDNcontrollerispartofthenetworkcontrolplane•  Hasreal-1metopology•  Enablesmanipula1ngpathsonthedevicesusingstandardsouthbound

protocolsTrafficEngineeringbecomesanSDNapplica1on•  Op1mizespathsnetwork-wide•  Asfewtunnelsasnecessary


Segment Routing

Segmentrou1ngsimplifiesIP/MPLScontrolplane•  NoneedtorunLDPorRSVP-TEFunc1onalityisnotcompromised•  Canforwardtrafficonnon-shortestpathsfortrafficengineering

•  Detour,bypassFRR(fastre-route),andIPLFAprotec1on•  Secondarypaths•  SLA-conformingservicespecificpaths(e.g.L2/L3VPNs)•  SDNprogrammability


TE Needs Shortest and Non-Shortest Paths; SR Can Encode Any Path


A B

Z

DC

V W YX

1Segment(shortestIGPpath)•  GotoZonshortestpath(nodesegment)

A B

Z

DC

V W YX5Segments•  GotoBonshortestpath•  GotoWonshortestpath•  GotoYonshortestpath•  GotoDonshortestpath•  GotoZonshortestpath

A B

Z

DC

V W YX

3Segments•  GotoConshortestpath•  GotoXonlink3(adjacencysegment)•  GotoZonshortestpath

Push-Based Telemetry Eases Traffic Demand Matrix Generation

HowmuchcustomertrafficentersthenetworkinHanoiandisdes1nedforTokyo?•  Demanddoesnotchangebasedoninternalrou1ngTradi1onally,NetFlowisusedforthisandcans1llbeusedPush-andmodel-basedtelemetryhaveverypromisingfeatures,includingreal-1metrafficvisibility


YANG Model Pushed by Ingress Routers

SimilarcontenttoNetFlowfortrafficmatrixgenera1on•  Missesport/protoleveldetailPushedfromtherouters•  FewsecondstominutesEfficienttransferofdata•  BinaryencodedusingProtoBuf


+--rotraffic-collector+--roafs+--roaf*[af-name]+--rocounters+--roprefixes+--roprefix*+--roipaddr?string+--romask?string+--rolabel?Tc-oper-local-label+--robase-counter-sta1s1cs|+--rotransmit-packets-per-second-switched?uint64|+--rotransmit-bytes-per-second-switched?uint64|+--rocount-history*|+--roevent-start-1mestamp?uint64|+--roevent-end-1mestamp?uint64|+--rotransmit-number-of-packets-switched?uint64|+--rotransmit-number-of-bytes-switched?uint64|+--rois-valid?boolean+--rotraffic-matrix-counter-sta1s1cs|+--rotransmit-packets-per-second-switched?uint64|+--rotransmit-bytes-per-second-switched?uint64|+--rocount-history*|+--roevent-start-1mestamp?uint64|+--roevent-end-1mestamp?uint64|+--rotransmit-number-of-packets-switched?uint64|+--rotransmit-number-of-bytes-switched?uint64|+--rois-valid?boolean+--roprefix?string

Traffic Engineering as an SDN App.

SDNapplica1onmanagestrafficdemand•  Currentaswellasfuturereserva1ons•  IGPdoesnothavetosignalavailablebandwidth•  Push-basedtelemetryorNetFlow-basedmatricescanbegeneratedSDNapplica1oncomputespathsandallocatesbandwidth•  Centraliza1onyieldsnetwork-wideresourceop1miza1on•  CreatesthefewesttunnelsnecessarySDNapplica1onadaptstofailuresandrepairs•  SDNcontrollerprovidesreal-1metopologyview•  Noracecondi1onsa\erfailuresandrepairsSegmentrou1ngcanbeusedfornetworksimplifica1on•  SDNcontrollermakesthisanabstrac1onfortheapplica1on•  RSVP-TEcans1llbeusedwhereSRisnotavailable


Reducing the N2 Tunnels

Onlygeneratestunnelsfortrafficgoingovercongestedlinks•  Tunnelsnolongerneedtobeconfiguredaprioriattherouters

•  Onlycreatethemiftheywillhaveaposi1veimpact•  Specialcase:

•  Undernormalcondi1onsdon’tgenerateanytunnels•  Underfailurecondi1onsgenerateenoughtoalleviateconges1on

DonotcreatetunnelswhenIGPpathsa1sfiestheconstraintsEasytoimplementinso\warewithaglobalview,buthardtodoonedeviceata1me


Illustration


1GbpslinksTwoelephantflows•  850Mbpswesttoeast•  500MbpsnorthtosouthLotsofmiceflows

Concluding Remarks

SDNsimplifiesrunningatrafficengineerednetwork•  Applica1onistheSDNrevolu1onSDNapplica1onneedsenablersfromtheinfrastructure•  Controller•  Segmentrou1ng(orRSVP-TEwhennotavailable)•  Push-basedtelemetry•  NETCONF/YANG,PCEP,andothersouthboundprotocols


SDN Traffic Engineering with Segment Routing · Evolution of Traffic Engineering Oﬄine traﬃc...

Documents

Transcript of SDN Traffic Engineering with Segment Routing · Evolution of Traffic Engineering Oﬄine traﬃc...