ip anycast and multicast; overlays and …...ip anycast and multicast; overlays and underlays...

IPANYCASTandMULTICAST;OVERLAYSandUNDERLAYS

READING:SECTION4.4,4.5,9.4.1

COS461:ComputerNetworksSpring2010(MW3:00‐4:20inCOS105)

MikeFreedmanhDp://www.cs.princeton.edu/courses/archive/spring10/cos461/

1

Outlinetoday•  IPAnycast•  MulNcastprotocols

–  IPMulNcastandIGMP–  SRM(ScalableReliableMulNcast)

–  PGM(PragmaNcGeneralMulNcast)

•  Overlaynetworks–  Tunnelsbetweenhostcomputers–  Buildnetworks“ontop”oftheInternet–  ProvidebeDercontrol,flexibility,QoS,isolaNon,…

•  Underlaytunnels–  AcrossrouterswithinAS–  Buildnetworks“below”IProute–  ProvidebeDercontrol,flexibility,QoS,isolaNon,…

2

LimitaNonsofDNS‐basedfailover

•  Failover/loadbalancingviamulNpleArecords ;; ANSWER SECTION: www.cnn.com. 300 IN A 157.166.255.19 www.cnn.com. 300 IN A 157.166.224.25 www.cnn.com. 300 IN A 157.166.226.26 www.cnn.com. 300 IN A 157.166.255.18

•  Ifserverfails,serviceunavailableforTTL– VerylowTTL:ExtraloadonDNS– Anyway,browserscacheDNSmappings

•  WhatifrootNSfails?AllDNSqueriestake>3s?3

MoNvaNonforIPanycast

•  Failureproblem:clienthasresolvedIPaddress– WhatifIPaddresscanrepresentmanyservers?

•  Load‐balancing/failoverviaIPaddr,ratherthanDNS

•  IPanycastissimplereuseofexisNngprotocols– MulNpleinstancesofaservicesharesameIPaddress

–  EachinstanceannouncesIPaddress/prefixinBGP/IGP–  RouNnginfrastructuredirectspacketstonearestinstanceoftheservice

•  CanusesameselecNoncriteriaasinstallingroutesintheFIB

– NospecialcapabiliNesinservers,clients,ornetwork4

Client Router1

IPanycastinacNon

ServerInstanceA

ServerInstanceB Router3

Router2

Router4

10.0.0.1

10.0.0.1

192.168.0.1

192.168.0.2

Announce10.0.0.1/32

Announce10.0.0.1/32

Router1

IPanycastinacNon

Client

ServerInstanceA

ServerInstanceB Router3

Router2

Router4

10.0.0.1

10.0.0.1

192.168.0.1

192.168.0.2

RouFngTablefromRouter1:

DesFnaFon Mask Next‐Hop Distance192.168.0.0 /29 127.0.0.1 010.0.0.1 /32 192.168.0.1 110.0.0.1 /32 192.168.0.2 2

Client Router1

IPanycastinacNon

ServerInstanceA

ServerInstanceB Router3

Router2

Router4

10.0.0.1

10.0.0.1

192.168.0.1

192.168.0.2

DNSlookupforhDp://www.server.com/producesasingleanswer:

www.server.com.INA10.0.0.1

Router1

IPanycastinacNon

Client

ServerInstanceA

ServerInstanceB Router3

Router2

Router4

10.0.0.1

10.0.0.1

192.168.0.1

192.168.0.2

RouFngTablefromRouter1:

DesFnaFon Mask Next‐Hop Distance192.168.0.0 /29 127.0.0.1 010.0.0.1 /32 192.168.0.1 110.0.0.1 /32 192.168.0.2 2

Router1

IPanycastinacNon

Client

ServerInstanceA

ServerInstanceB Router3

Router2

Router4

10.0.0.1

10.0.0.1

192.168.0.1

192.168.0.2

RouFngTablefromRouter1:

DesFnaFon Mask Next‐Hop Distance192.168.0.0 /29 127.0.0.1 010.0.0.1 /32 192.168.0.1 110.0.0.1 /32 192.168.0.2 2

Router1

IPanycastinacNon

Client

ServerInstanceA

ServerInstanceB Router3

Router2

Router4

10.0.0.1

10.0.0.1

192.168.0.1

192.168.0.2

RouFngTablefromRouter1:

DesFnaFon Mask Next‐Hop Distance192.168.0.0 /29 127.0.0.1 010.0.0.1 /32 192.168.0.1 110.0.0.1 /32 192.168.0.2 2

Router1

IPanycastinacNon

Client Server

Router3

Router2

Router4

10.0.0.1

192.168.0.1

192.168.0.2

RouFngTablefromRouter1:

DesFnaFon Mask Next‐Hop Distance192.168.0.0 /29 127.0.0.1 010.0.0.1 /32 192.168.0.1 110.0.0.1 /32 192.168.0.2 2

Fromclient/routerperspecNve,topologycouldaswellbe:

DownsidesofIPanycast•  ManyTier‐1ISPsingressfilterprefixes>/24

–  Publisha/24togeta“single”anycastedaddress:PooruNlizaNon•  Scalespoorlywiththe#anycastgroups

–  EachgroupneedsentryinglobalrouNngtable•  Nottrivialtodeploy

–  ObtainanIPprefixandASnumber;speakBGP

•  SubjecttothelimitaNonsofIProuNng–  NonoNonofloadorotherapplicaNon‐layermetrics–  ConvergenceNmecanbeslow(asBGPorIGPconvergence)

•  Failoverdoesn’treallyworkwithTCP–  TCPisstateful;otherserverinstanceswilljustrespondwithRSTs–  Anycastmayreacttonetworkchanges,eventhoughserveronline

•  Rootnameservers(UDP)areanycasted,liDleelse 12

MulNcastprotocols

13

MulNcasNngmessages•  SimpleapplicaNonmulNcast:Iteratedunicast

–  Clientsimplyunicastsmessagetoeveryrecipient–  Pros:simpletoimplement,nonetworkmodificaNons

–  Cons:O(n)workonsender,network•  AdvancedoverlaymulNcast(“peer‐to‐peer”)

–  Buildreceiver‐driventree–  Pros:Scalable,nonetworkmodificaNons

–  Cons:O(logn)workonsender,network;complextoimplement•  IPmulNcast

–  Embedreceiver‐driventreeinnetworklayer–  Pros:O(1)workonclient,O(#receivers)onnetwork–  Cons:requiresnetworkmodificaNons;scalabilityconcerns?

14

IPMulNcast•  SimpletouseinapplicaNons

– MulNcast“group”definedbyIPmulNcastaddress•  IPmulNcastaddresseslooksimilartoIPunicastaddrs•  224.0.0.0to239.255.255.255(RPC3171)

–  265MmulNcastgroupsatmost

– Besteffortdeliveryonly•  SenderissuessingledatagramtoIPmulNcastaddress•  Routersdeliverypacketstoallsubnetworksthathaveareceiver“belonging”tothegroup

•  Receiver‐drivenmembership– Receiversjoingroupsbyinformingupstreamrouters–  InternetGroupManagementProtocol(v3:RFC3376)

15

IGMPv1•  TwotypesofIGMPmsgs(bothhaveIPTTLof1)

– Hostmembershipquery:Routersquerylocalnetworkstodiscoverwhichgroupshavemembers

– Hostmembershipreport:Hostsreporteachgroup(e.g.,mulNcastaddr)towhichbelong,bybroadcastonnetinterfacefromwhichquerywasreceived

•  Routersmaintaingroupmembership– HostsendersanIGMP“report”tojoinagroup

– MulNcastroutersperiodicallyissuehostmembershipquerytodeterminelivenessofgroupmembers

– Note:Noexplicit“leave”messagefromclients16

IGMP

•  IGMPv2added:–  IfmulNplerouters,onewithlowestIPelectedquerier

– Explicitleavemessagesforfasterpruning– Group‐specificquerymessages

•  IGMPv3added:– Sourcefiltering:JoinspecifiesmulNcast“onlyfrom”or“allbutfrom”specificsourceaddresses

17

IGMP

•  Parameters– Maximumreportdelay:10sec– Queryinternaldefault:125sec– Time‐outinterval:270sec

•  2*(queryinterval+maxdelay)

•  QuesNons–  IsaroutertrackingeachaDachedpeer?– Shouldclientsrespondimmediatelytomembershipqueries?

– Whatiflocalnetworksarelayer‐twoswitched?

18

Sofar,we’vebeenbest‐effortIPmulNcast…

19

ChallengesforreliablemulNcast

•  Ack‐implosionifalldesNnaNonsackatonce

•  Sourcedoesnotknow#ofdesNnaNons•  Howtoretransmit?

– Toall?OnebadlinkeffectsenNregroup– Onlywherelosses?Lossnearsendermakesretransmissionasinefficientasreplicatedunicast

•  Oncesizefitsall?–  Heterogeneity:receivers,links,groupsizes–  NotallmulNcastapplicaNonsneedreliabilityofthetypeprovidedbyTCP.Somecantoleratereordering,delay,etc.

20

ScalableReliableMulNcast•  Receivesallpacketsorunrecoverabledataloss•  DatapacketssentviaIPmulNcast

–  ODATAincludessequencenumbers

•  Uponpacketfailure:–  ReceivermulNcastsaNAK

•  …orsendsNAKtosender,whomulNcastsaNAKconfirmaNon(NCF)

–  ScalethroughNAKsuppression•  …ifreceivedaNAKorNCF,don’tNAKyourself•  Whatdoweneedtodotogetadequatesuppression?

–  AddrandomdelaysbeforeNAK’ing–  ButwhatifthemulNcastgroupgrowsbig?

–  Repairthroughpacketretransmission(RDATA)•  FrominiNalsender•  Fromdesignatedlocalrepairer(DLR–IETFlovesacronyms!)

21

PragmaNcGeneralMulNcast(RFC3208)

•  SimilarapproachasSRM:IPmulNcast+NAKs– …butmoretechniquesforscalability

•  HierarchyofPGM‐awarenetworkelements– NAKsuppression:SimilartoSRM

– NAKeliminaNon:SendatmostoneNAKupstream•  Orcompletelyhandlewithlocalrepair!

– Constrainedforwarding:RepairdatacanbesuppresseddownstreamifnoNAKseenonthatport

– Forward‐errorcorrecNon:ReduceneedtoNAK

•  WorkswhenonlysenderismulNcast‐able22

OverlayNetworks

23

OverlayNetworks

24

OverlayNetworks

25

Focus at the application level

IPTunnelingtoBuildOverlayLinks

•  IPtunnelisavirtualpoint‐to‐pointlink–  Illusionofadirectlinkbetweentwoseparatednodes

•  EncapsulaNonofthepacketinsideanIPdatagram– NodeBsendsapackettonodeE– …containinganotherpacketasthepayload

26

A B E F tunnel Logical view:

Physical view: A B E F

TunnelsBetweenEndHosts

27

A

C

B

Src: A Dest: B

Src: A Dest: B

Src: A Dest: C

Src: A Dest: B

Src: C Dest: B

OverlayNetworks

•  Alogicalnetworkbuiltontopofaphysicalnetwork–  Overlaylinksaretunnelsthroughtheunderlyingnetwork

•  Manylogicalnetworksmaycoexistatonce–  Overthesameunderlyingnetwork

–  AndprovidingitsownparNcularservice•  Nodesareovenendhosts

–  AcNngasintermediatenodesthatforwardtraffic–  Providingaservice,suchasaccesstofiles

•  Whocontrolsthenodesprovidingservice?–  Thepartyprovidingtheservice–  DistributedcollecNonofendusers

28

OverlaysforIncrementalDeployment

29

UsingOverlaystoEvolvetheInternet

•  Internetneedstoevolve–  IPv6– Security– Mobility– MulNcast

•  But,globalchangeishard– CoordinaNonwithmanyASes– “Flagday”todeployandenablethetechnology

•  Instead,beDertoincrementallydeploy– Andfindwaystobridgedeploymentgaps

30

6Bone:DeployingIPv6overIP4

31

A B E F

IPv6 IPv6 IPv6 IPv6

tunnel Logical view:

Physical view: A B E F

IPv6 IPv6 IPv6 IPv6

C D

IPv4 IPv4

Flow: X Src: A Dest: F

data

Flow: X Src: A Dest: F

data

Flow: X Src: A Dest: F

data

Src:B Dest: E

Flow: X Src: A Dest: F

data

Src:B Dest: E

A-to-B: IPv6

E-to-F: IPv6 B-to-C:

IPv6 inside IPv4

B-to-C: IPv6 inside IPv4

SecureCommunicaNonOverInsecureLinks

•  Encryptpacketsatentryanddecryptatexit•  Eavesdroppercannotsnoopthedata•  …ordeterminetherealsourceanddesNnaNon

32

CommunicaNngWithMobileUsers•  AmobileuserchangeslocaNonsfrequently

–  So,theIPaddressofthemachinechangesoven

•  TheuserwantsapplicaNonstoconNnuerunning–  So,thechangeinIPaddressneedstobehidden

•  SoluNon:fixedgatewayforwardspackets–  GatewayhasafixedIPaddress–  …andkeepstrackofthemobile’saddresschanges

33gateway www.cnn.com

MBone:MulNcastBackbone•  Acatch‐22fordeployingmulNcast

–  Routervendorswouldn’tsupportIPmulNcast–  …sincetheyweren’tsureanyonewoulduseit–  And,sinceitdidn’texist,nobodywasusingit

•  Idea:sovwareimplemenNngmulNcastprotocols–  Andunicasttunnelstotraversenon‐parNcipants

34

Wesawtunneling“ontopof”IP.Whatabouttunneling“below”IP?

Introducing

MulN‐ProtocolLabelSwitching

(MPLS)

35

MPLSOverview

•  Mainidea:Virtualcircuit–  PacketsforwardedbasedonlyoncircuitidenNfier

Destination

Source 1

Source 2

36

Router can forward traffic to the same destination on different interfaces/paths.

MPLSOverview

•  Mainidea:Virtualcircuit–  PacketsforwardedbasedonlyoncircuitidenNfier

Destination

Source 1

Source 2

Router can forward traffic to the same destination on different interfaces/paths.

37

CircuitAbstracNon:LabelSwapping

•  Label‐switchedpaths(LSPs):Pathsare“named”bythelabelatthepath’sentrypoint

•  Ateachhop,MPLSrouters:–  Uselabeltodetermineoutgoinginterface,newlabel–  Thus,push/pop/swapMPLSheadersthatencapsulateIP

•  LabeldistribuFonprotocol:responsiblefordisseminaNngsignallinginformaNon

A 1 2

3 A 2 D

Tag Out New

D

38

Reconsidersecurityproblem

39

Layer3VirtualPrivateNetworks

•  PrivatecommunicaNonsoverapublicnetwork

•  Asetofsitesthatareallowedtocommunicatewitheachother

•  DefinedbyasetofadministraNvepolicies– DeterminebothconnecNvityandQoSamongsites– EstablishedbyVPNcustomers

– Onewaytoimplement:BGP/MPLSVPN(RFC2547)

Layer3BGP/MPLSVPNs

•  IsolaFon:MulNplelogicalnetworksoverasingle,sharedphysicalinfrastructure

•  Tunneling:Keepingroutesoutofthecore

VPN A/Site 1

VPN A/Site 2

VPN A/Site 3

VPN B/Site 2

VPN B/Site 1

VPN B/Site 3

CEA1

CEB3

CEA3

CEB2

CEA2 CE1B1

CE2B1

PE1

PE2

PE3

P1

P2

P3

10.1/16

10.2/16

10.3/16

10.1/16 10.2/16

10.4/16

BGP to exchange routes

MPLS to forward traffic

41

High‐LevelOverviewofOperaNon

•  IPpacketsarriveatprovideredgerouter(PE)

•  DesNnaNonIPlookedupinforwardingtable–MulNple“virtual”forwardingtables

•  Datagramsenttocustomer’snetworkusingtunneling(i.e.,anMPLSlabel‐switchedpath)

42

PE1

PE2

PE3

VirtualRouNngandForwarding

•  Separatetablespercustomerateachrouter– RFC2547:RouteDisNnguishers

10.0.1.0/24 RD: Purple

10.0.1.0/24 RD: Blue

10.0.1.0/24

10.0.1.0/24

Customer 1

Customer 2

Customer 2

Customer 1

43

ForwardinginBGP/MPLSVPNs

•  Step1:Packetarrivesatincominginterface

– SiteVRFdeterminesBGPnext‐hopandLabel#2

IP Datagram Label 2

•  Step2:BGPnext‐hoplookup,addcorrespondingLSP(alsoatsiteVRF)

IP Datagram Label 2

Label 1

44

Forwarding•  PEandProutershaveBGPnext‐hopreachabilitythroughthebackboneIGP

•  LabelsaredistributedthroughLDP(hop‐by‐hop)correspondingtoBGPNext‐Hops

•  Two‐LabelStackisusedforpacketforwarding•  ToplabelindicatesNext‐Hop(interiorlabel)•  Secondlabelindicatesoutgoinginterface/VRF(exteriorlabel)

IP Datagram Label 2

Label 1

Layer 2 Header

Corresponds to LSP of BGP next-hop (PE)

Corresponds to VRF/interface at exit

45

Forwarding

VPN A/Site 1

VPN A/Site 2

VPN A/Site 3

VPN B/Site 2

VPN B/Site 1

VPN B/Site 3

CEA1

CEB3

CEA3

CEB2

CEA2 CE1B1

CE2B1

PE1

PE2

PE3

P1

P2

P3

10.1/16

10.2/16

10.3/16

10.1/16

10.2/16

10.4/16

46

IP Datagram Label 2

Label 1

Layer 2 Header

Outlinetoday•  IPAnycast•  MulNcastprotocols

–  IPMulNcastandIGMP–  SRM(ScalableReliableMulNcast)

–  PGM(PragmaNcGeneralMulNcast)

•  Overlaynetworks–  Tunnelsbetweenhostcomputers–  Buildnetworks“ontop”oftheInternet–  ProvidebeDercontrol,flexibility,QoS,isolaNon,…

•  Underlaytunnels–  AcrossrouterswithinAS–  Buildnetworks“below”IProute–  ProvidebeDercontrol,flexibility,QoS,isolaNon,…

47