lecture17-bgp-covid€¦ · Telecom LBL a.b.0.0/16 Cornell a.c.0.0/16 a...* is this way foo.com...

ComputerNetworks:ArchitectureandProtocols

CS4450

Lecture17BGPrecap

Packetheaderasaninterface

RachitAgarwal

Whatdoweknowsofar[1]…

• Networkperformancemetrics

• Transmissiondelay,propagationdelay,queueingdelay,bandwidth

• Sharingnetworks• Circuitswitching,packetswitching,andassociatedtradeoffs• WhyisInternetpacketswitched?

• Architecturalprinciplesanddesigngoals• Layeringprinciple,End-to-endprinciple,Fatesharingprinciple• ManyimportantdesigngoalsfromDavidClark’spaper

• Andmanyimportantmissinggoals

• Addressing• LinklayerMACnames,andscalabilitychallengesattheInternet

• NetworklayerIPaddresses:threerequirements,aggregation,CIDR

2

Whatdoweknowsofar[2]…• LinkLayer

• SharingaBroadcastmedium,associatedchallenges,CSMA/CD

• Linklayeraddressing:MACnames

• WhyFrames?WhySwitchedEthernet?

• TheSpanningTreeProtocol(STP)

• NetworkLayer

• WhyNetworkLayer?WhynotjustuseSTPacrosstheInternet?

• IPAddressing

• RoutingTables:Acollectionofspanningtrees,oneperdestination

• GeneratingValidRoutingtables(withinadomain):

• Globalview(Link-StateProtocol),andlimitations

• Localview(Distance-vectorProtocol)

• GeneratingValidRoutingtables(acrossdomains):

• BorderGatewayProtocol,Internetstructure,routingpolicies3

GoalsforToday’sLecture

• RecapIPaddressingandBGPquickly

• UnderstandIP(theInternetProtocol)

• PacketHeaderasanetwork“interface”

4

NetworkLayer

• THEfunctionality:deliveringthedata

• THEprotocol:InternetProtocol(IP)

• Achievesitsfunctionality(deliveringthedata),usingthreeideas:

• Addressing(IPaddressing)

• Routing(usingavarietyofprotocols)

• Packetheaderasaninterface(Encapsulatingdataintopackets)

Recap:Threerequirementsforaddressing

• Scalablerouting

• Howmuststatemustbestoredtoforwardpackets?

• Howmuchstateneedstobeupdateduponhostarrival/departure?

• Efficientforwarding

• Howquicklycanonelocateitemsinroutingtable?

• Hostmustbeabletorecognizepacketisforthem

Recap:L2addressingdoesnotenablescalablerouting

• Scalablerouting

• Howmuchstatetoforwardpackets?

• Oneentryperhostperswitch

• Howmuchstateupdatedforeacharrival/departure?

• Oneentryperhostperswitch

• Efficientforwarding

• ExactmatchlookuponMACaddresses(exactmatchiseasy!)

• Hostmustbeabletorecognizethepacketisforthem

• MACaddressdoesthisperfectly

Recap:Today’sInternetAddressing:CIDR

• ClasslessInter-domainRouting

• Idea:Flexibledivisionbetweennetworkandhostaddresses

• Prefixisnetworkaddress

• Suffixishostaddress

• Example:

• 128.84.139.5/23isa23bitprefixwith:

• First23bitsfornetworkaddress

• Next9bitsforhostaddresses:maximum2^9hosts

• Terminology:“Slash23”

“InteriorRouters”

“AutonomousSystem(AS)”or“Domain” Regionofanetworkunderasingleadministrativeentity

“BorderRouters”

An“end-to-end”route

Recap:Whatdoesacomputernetworklooklike?

AT&T a.0.0.0/8

France Telecom

LBL a.b.0.0/16

Cornella.c.0.0/16

a.c.*.* is this way

a.b.*.* is this way

Recap:IPaddressing->ScalableRouting?

AT&T a.0.0.0/8

France Telecom

LBL a.b.0.0/16

Cornella.c.0.0/16

a.*.*.* is this way

foo.com a.d.0.0/16

Canaddnewhosts/networkswithoutupda^ngtherou^ngentriesatFranceTelecom


AT&T a.0.0.0/8

LBL a.b.0.0/16

Cornella.c.0.0/16

ESNet

ESNetmustmaintainrou^ngentriesforbotha.*.*.*anda.c.*.*


Recap:AdministrativeStructureShapesInter-domainRouting

● ASeswantfreedomtopickroutesbasedonpolicy● “Mytrafficcan’tbecarriedovermycompetitor’snetwork!”

● “Idon’twanttocarryA’strafficthroughmynetwork!”

● CannotbeexpressedasInternet-wide“leastcost”

● ASeswantautonomy● Wanttochoosetheirowninternalroutingprotocol

● Wanttochoosetheirownpolicy

● ASeswantprivacy● Choiceofnetworktopology,routingpolicies,etc.

peer peerprovider customerRelationsbetweenASes

•Customerspayprovider•Peersdon’tpayeachother

BusinessImplications

Recap:BusinessRelationships

● ASesprovide“transit”betweentheircustomers● Peersdonotprovidetransitbetweenotherpeers

trafficallowed trafficnotallowed

A B C

D E F

QPr Cu

Peer Peer

Recap:Inter-domainRoutingFollowstheMoney

Recap:BGPInspiredbyDistanceVector

● Per-destinationrouteadvertisements

● Noglobalsharingofnetworktopology

● Iterativeanddistributedconvergenceonpaths

● But,fourkeydifferences

● BGPdoesnotpickshortestpaths● Path-vectorratherthandistancevector

▪ Eachannouncementcontainsthepathforeachdestination● Selectiverouteadvertisement

▪ IfIselectapath,Idon’t*haveto*advertiseittoothers● Routeaggregation

▪ Ratherthanstoringa.b.*.*/16anda.c.*.*/16,storea.*.*.*/8

Recap:BGPOutline

● BGPPolicy● Typicalpoliciesandimplementation

● BGPprotocoldetails

● IssueswithBGP

Recap:Policy:

Imposedinhowroutesareselectedandexported

Can reach 128.3/16

blah blah

Route selection

A

P

C

B

Q

Route export

● Selection:Whichpathtouse● Controlswhether/howtrafficleavesthenetwork

● Export:Whichpathtoadvertise● Controlswhether/howtrafficentersthenetwork

Recap:TypicalExportPolicy

Destinationprefixadvertisedby…

Exportrouteto…

CustomerEveryone

(providers,peers,othercustomers)

Peer Customers

Provider Customers

Knownasthe“Gao-Rexford”rulesCapturecommon(butnotrequired!)prac^ce

Recap:TypicalSelectionPolicy

● Indecreasingorderofpriority:1. Makeorsavemoney(sendtocustomer>peer>provider)

2. Maximizeperformance(smallestASpathlength)

3. Minimizeuseofmynetworkbandwidth(“hotpotato”)

4. …

Recap:BGPimplicitdecisionmaking

● Exportpolicy● Givesasetof“possible”pathsforeachAS

● Selectionpolicy● Givesarankingoverallthepossiblepaths

GRIFFIN et al.: STABLE PATHS PROBLEM AND INTERDOMAIN ROUTING 235

Fig. 1. Stable paths problems with shortest path solutions.

, then . Therefore, any stable pathassignment implicitly defines a tree rooted at the origin. Note,however, that this is not always a spanning tree.The stable paths problem is solvable if there

is a stable path assignment for . A stable path assignment isalso called a solution for . If no such assignment exists, thenis unsolvable.Fig. 1(a) presents a stable paths problem called SHORTEST 1.

The ranking function for each nonzero node is depicted as avertical list next to the node, with the highest ranked path atthe top going down to the lowest ranked nonempty path at thebottom. The stable path assignment

is illustrated in Fig. 1(b). If we reverse the ranking order of pathsat node we arrive at SHORTEST 2, depicted in Fig. 1(c). Thestable path assignment

is illustrated in Fig. 1(d). In both cases, the ranking functionsprefer shorter paths to longer paths and the solutions are shortestpath trees. Note that the ranking at node 4 breaks ties betweenpaths of equal length. This results in one shortest path tree asthe solution for SHORTEST 1, while another shortest path tree asthe solution for SHORTEST 2.The ranking of paths is not required to prefer shorter paths

to longer paths. For example, Fig. 2(a) presents a stable pathsproblem called GOOD GADGET. Note that both nodes 1 and 2prefer longer paths to shorter paths. The stable path assignment

illustrated in Fig. 2(b) is not a shortest path tree. This is theunique solution to this problem.A modification of GOOD GADGET, called NAUGHTY GADGET,

is shown in Fig. 2(c). NAUGHTY GADGET adds one permitted path

Fig. 2. Stable paths problems that are not shortest path problems.

Fig. 3. DISAGREE and its two solutions.

(3 4 2 0) for node 3, yet it has the same unique solution as GOODGADGET. However, as is explained in Section IV, the protocolSPVP can diverge for this problem. Finally, by reordering theranking of paths at node 4, we produce a specification calledBAD GADGET, presented in Fig. 2(d). This specification has nosolution and the SPVP protocol will always diverge.So far, our examples each has had at most one solution. This

is not always the case. The simplest instance, called DISAGREE,having more than one solution is illustrated in Fig. 3(a). Thestable path assignment

is depicted in Fig. 3(b). An alternative solution

is shown in Fig. 3(c). No other path assignments are stable forthis problem.

BGPExample(Allgood)GRIFFIN et al.: STABLE PATHS PROBLEM AND INTERDOMAIN ROUTING 235

Fig. 1. Stable paths problems with shortest path solutions.

, then . Therefore, any stable pathassignment implicitly defines a tree rooted at the origin. Note,however, that this is not always a spanning tree.The stable paths problem is solvable if there

is a stable path assignment for . A stable path assignment isalso called a solution for . If no such assignment exists, thenis unsolvable.Fig. 1(a) presents a stable paths problem called SHORTEST 1.

The ranking function for each nonzero node is depicted as avertical list next to the node, with the highest ranked path atthe top going down to the lowest ranked nonempty path at thebottom. The stable path assignment

is illustrated in Fig. 1(b). If we reverse the ranking order of pathsat node we arrive at SHORTEST 2, depicted in Fig. 1(c). Thestable path assignment

is illustrated in Fig. 1(d). In both cases, the ranking functionsprefer shorter paths to longer paths and the solutions are shortestpath trees. Note that the ranking at node 4 breaks ties betweenpaths of equal length. This results in one shortest path tree asthe solution for SHORTEST 1, while another shortest path tree asthe solution for SHORTEST 2.The ranking of paths is not required to prefer shorter paths

to longer paths. For example, Fig. 2(a) presents a stable pathsproblem called GOOD GADGET. Note that both nodes 1 and 2prefer longer paths to shorter paths. The stable path assignment

illustrated in Fig. 2(b) is not a shortest path tree. This is theunique solution to this problem.A modification of GOOD GADGET, called NAUGHTY GADGET,

is shown in Fig. 2(c). NAUGHTY GADGET adds one permitted path

Fig. 2. Stable paths problems that are not shortest path problems.

Fig. 3. DISAGREE and its two solutions.

(3 4 2 0) for node 3, yet it has the same unique solution as GOODGADGET. However, as is explained in Section IV, the protocolSPVP can diverge for this problem. Finally, by reordering theranking of paths at node 4, we produce a specification calledBAD GADGET, presented in Fig. 2(d). This specification has nosolution and the SPVP protocol will always diverge.So far, our examples each has had at most one solution. This

is not always the case. The simplest instance, called DISAGREE,having more than one solution is illustrated in Fig. 3(a). Thestable path assignment

is depicted in Fig. 3(b). An alternative solution

is shown in Fig. 3(c). No other path assignments are stable forthis problem.

1 2 3 4

R1 10 20 30 -

R2 130 20 30 430

AssumesaparticularadvertisementorderingMaylookdifferentwithdifferentordering

Inreal-world:orderingdependsonlatency,processingdelay,etc.

BGP: Issues

● Reachability

● Security

● Convergence

● Performance

● Anomalies

1

2 3

1 3 0 1 0

3 2 0 3 0

2 1 0 2 0

0

“1” prefers “1 3 0” over “1 0” to reach “0”

Example of Policy Oscillation

Initially: nodes 1, 2, 3 know only shortest path to 0

1

2 3

1 3 0 1 0

3 2 0 3 0

2 1 0 2 0

0

Step-by-step Policy Oscillation

1 advertises its path 1 0 to 2

1

2 3

1 3 0 1 0

3 2 0 3 0

2 1 0 2 0

0adve

rtise

: 1 0


1

2 3

1 3 0 1 0

3 2 0 3 0

2 1 0 2 0

0


1

2 3

1 3 0 1 0

3 2 0 3 0

2 1 0 2 0

0

advertise: 3 0



1

2 3

1 3 0 1 0

3 2 0 3 0

2 1 0 2 0

0


1

2 3

1 3 0 1 0

3 2 0 3 0

2 1 0 2 0

0withdr

aw: 1

0

1 withdraws its path 1 0 from 2


1

2 3

1 3 0 1 0

3 2 0 3 0

2 1 0 2 0

0


1

2 3

1 3 0 1 0

3 2 0 3 0

2 1 0 2 0

0

advertise: 2 0



1

2 3

1 3 0 1 0

3 2 0 3 0

2 1 0 2 0

0


1

2 3

1 3 0 1 0

3 2 0 3 0

2 1 0 2 0

0

withdraw: 3 0



1

2 3

1 3 0 1 0

3 2 0 3 0

2 1 0 2 0

0


1

2 3

1 3 0 1 0

3 2 0 3 0

2 1 0 2 0

0

1 advertises its path 1 0 to 2ad

verti

se: 1

0


1

2 3

1 3 0 1 0

3 2 0 3 0

2 1 0 2 0

0


1

2 3

1 3 0 1 0

3 2 0 3 0

2 1 0 2 0

0

withdraw: 2 0



1

2 3

1 3 0 1 0

3 2 0 3 0

2 1 0 2 0

0

We are back to where we started!


NetworkLayer

• THEfunctionality:deliveringthedata

• THEprotocol:InternetProtocol(IP)

• Achievesitsfunctionality(deliveringthedata),usingthreeideas:

• Addressing(IPaddressing)

• Routing(usingavarietyofprotocols)

• Packetheaderasaninterface(Encapsulatingdataintopackets)

WhatisDesigningIP?

• Syntax:formatofpacket

• Nontrivialpart:packet“header”

• Restisopaquepayload(whyopaque?)

• Semantics:meaningofheaderfields

• Requiredprocessing

Opaque PayloadHeader

PacketHeaderasInterface

• Thinkofpacketheaderasinterface

• Onlywayofpassinginformationfrompackettoswitch

• Designinginterfaces:

• Whattaskareyoutryingtoperform?

• Whatinformationdoyouneedtoaccomplishit?

• Headerreflectsinformationneededforbasictasks

WhatTasksDoWeNeedtoDo?

• Readpacketcorrectly

• Getthepackettothedestination

• Getresponsestothepacketbacktosource

• Carrydata

• Tellhostwhattodowiththepacketoncearrived

• Specifyanyspecialnetworkhandlingofthepacket

• Dealwithproblemsthatarisealongthepath

ReadingPacketCorrectly

• Wheredoestheheaderend?

• Wherethethepacketend?

• Whatprotocolareweusing?

• Whyisthissoimportant?

GettingtotheDestination

• Providedestinationaddress

• Shouldthisbelocationoridentifier(name)?

• Andwhat’sthedifference?

• Ifahostmovesshoulditsaddresschange?

• Ifnot,howcanyoubuildscalableInternet?

• Ifso,thenwhatgoodisanaddressforidentification?

GettingResponseBacktoSource

• Sourceaddress

• Necessaryforrouterstorespondtosource

• Whenwouldtheyneedtorespondback?

• Failures!

• Dotheyreallyneedtorespondback?

• Howwouldthesourceknowifthepackethasreachedthedestination?

CarryData

• Payload!

Questions?

ListofTasks




• Carrydata

• Tellhostwhattodowithpacketoncearrived



TellingDestinationHowtoProcessPacket

• Indicatewhichprotocolsshouldhandlepacket

• Whatlayersshouldthisprotocolbein?

• Whataresomeoptionsforthistoday?

• Howdoesthesourceknowwhattoenterhere?

SpecialHandling

• Typeofservice,priority,etc.

• Options:discusslater

DealingWithProblems

• Ispacketcaughtinloop?

• TTL

• Headercorrupted:

• DetectwithChecksum

• Whataboutpayloadchecksum?

• Packettoolarge?

• Dealwithfragmentation

• Splitpacketapart

• Keeptrackofhowtoputtogether

AreWeMissingAnything?




• Carrydata




FromSemanticstoSyntax

• Thepastfewslidesdiscussedtheinformationtheheadermustprovide

• Willnowshowthesyntax(layout)ofIPv4header,anddiscussthe

semanticsinmoredetail

IPPacketStructure

4-bit Version4-bit Header

Length8-bit Type of

Service (TOS)

16-bit Total Length (Bytes)

16-bit Identification 3-bit Flags 13-bit Fragment Offset

8-bit Time to Live (TTL)

8-bit Protocol 16-bit Header Checksum

32-bit Source IP Address

32-bit Destination IP Address

Options (if any)

Payload

20BytesofStandardHeader,thenOptions


Length8-bit Type of

Service (TOS)







Options (if any)

Payload

NextSetofSlides

• Mappingbetweentasksandheaderfields

• Eachofthesefieldsisdevotedtoatask

• Let’sfindoutwhichonesandwhy…

GoThroughTasksOne-by-One




• Carrydata




ReadPacketCorrectly

• Versionnumber(4bits)

• IndicatestheversionoftheIPprotocol

• Necessarytoknowwhatotherfieldstoexpect

• Typically“4”(forIPv4),andsometimes“6”(forIPv6)

• Headerlength(4bits)

• Numberof32-bitwordsintheheader

• Typically“5”(fora20-byteIPv4header)

• CanbemorewhenIPoptionsareused

• Totallength(16bits)

• Numberofbytesinthepacket

• Maximumsizeis65,535bytes(2^16-1)

• …thoughunderlyinglinksmayimposesmallerlimits

FieldsforReadingPacketCorrectly


Length8-bit Type of

Service (TOS)







Options (if any)

Payload

GettingPackettoDestinationandBack

• TwoIPaddresses

• SourceIPaddress(32bits)

• DestinationIPaddress(32bits)

• DestinationAddress

• Uniquelocatorforthereceivinghost

• Allowseachnodetomakeforwardingdecisions

• SourceAddress

• Uniquelocatorforthesendinghost

• Recipientcandecidewhethertoacceptpacket

• Enablesrecipienttosendareplybacktothesource



Length8-bit Type of

Service (TOS)







Options (if any)

Payload

Questions?

ListofTasks




• Carrydata




TellingHostHowtoHandlePacket

• Protocol(8bits)

• Identifiesthehigherlevelprotocol

• Importantfordemultiplexingatreceivinghost

• Mostcommonexamples

• E.g.,“6”fortheTransmissionControlProtocol(TCP)

• E.g.,“17”fortheUserDatagramProtocol

IP HeaderTCP Header

IP HeaderTCP Header

Protocol = 6 Protocol = 17



Length8-bit Type of

Service (TOS)







Options (if any)

Payload

SpecialHandling

• Type-of-Service(8-bits)

• Allowpacketstobetreateddifferentlybasedonneeds

• E.g.,lowdelayforaudio,highbandwidthforbulktransfer

• Hasbeenredefinedseveraltimes,nogeneraluse

• Options

• Abilitytospecifyotherfunctionality

• Extensibleformat

ExamplesofOptions

• RecordRoute

• StrictSourceRoute

• LooseSourceRoute

• Timestamp

• Traceroute

• RouterAlert

• …

PotentialProblems

• HeaderCorrupted:Checksum

• Loop:TTL

• Packettoolarge:Fragmentation

PreventingLoops

• Forwardingloopscausepacketstocycleforever

• Astheseaccumulate,eventuallyconsumeallcapacity

• Time-to-live(TTL)Field(8-bits)

• Decrementedateachhop,packetdiscardedifreaches0

• …and“timeexceeded”messageissenttothesource

• Using“ICMP”controlmessage;basisfortraceroute

TTLField


Length8-bit Type of

Service (TOS)







Options (if any)

Payload

HeaderCorruption

• Checksum(16bits)

• Particularformofchecksumoverpacketheader

• Ifnotcorrect,routerdiscardspackets

• Soitdoesn’tactinbogusinformation

• Checksumrecalculatedateveryrouter

• Why?

• WhyincludeTTL?

• Whyonlyheader?

ChecksumField


Length8-bit Type of

Service (TOS)







Options (if any)

Payload

PacketHeaderasaninterface

• Uselesstolearntheheaderformatbyheart

• Ifyourememberthetasksthatneedtobeperformed…

• Understandingwhyheaderformatiswhatitis…

• Ingeneral:ifyouunderstandtheproblem,solutioniseasy

• Astheproblemevolves,youwillknowwheretolookforasolution

• TransitionfromIPv4toIPv6

• Graduallyhappening…

• Ifyouwanttolearnabit,seebackupslides

Thisisitfortoday!

IPv6

• Motivated(prematurely)byaddressexhaustion

• Addressfourtimesasbig

• SteveDeeringfocusedonsimplifyingIP

• Gotridofallfieldsthatwerenotabsolutelynecessary

• “SpringCleaning”forIP

• Resultisanelegant,ifunambitious,protocol

IPv4andIPv6HeaderComparison

Version IHLType of Service (TOS)

Total Length

Identification Flags Fragment Offset

Time to Live (TTL) Protocol Header Checksum

Source Address

Destination Address

Options

Version Traffic Class Flow Label

Payload Length Next Header Hop Limit

Source Address

Destination Address

Field name kept from IPv4 to IPv6

Fields not kept in IPv6

Name and position changed in IPv6

New field in IPv6

SummaryofChanges

• EliminatedFragmentation

• Eliminatedheaderlength

• EliminatedChecksum

• Newoptionsmechanism(nextheader)

• Expandedaddress

• AddedFlowLabel


Version IHLType of Service (TOS)

Total Length



Source Address

Destination Address

Options

Version Traffic Class Flow Label


Source Address

Destination Address

Field name kept from IPv4 to IPv6

Fields not kept in IPv6

Name and position changed in IPv6

New field in IPv6

PhilosophyofChanges

• Don’tdealwithproblems:leavetoends

• Eliminatedfragmentation

• Eliminatedchecksum

• WhyretainTTL?

• Simplifyhandling

• Newoptionsmechanism(usesnextheaderapproach)

• Eliminatedheaderlength

• Whycouldn’tIPv4dothis?

• Providegeneralflowlabelforpacket

• Nottiedtosemantics

• Providesgreatflexibility

Traffic Class


IHLType of Service (TOS)

Total Length



Source Address

Destination Address

Options

Version Flow Label


Source Address

Destination Address

To Destination and Back (expanded)

Deal with Problems (greatly reduced)

Read Correctly (reduced)

Special Handling (Similar)

Version

lecture17-bgp-covid€¦ · Telecom LBL a.b.0.0/16 Cornell a.c.0.0/16 a...* is this way foo.com...

Documents

Transcript of lecture17-bgp-covid€¦ · Telecom LBL a.b.0.0/16 Cornell a.c.0.0/16 a...* is this way foo.com...

lecture17-bgp-covid€¦ · Telecom LBL a.b.0.0/16 Cornell a.c.0.0/16 a.*.*.* is this way foo.com...

Documents

Transcript of lecture17-bgp-covid€¦ · Telecom LBL a.b.0.0/16 Cornell a.c.0.0/16 a.*.*.* is this way foo.com...

lecture17-bgp-covid€¦ · Telecom LBL a.b.0.0/16 Cornell a.c.0.0/16 a...* is this way foo.com...

Transcript of lecture17-bgp-covid€¦ · Telecom LBL a.b.0.0/16 Cornell a.c.0.0/16 a...* is this way foo.com...