12.07.2015 Views

Multicast tutorial PDF - Garr

Multicast tutorial PDF - Garr

Multicast tutorial PDF - Garr

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

AgendaIntroduction<strong>Multicast</strong> addressingGroup Membership ProtocolPIM-SM / SSMMSDPMBGP2


•Introduction•<strong>Multicast</strong> addressing•Group Membership Protocol•PIM-SM / SSM•MSDP•MBGP3


A bit of historyIn 1995 the first mcast network was born: MBoneDVMRP (Distance Vector <strong>Multicast</strong> Routing Protocol) wasthe protocol usedDVMRP subnetworks was interconnected through the unicast Internetinfrastructure with tunnelsFlood and Prune technologyVery successful in academic circles6


The evolutionPIM Dense modeFlood and Prune behavior very inefficientCan cause problems in certain network topologiesCreates (S, G) state in EVERY routerEven when there are no receivers for the trafficComplex Assert mechanismTo determine which router in a LAN will forward the trafficNo support for shared trees8


The evolutionPIM Sparse mode(‏RP‏)‏ Must configure a Rendezvous Point(‏Router Statically (on every(‏automatically Using Auto-RP or BSR (Routers learn RPVery efficientUses Explicit Join modelTraffic only flows to where it’s neededRouter state only created along flow pathsScales better than dense modeWorks for both sparsely or densely populated networks9


PIM Dense Mode OverviewInitial FloodingSource<strong>Multicast</strong> Packets(S, G) State created inevery router in the network!Receiver10


PIM Dense Mode OverviewPruning Unwanted TrafficSource<strong>Multicast</strong> PacketsPrune MessagesReceiver11


PIM Dense Mode OverviewResults After PruningSource<strong>Multicast</strong> Packets(S, G) State still exists inevery router in the network!Flood & Prune processrepeats every 3 minutes!!!Receiver12


(S,G) notation• For every multicast source there must be twopieces of information: the source IP address,S, and the group address, G.This is generally expressed as (S,G).Also commonly used is (*,G) - every sourcefor a particular group.The router creates a table with the entries(*,G),(S,G).13


IP <strong>Multicast</strong> building blocksThe SENDERS send<strong>Multicast</strong> Addressing - rfc1700(‏‎239.255.255.255‎ (224.0.0.0 - D classThe RECEIVERS inform the routers what they want to receiveInternet Group Management Protocol (IGMP) - rfc2236 -> version 2The routers make sure the STREAMS make it to the correct receiving nets.(‏PIM-SM/SSM‏)‏ <strong>Multicast</strong> Routing ProtocolsRPF (reverse path forwarding) – against source address14


<strong>Multicast</strong> Forwarding•<strong>Multicast</strong> Routing is backwards from Unicast RoutingUnicast Routing is concerned about where thepacket is going.<strong>Multicast</strong> Routing is concerned about where thepacket came from.•<strong>Multicast</strong> Routing uses "Reverse Path Forwarding"15


<strong>Multicast</strong> Forwarding(‏RPF‏)‏ Reverse Path ForwardingWhat is RPF?A router forwards a multicast datagram only if received on the upstream interface to the source (i.e. it follows the distribution tree).The RPF CheckThe source IP address of incoming multicast packets are checkedagainst a unicast routing table.If the datagram arrived on the interface specified in therouting table for the source address; then the RPF checksucceeds.Otherwise, the RPF Check fails.16


<strong>Multicast</strong> Forwarding•<strong>Multicast</strong> uses unicast routes to determine path back tosource•RPF checks ensures packets won’t loop•RPF checks are performed against routing table bydefault•If multicast path is different from unicast path, then amulticast table will exist. It will be use for RPF check.•Routes contain incoming interfacePackets matching are forwardedPackets mis-matching are dropped17


<strong>Multicast</strong> ForwardingExample: RPF CheckingSource151.10.3.21RPF Check FailsPacket arrived on wrong interface!Mcast Packets18


<strong>Multicast</strong> Distribution TreesShortest Path or Source Based Distribution TreeSourceState Information:(‏G ,S)S = SourceG = GroupGroup Member 1Group Member 219


<strong>Multicast</strong> Distribution TreesShared or Core Based Distribution TreeSource 1CoreSource 2State Information:(‏G‏,*)‏* = Any SourceG = GroupGroup Member 1Group Member 220


<strong>Multicast</strong> Distribution Trees•Source or Shortest Path trees(‏S,G‏)‏ More resource intensive; requires more statesYou get optimal paths from source to all receivers, minimizesdelayBest for one-to-many distribution• Shared or Core Based treesUses less resources; less memory (*,G)You can get suboptimal paths from source to all receiversDepending on topologyThe RP (core) itself and its location may affect performanceBest for many-to-many distribution(‏PIM-SM‏)‏ May be necessary for source discovery21


•Introduction•<strong>Multicast</strong> addressing•Group Membership Protocol•PIM-SM / SSM•MSDP•MBGP22


<strong>Multicast</strong> AddressingIP <strong>Multicast</strong> Group Addresses224.0.0.0–239.255.255.255Class “D” Address SpaceHigh order bits of 1st Octet = “1110”TTL value defines scope and limits distributionIP multicast packet must have TTL > interface TTL or it isdiscardedvalues are: 0=host, 1=network, 32=same site, 64=sameregion, 128=same continent, 255=unrestrictedNo longer recommended as a reliable scoping mechanism23


<strong>Multicast</strong> AddressingAdministratively Scoped Addresses – RFC 2365239.0.0.0–239.255.255.255Private address spaceSimilar to RFC 1918 unicast addressesNot used for global Internet trafficUsed to limit “scope” of multicast trafficSame addresses may be in use at different locations fordifferent multicast sessionsExamplesSite-local scope: 239.253.0.0/16Organization-local scope: 239.192.0.0/1424


<strong>Multicast</strong> AddressingGLOP addressesProvides globally available private Class D space233.x.x/24 per AS numberRFC2770How?AS number = 16 bitsInsert the 16 ASN into the middle two octets of 233/8Online Glop Calculator:www.shepfarm.com/multicast/glop.html25


<strong>Multicast</strong> Addressinghttp://www.iana.org/assignments/multicast-addressesExamples of Reserved & Link-local Addresses224.0.0.0 - 224.0.0.255 reserved & not forwarded239.0.0.0 - 239.255.255.255 Administrative Scoping232.0.0.0 - 232.255.255.255 Source-Specific <strong>Multicast</strong>224.0.0.1 - All local hosts224.0.0.2 - All local routers224.0.0.4 - DVMRP224.0.0.5 - OSPF224.0.0.6 - Designated Router OSPF224.0.0.9 - RIP2224.0.0.13 - PIM224.0.0.15 - CBT224.0.0.18 - VRRP26


•Introduction•<strong>Multicast</strong> addressing•Group Membership Protocol•PIM-SM / SSM•M-BGP•MSDP27


(‏IGMP‏)‏ Internet Group Membership ProtocolHow hosts tell routers about group membershipRouters solicit group membership from directly connected hostsRFC 2236 specifies version 2 of IGMPSupported on every OSIGMP version 3 is the latest versionRFC 3376(!‏SSM‏)‏ provides source include-list capabilitiesSupport?Unix latest versions, Window XP, Vista28


IGMPv2 Protocol Flow - Join a GroupI wantto JOIN!230.0.0.1Router adds groupForwards stream230.0.0.1230.0.0.1I want 230.0.0.1Router triggers group membership request to PIM.(‏‎1‎ Hosts can send unsolicited join membership messages – called reports in the RFC (usually more thanOr hosts can join by responding to periodic query from router29


IGMPv2 Protocol Flow - QuerierStillinterested?(‏query (generalYes, me!224.0.0.1230.0.0.1I want 230.0.0.1230.0.0.1 group230.0.0.1224.0.0.1(‏group(s Hosts respond to query to indicate (new or continued) interest inonly 1 host should respond per groupHosts fall into idle-member state when same-group report heard.After 260 sec with no response, router times out group30


IGMPv2 Protocol Flow - Leave a GroupAnyone stillwant this group?224.0.0.1I wantto leave!224.0.0.2I don’t want230.0.0.1 anymore224.0.0.1230.0.0.1 groupHosts send leave messages to all routers group indicatinggroup they’re leaving.Router follows up with 2 group-specific queries messages31


IGMPv3RFC 3376Enables hosts to listen only to a specified subset of thehosts sending to the groupSource = 1.1.1.1Group = 224.1.1.1R1R2Source = 2.2.2.2Group = 224.1.1.1Video ServerVideo ServerH1 wants to receive from S =1.1.1.1 but not from S = 2.2.2.2With IGMPv3, specific sourcescan be pruned back - S =2.2.2.2 in this casedraft-holbrook-idmr-igmpv3-ssm-01.txtR3H1 - Member of 224.1.1.1IGMPv3: MODE_IS_INCLUDEJoin 1.1.1.1, 224.1.1.132


IGMP EnhancementsIGMP Version 2multicast router with lowest IP address is elected querierGroup-Specific Query message is defined. Enables router totransmit query to specific multicast address rather than to the"all-hosts" address of 224.0.0.1Leave Group message is defined. Last host in group wishes toleave, it sends Leave Group message to the "all-routers"address of 224.0.0.2. Router then transmits Group-Specificquery and if no reports come in, then the router removes thatgroup from the list of group memberships for that interfaceIGMP Version 3Group-Source Report message is defined. Enables hosts tospecify which senders it can receive or not receive data from.Group-Source Leave message is defined. Enables host tospecify the specific IP addresses of a (source,group) that itwishes to leave.33


•Introduction•<strong>Multicast</strong> addressing•Group Membership Protocol•PIM-SM / SSM•MSDP•MBGP34


PIM-SMProtocol Independent <strong>Multicast</strong> - sparse modedraft-ietf-pim-sm-v2-new-10.txtObsoletes RFC 2362BSR removed from PIM spec.explicit join:assumes everyone does not want the datauses unicast routing tablefor RPF checkingdata and joins are forwarded to RPfor initial rendezvousall routers in a PIM domainmust have RP mappingwhen load exceeds thresholdforwarding swaps to shortest path tree(‏packet (default is firststate increases (not everywhere)as number of sources and number of groups increasesource-tree state is refreshedwhen data is forwarded and with Join/Prune control messages35


PIM Sparse-Mode :RPAllows Source Trees or Shared Trees(‏RP‏)‏ Rendezvous PointMatches senders with receiversProvides network source discoveryRoot of shared treeTypically use shared tree to bootstrap source treeRP’s can be learned via:Static configuration – RECOMMENDED(‏V2‎ Auto-RP (V1 &(‏V2‎‏)‏ Bootstrap Router36


PIM-SM Shared Tree JoinRP(*, G) JoinShared Tree(*, G) State created onlyalong the Shared Tree.Receiver37


PIM-SM Sender RegistrationSourceRPTraffic FlowShared TreeSource Tree(S, G) Register(S, G) Join(‏unicast‏)‏ Receiver(S, G) State created onlyalong the Source Tree.38


PIM-SM Sender RegistrationSourceRPTraffic Flow(S, G) traffic begins arriving atthe RP via the Source tree.Shared TreeSource Tree(S, G) Register(S, G) Register-Stop(‏unicast‏)‏(‏unicast‏)‏ReceiverRP sends a Register-Stop backto the first-hop router to stopthe Register process.39


PIM-SM Sender RegistrationSourceRPTraffic FlowShared TreeSource TreeSource traffic flows nativelyalong SPT to RP.From RP, traffic flows downthe Shared Tree to Receivers.Receiver40


PIM-SM SPT SwitchoverSourceRPTraffic FlowShared TreeSource Tree(S, G) JoinReceiverLast-hop router joins the SourceTree.Additional (S, G) State is createdalong new part of the Source Tree.41


PIM-SM SPT SwitchoverSourceRPTraffic FlowShared TreeSource Tree(S, G)RP-bit PruneReceiverTraffic begins flowing down thenew branch of the Source Tree.Additional (S, G) State is createdalong along the Shared Tree toprune off (S, G) traffic.42


PIM-SM SPT SwitchoverSourceRPTraffic FlowShared TreeSource Tree(S, G) Traffic flow is now prunedoff of the Shared Tree and isflowing to the Receiver via theSource Tree.Receiver43


PIM-SM SPT SwitchoverSourceRPTraffic FlowShared TreeSource Tree(S, G) PruneReceiver(S, G) traffic flow is no longerneeded by the RP so it Prunes theflow of (S, G) traffic.44


PIM-SM SPT SwitchoverSourceRPTraffic FlowShared TreeSource Tree(S, G) Traffic flow is now onlyflowing to the Receiver via asingle branch of the Source Tree.Receiver45


PIM-SM ConfigurationRP Mapping optionsStatic RPRecommendedEasy transition to Anycast-RPAllows for a hierarchy of RPsAuto-RP(‏slow‏)‏ Fixed convergence timersBSRMust flood RP mapping trafficNo longer in the PIM spec.(‏slow‏)‏ Fixed convergence timersAllows for a hierarchy of RPs46


PIM-SSMNo shared treesNo register packetsNo RP required(‏MSDP‏)‏ No RP-to-RP source discoveryRequires IGMP include-source list – IGMPv3(‏page Host must learn of source address out-of-band (webRequires host-to-router source AND group requestHard-coded behavior in 232/8Configurable to expand range47


PIM-SSMSourceRPIGMPv3 host report(S, G) JoinSource TreeTraffic FlowReceiverReceiver announces desireto join group G AND sourceS with an IGMPv3 include-list.list.Last-hop router joins the SourceTree.(S,G) state is built between thesource and the receiver.48


PIM-SSMSourceRPData flows down the source treeto the receiver.Source TreeTraffic FlowReceiver49


•Introduction•<strong>Multicast</strong> addressing•Group Membership Protocol•PIM-SM / SSM•MSDP•MBGP50


MSDP<strong>Multicast</strong> Source Discovery ProtocolRFC 3618(‏RP(s Allows each domain to control its ownInterconnect RPs between domains(‏SAs‏)‏ with TCP connections to pass source active messagesCan also be used within a domain(‏Anycast-RP‏)‏ to provide RP redundancyRPs send SA messagesfor internal sources to MSDP peersSAs are Peer-RPF checkedbefore accepting or forwardingRPs learn about external sources via SA messagesmay trigger (S,G) joins on behalf of local receiversMSDP connections typically parallel MBGP connections51


MSDP Operation(‏domain MSDP peers (inter or intra(‏LISTENS (TCP port 639 with higher IP addr“FLOOD & join”SA (source active) packets periodically sent to MSDP peers indicating:source address of active streamsgroup address of active streamsIP address of RP originating the SAonly originate SA’s for its sources within its domaininterested parties can send PIM JOIN’s(‏trees towards source (creates inter-domain source52


MSDP Source Active MessagesInitial SA message sent when source first registersMay optionally encapsulate first data packetSubsequent SA messages periodically refreshed every 30 seconds aslong as source still active by originating RPOther MSDP peers don’t originate this SA but only forward it if receivedSA messages cached on router for new group members that may joinReduced join latencyPrevent SA storm propagation53


MSDP OverviewMSDP PeersDomain ESource ActiveMessagesSADomain CSARPrDomain BSARPSASA(‏‎224.2.2.2‎ (*, JoinRPSARPSA Message192.1.1.1, 224.2.2.2SAsRPDomain ASA Message192.1.1.1, 224.2.2.2Domain DRegister192.1.1.1, 224.2.2.254


MSDP OverviewMSDP PeersDomain BRPDomain CRPJoin(‏‎224.2.2.2‎ ,S)Domain ERPrsRPDomain ARPDomain D55


MSDP OverviewMSDP PeersDomain E<strong>Multicast</strong> TrafficDomain CRPrRPDomain BRPRPDomain DsRPDomain A56


MSDP Peers•MSDP establishes a neighbor relationship between MSDP peersPeers connect using TCP port 639•MSDP peers may run mBGPMay be an MBGP peer, a BGP peer or bothRequired for peer-RPF checking of the RP addressin the SA to prevent SA loopingException:BGP is unnecessary(‏default-peer‏)‏ when peering with only a single MSDP peer57


RPF-peer Rules•Skip RPF Check and accept SA if:Sending MSDP peer is default-peerSending MSDP peer = Mesh-Group peer•Otherwise, being a MSDP peer, the RPF-peer will be:The originating RP.The eBGP next-hop toward the originating RP.The iBGP peer that advertise the route or is the IGP next-hoptoward the originating RP.The one with the highest IP address of all the MSDP peers inthe AS path toward the originating RP.The static RPF-peer.58


MSDP with SSM – Unnecessary!ASM MSDP Peers(‏SSM (irrelevant toDomain BDomain CRPDomain ERPrReceiver learnsS AND G out ofband; ie Web pageRPRPDomain DSource in 232/8sRPDomain A59


MSDP with SSM – Unnecessary!ASM MSDP Peers(‏SSM (irrelevant toDomain BDomain CRPDomain ERPrReceiver learnsS AND G out ofband; ie Web pageRPRPDomain DSource in 232/8sRPDomain A60


MSDP Application: Anycast-RP•RFC 3446•Within a domain, deploy more than one RP for thesame group range•Sources from one RP are known to other RPs usingMSDP•Give each RP the same /32 IP address•Sources and receivers use closest RP, as determined bythe IGP•Used intra-domain to provide redundancy and RP loadsharing, when an RP goes down, sources and receiversare taken to new RP via unicast routingFast convergence!61


Anycast-RPRP1 – lo0X.X.X.X10.0.0.1RecSrcRecMSDPRecRecSrcRP2 – lo0Y.Y.Y.Y10.0.0.162


Anycast-RPSrcRecRP1 – lo0X.X.X.X10.0.0.1XRecRecRecSrcRP2 – lo0Y.Y.Y.Y10.0.0.163


•Introduction•<strong>Multicast</strong> addressing•Group Membership Protocol•PIM-SM / SSM•MSDP•MBGP64


MBGP Overview•Multiprotocol Extensions to BGP (RFC 2858).•Tag unicast prefixes as multicast source prefixes for intradomainmcast routing protocols to do RPF checks.•WHY? Allows for interdomain RPF checking where unicastand multicast paths are non-congruent.•DO I REALLY NEED IT?YES, if:NO, if:ISP to ISP peeringMultiple-homed networksYou are single-homed65


MBGP Overview•MBGP: Multiprotocol BGP(‏networks (multicast BGP in multicast(‏BGP Defined in RFC 2858 (extensions toCan carry different route types for different purposesUnicast<strong>Multicast</strong>Both route types carried in same BGP sessionDoes not propagate multicast state informationSame path selection and validation rulesAS-Path, LocalPref, MED, …66


MBGP Overview•New multiprotocol attributes:MP_REACH_NLRIUsed to advertise one or more routes to a peer that shares thesame path attributeMP_UNREACH_NLRIUsed to indicate a previously route is no longer reachable•They include the next information:(‏IPv4‎‏)‏ Address Family Information (AFI) = 1(‏unicast Sub-AFI = 1 (NLRI is used for(‏check Sub-AFI = 2 (NLRI is used for multicast RPFSub-AFI = 3 (NLRI is used for both unicast and multicast RPF(‏check•This information is used to build routing tables•Allows different policies and topologies between multicast and unicast67


MBGP—Capability Negotiation•RFC 2842•BGP routers establish BGP sessions through the OPENmessageOPEN message contains optional parametersBGP session is terminated if OPEN parameters are not recognised•MBGP peers use this procedure to determine if they supportMBGP and which AFIs and SAFIs support each oneIf there is no match, notification is sent and peering doesn’tcome upIf neighbor doesn’t include the capability parameters in open,session backs off and reopens with no capability parametersPeering comes up in unicast-only mode68


Summary•IGMP - Internet Group Management Protocol is used by hosts androuters to tell each other about group membership.•PIM-SM - Protocol Independent <strong>Multicast</strong>-Sparse Mode is used topropagate forwarding state between routers.•SSM - Source Specific <strong>Multicast</strong> utilizes a subset of PIM?s functionalityto guaranty source-only trees in the 232/8 range.•MBGP - Multiprotocol Border Gateway Protocol is used to exchangerouting information for interdomain RPF checking.•MSDP - <strong>Multicast</strong> Source Discovery Protocol is used to exchange ASMactive source information between RPs.69


SummaryISP Requirements•Current solution: MBGP + PIM-SM + MSDPEnvironment(‏internally‏)‏ ISPs run iMBGP and PIM-SMISPs multicast peer at a public interconnectDeploymentBorder routers run eMBGPThe interfaces on interconnect run PIM-SMRPs’ MSDP peering must be consistant with eMBGP peeringAll peers set a common distance for eMBGP70

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!