Introduction to IP Multicast David Meyer Cisco Systems - PowerPoint PPT Presentation

1 / 98
About This Presentation
Title:

Introduction to IP Multicast David Meyer Cisco Systems

Description:

... queries to make sure there are no members present before stopping to forward data for the group for that subnet Standard ... Internet Service Providers ... – PowerPoint PPT presentation

Number of Views:100
Avg rating:3.0/5.0
Slides: 99
Provided by: Manoj91
Category:

less

Transcript and Presenter's Notes

Title: Introduction to IP Multicast David Meyer Cisco Systems


1
Introduction to IP Multicast David
Meyer Cisco Systems
0940_03F8_c1 NW97_US_106
2
Agenda
  • IP Multicast Technology and Concepts
  • IP Multicast Host-to-Router Protocols
  • IP Multicast Routing Protocols
  • Protocol Independent MulticastPIM
  • General Multicast Concepts
  • Inter-domain Multicast Routing
  • Issues and Solutions

3
Introduction to Multicast
  • Why multicast?
  • When sending same data to multiple receivers
  • Better bandwidth utilization
  • Lesser host/router processing
  • Receivers addresses unknown
  • Applications
  • Video/audio conferencing
  • Resource discovery/service advertisement
  • Stock distribution
  • Eg. Vat, Vic, IP/TV, Pointcast

4
Unicast/Multicast
Unicast
Host
Router
Multicast
Host
Router
5
IP Multicast Service Model
  • RFC 1112
  • Each multicast group identified by a class D IP
    address
  • Members of the group could be present anywhere in
    the Internet
  • Members join and leave the group and indicate
    this to the routers
  • Senders and receivers are distinct i.e., a
    sender need not be a member
  • Routers listen to all multicast addresses and
    use multicast routing protocols to manage groups

6
IP Multicast Service Model (Cont.)
  • IP group addresses
  • Class D addresshigh-order 3 bits are set
    (224.0.0.0)
  • Range from 224.0.0.0 through 239.255.255.255
  • Well known addresses designated by IANA
  • Reserved use 224.0.0.0 through 224.0.0.255
  • 224.0.0.1all multicast systems on subnet
  • 224.0.0.2all routers on subnet
  • Transient addresses, assigned and reclaimed
    dynamically
  • Global scope 224.0.1.0-238.255.255.255
  • Limited scope 239.0.0.0-239.255.255.255
  • Site-local scope 239.253.0.0/16
  • Organization-local scope 239.192.0.0/14

7
IP Multicast Service Model (Cont.)
  • Mapping IP group addresses to data link multicast
    addresses
  • RFC 1112 defines OUI 0x01005e
  • Low-order 23-bits of IP address map into
    low-order 23 bits of IEEE address (eg.
    224.2.2.201005e.020202)
  • Ethernet and FDDI use this mapping
  • Token Ring uses functional address-c000.4000.0000

8
IP Multicast Service Model (Cont.)
Host-to-Router Protocols (IGMP)
Hosts
Routers
Multicast Routing Protocols (PIM)
9
Internet Group Management ProtocolIGMP
  • How hosts tell routers about group membership
  • Routers solicit group membership from directly
    connected hosts
  • RFC 1112 specifies first version of IGMP
  • IGMP v2 and IGMP v3 enhancements
  • Supported on UNIX systems, PCs, and MACs

0940_03F8_c1 NW97_US_106
9
10
Internet Group Management ProtocolIGMP
  • IGMP v1
  • Queries
  • Querier sends IGMP query messages to 224.0.0.1
    with ttl 1
  • One router on LAN is designated/elected to send
    queries
  • Query interval 60120 seconds
  • Reports
  • IGMP report sent by one host suppresses sending
    by others
  • Restrict to one report per group per LAN
  • Unsolicited reports sent by host, when it first
    joins the group

0940_03F8_c1 NW97_US_106
10
11
IGMPJoining a Group
224.2.0.1224.5.5.5
224.2.0.1
224.2.0.1
Host 1
Host 2
Host 3
Sends Reportto 224.5.5.5
Sends Reportto 224.2.0.1
Periodically SendsIGMP Query to 224.0.0.1
12
Internet Group Management ProtocolIGMP
  • IGMP v2
  • Host sends leave message if it leaves the group
    and is the last member (reduces leave latency
    in comparison to v1)
  • Router sends G-specific queries to make sure
    there are no members present before stoppingto
    forward data for the group for that subnet
  • Standard querier election
  • IGMP v3
  • In design phase
  • Enables to listen only to a specified subset of
    the hosts sending to the group

13
IGMPLeaving a Group
224.2.0.1
224.2.0.1
224.2.0.1
Host 1
Host 2
Host 3
Sends Reportfor 224.2.0.1
Sends Leavefor 224.5.5.5to 224.0.0.2
Sends Leavefor 224.2.0.1to 224.0.0.2
Sends Group SpecificIGMP Query to 224.2.0.1
Sends Group SpecificIGMP Query to 224.5.5.5
14
Multicast Routing Protocols(Reverse Path
Forwarding)
  • What is RPF?
  • A router forwards a multicast datagram if
    received on the interface used to send unicast
    datagrams to the source

Unicast
C
B
Source
Receiver
A
F
D
E
Multicast
15
Multicast Routing Protocols(Reverse Path
Forwarding)
  • If the RPF check succeeds, the datagram is
    forwarded
  • If the RPF check fails, the datagram is
    typically silently discarded
  • When a datagram is forwarded, it is sent out each
    interface in the outgoing interface list
  • Packet is never forwarded back out the RPF
    interface!

16
Multicast Routing ProtocolsCharacteristics
Shortest Path or Source Distribution Tree
Source
Notation (S, G) S Source G Group
E
C
Receiver 1
Receiver 2
17
Multicast Routing ProtocolsCharacteristics
Shared Distribution Tree
Source 1
Notation (, G) All Sources G
Group
Source 2
B
A
F
D (Shared Root)
E
C
Receiver 1
Receiver 2
18
Multicast Routing ProtocolsCharacteristics
  • Distribution trees
  • Source tree
  • Uses more memory O(S x G) but you get optimal
    paths from source to all receivers, minimizes
    delay
  • Shared tree
  • Uses less memory O(G) but you may get suboptimal
    paths from source to all receivers, may
    introduce extra delay
  • Protocols
  • PIM, DVMRP, MOSPF, CBT

19
Multicast Routing ProtocolsCharacteristics
  • Types of multicast protocols
  • Dense-mode
  • Broadcast and prune behavior
  • Similar to radio broadcast
  • Sparse-mode
  • Explicit join behavior
  • Similar to pay-per-view

20
Multicast Routing ProtocolsCharacteristics
  • Dense-mode protocols
  • Assumes dense group membership
  • Branches that are pruned dont get data
  • Pruned branches can later be grafted to reduce
    join latency
  • DVMRPDistance Vector Multicast Routing Protocol
  • Dense-mode PIMProtocol Independent Multicast

21
Multicast Routing ProtocolsCharacteristics
  • Sparse-mode protocols
  • Assumes group membership is sparsely populated
    across a large region
  • Uses either source or shared distribution trees
  • Explicit join behaviorassumes no one wants the
    packet unless asked
  • Joins propagate from receiver to source or
    Rendezvous Point (Sparse mode PIM) or Core (Core
    Based Tree)

22
DVMRP
  • Broadcast and prune
  • Source trees created on demand based on RPF rule
  • Uses own routing table
  • e.g., use of poison reverse
  • Tunnels to overcome incongruent topologies
  • Many implementations
  • mrouted, Bay,
  • Cisco
  • draft-ietf-idmr-dvmrp-v3-06.txt,ps

23
Dense Mode PIM
  • Broadcast and prune ideal for dense groups
  • Source trees created on demand based on RPF rule
  • If the source goes inactive, the tree is torn
    down
  • Fewer implementations than DVMRP
  • Draft draft-ietf-idmr-pim-dm-spec-05.txt

24
Dense Mode PIM
  • Branches that don't care for data are pruned
  • Grafts to join existing source tree
  • Uses asserts to determine forwarder for
    multi-access LAN
  • Prunes on non-RPF P2P links
  • Rate-limited prunes on RPF P2P links

25
Dense Mode PIM Example
Source
Receiver 2
Receiver 1
26
Dense Mode PIM Example
Source
Initial Flood of Dataand Creation of State
Receiver 2
Receiver 1
27
Dense Mode PIM Example
Source
Prune to Non-RPF Neighbor
Prune
Receiver 2
Receiver 1
28
Dense Mode PIM Example
Source
C and D Assert to DetermineForwarder for the
LAN, C Wins
Asserts
Receiver 2
Receiver 1
29
Dense Mode PIM Example
Source
I Gets Pruned Es Prune is Ignored Gs Prune is
Overridden
Prune
Join Override
Prune
Receiver 2
Receiver 1
30
Dense Mode PIM Example
Source
New Receiver, I Sends Graft
Graft
Receiver 2
Receiver 1
Receiver 3
31
Dense Mode PIM Example
Source
Receiver 2
Receiver 1
Receiver 3
32
Sparse Mode PIM
  • Explicit join model
  • Receivers join to the Rendezvous Point (RP)
  • Senders register with the RP
  • Data flows down the shared tree and goes only to
    places that need the data from the sources
  • Last hop routers can join source tree if the data
    rate warrants by sending joins to the source
  • RPF check for the shared tree uses the RP
  • RPF check for the source tree uses the source

33
Sparse Mode PIM
  • Only one RP is chosen for a particular group
  • RP statically configured or dynamically learned
    (Auto-RP, PIM v2 candidate RP advertisements)
  • Data forwarded based on the source state (S, G)
    if it exists, otherwise use the shared state (,
    G)
  • Draft draft-ietf-idmr-pim-sm-specv2-00.txt
  • Draft draft-ietf-idmr-pim-arch-04.txt

34
Sparse Mode PIM Example
Source
B
A
D
RP
E
C
Receiver 1
Receiver 2
35
Sparse Mode PIM Example
Receiver 1 Joins Group GC Creates (, G) State,
Sends(, G) Join to the RP
Source
B
A
D
RP
Join
E
C
Receiver 1
Receiver 2
36
Sparse Mode PIM Example
RP Creates (, G) State
Source
B
A
D
RP
E
C
Receiver 1
Receiver 2
37
Sparse Mode PIM Example
Source Sends DataA Sends Registers to the RP
Source
Register
B
A
D
RP
E
C
Receiver 1
Receiver 2
38
Sparse Mode PIM Example
RP de-encapsulates RegistersForwards Data Down
the Shared TreeSends Joins Towards the Source
Source
Join
Join
B
A
D
RP
E
C
Receiver 1
Receiver 2
39
Sparse Mode PIM Example
RP Sends Register-Stop OnceData Arrives Natively
Source
Register-Stop
B
A
D
RP
E
C
Receiver 1
Receiver 2
40
Sparse Mode PIM Example
C Sends (S, G) Joins to Join theShortest Path
(SPT) Tree
Source
B
A
D
RP
(S, G) Join
E
C
Receiver 1
Receiver 2
41
Sparse Mode PIM Example
When C Receives Data Natively,It Sends Prunes Up
the RP tree forthe Source. RP Deletes (S, G) OIF
andSends Prune Towards the Source
Source
(S, G) Prune
B
A
D
RP
(S, G) RP Bit Prune
E
C
Receiver 1
Receiver 2
42
Sparse Mode PIM Example
New Receiver 2 JoinsE Creates State and Sends
(, G) Join
Source
B
A
D
RP
(, G) Join
E
C
Receiver 1
Receiver 2
43
Sparse Mode PIM Example
C Adds Link Towards E to the OIFList of Both (,
G) and (S, G)Data from Source Arrives at E
Source
B
A
D
RP
E
C
Receiver 1
Receiver 2
44
Sparse Mode PIM Example
New Source Starts SendingD Sends Registers, RP
Sends JoinsRP Forwards Data to Receiversthrough
Shared Tree
Source
Register
Source 2
B
A
D
RP
E
C
Receiver 1
Receiver 2
45
Inter-domain Multicast Routing
1037_03F8_c2 NW98_US_114
46
Agenda
  • Introduction
  • First Some Basic Technology
  • Basic Host Model
  • Basic Router Model
  • Data Distribution Concepts
  • What Are the Deployment Obstacles
  • What Are the Non-technical Issues
  • What Are the Technical Scaling Issues

47
Agenda (Cont.)
  • Potential Solutions (Cisco Specific)
  • Multi-level RP, Anycast Clusters, MSDP
  • Using Directory Services
  • Industry Solutions
  • BGMP and MASC
  • Possible Deployment Scenarios
  • References

48
IntroductionLevel Set
  • This presentation focuses on large-scale
    multicast routing in the Internet
  • The problems/solutions presented are related to
    inter-ISP deployment of IP multicast
  • We believe the current set of deployed technology
    is sufficient for enterprise environments

49
IntroductionWhy Would You Want to Deploy IP
Multicast?
  • You dont want the same data traversing your
    links many times bandwidth saver
  • You want to join and leave groups dynamically
    without notifying all data sourcespay-per-view

50
IntroductionWhy Would You Want to Deploy IP
Multicast?
  • You want to discover a resource but dont know
    who is providing it or if you did, dont want to
    configure it expanding ring search
  • Reduce startup latency for subscribers

51
IntroductionWhy Would ISPs Want to Deploy IP
Multicast?
  • Internet Service Providers are seeing revenue
    potential for deploying IP multicast
  • Initial applications
  • Radio station transmissions
  • Real-time stock quote service
  • Future applications
  • Distance learning
  • Entertainment

52
Basic Host Model
  • Strive to make the host model simple
  • When sourcing data, just send the data
  • Map network layer address to link layer address
  • Routers will figure out where receivers are and
    are not
  • When receiving data, need to perform two actions
  • Tell routers what group youre interested in (via
    IGMP)
  • Tell your LAN controller to receive for
    link-layer mapped address

53
Basic Host Model
  • Hosts can be receivers and not send to the group
  • Hosts can send but not be receivers of the group
  • Or they can be both

54
Basic Host Model
  • There are some protocol and architectural issues
  • Multiple IP group addresses map into a single
    link-layer address
  • You need IP-level filtering
  • Hosts join groups, which means they receive
    traffic from all sources sending to the group
  • Wouldnt it be better if hosts could say what
    sources they were willing to receive from

55
Basic Host Model
  • There are some protocol and architectural issues
    (continued)
  • You can access control sources but you cant
    access control receivers in a scalable way

56
Basic Router Model
  • Since hosts can send any time to any group,
    routers must be prepared to receive on all
    link-layer group addresses
  • And know when to forward or drop packets

57
Basic Router Model
  • What does a router keep track of?
  • interfaces leading to receivers
  • sources when utilizing source distribution trees
  • prune state depending on the multicast routing
    protocol (e.g. Dense Mode)

58
Data Distribution Concepts
  • Routers maintain state to deliver data down a
    distribution tree
  • Source trees
  • Router keeps (S,G) state so packets can flow from
    the source to all receivers
  • Trades off low delay from source against router
    state

59
Data Distribution Concepts
  • Shared trees
  • Router keeps (,G) state so packets flow from the
    root of the tree to all receivers
  • Trades off higher delay from source against less
    router state

60
Data Distribution Concepts
  • How is the tree built?
  • On demand, in response to data arrival
  • Dense-mode protocols (PIM-DM and DVMRP)
  • MOSPF
  • Explicit control
  • Sparse-mode protocols (PIM-SM and CBT)

61
Data Distribution Concepts
  • Building distribution trees requires knowledge of
    where members are
  • flood data to find out where members are not
    (Dense-mode protocols)
  • flood group membership information (MOSPF), and
    build tree as data arrives
  • send explicit joins and keep join state
    (Sparse-mode protocols)

62
Data Distribution Concepts
  • Construction of source trees requires knowledge
    of source locations
  • In dense-mode protocols you learn them when data
    arrives (at each depth of the tree)
  • Same with MOSPF
  • In sparse-mode protocols you learn them when data
    arrives on the shared tree (in leaf routers only)
  • Ignore since routing based on direction from RP
  • Pay attention if moving to source tree

63
Data Distribution Concepts
  • To build a shared tree you need to know where the
    core (RP) is
  • Can be learned dynamically in the routing
    protocol (Auto-RP, PIMv2)
  • Can be configured in the routers
  • Could use a directory service

64
Data Distribution Concepts
  • Source trees make sense for
  • Broadcast radio transmissions
  • Expanding ring search
  • Generic few-sources-to-many-receiver applications
  • High-rate, low-delay application requirements
  • Per source policy from a service providers
    point of view
  • Per source access control

65
Data Distribution Concepts
  • Shared trees make sense for
  • Many low-rate sources
  • Applications that dont require low delay
  • Consistent policy and access control across most
    participants in a group
  • When most of the source trees overlap
    topologically with the shared tree

66
Deployment ObstaclesNon-Technical Issues
  • How to bill for the service
  • Is the service what runs on top of multicast?
  • Or is it the transport itself?
  • Do you bill based on sender or receiver, or both?
  • How to control access
  • Should sources be rate-controlled (unlike unicast
    routing)
  • Should receivers be rate-controlled?

67
Deployment ObstaclesNon-Technical Issues
  • Making your peers fan out instead of you (save
    replication in your network)
  • Closest exit vs latest entrance all a wash
  • Multicast-related security holes
  • Network-wide denial of service attacks
  • Eaves-dropping simpler since receivers are unknown

68
Deployment ObstaclesTechnical Issues
  • Source tree state will become a problem as IP
    multicast gains popularity
  • When policy and access control per source are the
    rule rather than the exception
  • Group state will become a problem as IP
    multicast gains popularity
  • 10,000 three member groups across the Internet

69
Deployment Obstacles Technical Issues
  • Hopefully we can upper bound the state in routers
    based on their switching capacity

70
Deployment Obstacles Technical Issues
  • ISPs dont want to depend on competitors RP
  • Do we connect shared trees together?
  • Do we have a single shared tree across domains?
  • Do we use source trees only for inter-domain
    groups?

71
Deployment Obstacles Technical Issues
  • Unicast and multicast topologies may not be
    congruent across domains
  • Due to physical/topological constraints
  • Due to policy constraints
  • Need inter-domain routing protocol that
    distinguishes unicast versus multicast policy

72
How to Control Multicast Routing Table State in
the Network?
  • Fundamental problem of learning group membership

Flood and Prune DVMRP PIM-DM
Broadcast Membership MOSPF DWRs
Rendezvous Mechanism PIM-SM BGMP
73
Rendezvous Mechanism
  • Why not use sparse-mode PIM?
  • Where to put root of shared tree (RP)
  • ISP third-party RP problem
  • If you did use sparse-mode PIM
  • Group-to-RP mappings would have to be distributed
    throughout the Internet

74
Rendezvous Mechanism
  • Lets try using sparse-mode PIM for inter-domain
    multicast
  • Four possibilities for distributing group-to-RP
    mappings
  • (1) Multi-level RP
  • (2) Anycast clusters
  • (3) MSDP
  • (4) Directory service

75
Group-to-RP mapping distribution (1) Multi-level
RP
  • Idea connect shared trees in hierarchy
  • Level-0 RPs are inside domains
  • They propagate joins from downstream routers to a
    Level-1 RP that may be in another domain
  • Level-0 shared trees connected via a Level-1 RP
  • If multiple Level-1 RPs, iterate up to Level-2 RPs

76
Group-to-RP mapping distribution(1) Multi-Level
RP
  • Problems
  • Requires PIM protocol changes
  • If you dont locate the Level-0 RP at the border,
    intermediate PIM routers think there may be two
    RPs for the group
  • Still has the third-party problem, there is
    ultimately one node at the root of the hierarchy
  • Data has to flow all the way to the
    highest-level RP

77
Group-to-RP mapping distribution (2) Anycast
clusters
  • Idea connect shared trees in clusters
  • Shares burden among ISPs
  • Each RP in each domain is a border router
  • Build RP clusters at interconnect points (or in
    dense-mode clouds)
  • Group allocation is per cluster, not per
    user or per domain

78
Group-to-RP mapping distribution(2) Anycast
clusters
  • Closest border router in cluster is used as the
    RP
  • Routers within a domain will use that domains RP
  • Provided you have an RP for that group range at
    an interconnect point
  • If not, you use the closest RP at the
    interconnect point (could be RP in another
    domain)

79
Group-to-RP mapping distribution(3) MSDP
  • Idea connect domains together
  • If you cant connect shared trees together
    easily, then dont
  • Multicast Source Discovery Protocol
  • Rather than connecting trees, connect sources
    known to all trees

80
Group-to-RP mapping distribution(3) MSDP
  • An RP in a domain has a MSDP peering session with
    an RP in another domain
  • Runs over TCP
  • Source Active (SA) messages indicate active
    sending sources in a domain
  • Logical topology is built for the sole purpose to
    distribute SA messages

81
Group-to-RP mapping distribution(3) MSDP
  • How it works
  • Source goes active in PIM-SM domain
  • Its packets get PIM registered to domains RP
  • RP sends SA message to its MSDP peers
  • Those peers forward the SA to their peers
    away from the originating RP
  • If a peer in another domain has receivers for the
    group to which the source is sending,
    it joins the source (Flood-and-Join
    model)

82
Group-to-RP mapping distribution(3) MSDP
  • No shared tree across domains
  • So each domain can depend solely on its own RP
    (no third-party problem)
  • Do not need to store SA state at each MSDP peer
  • Could encapsulate data in SA messages for
    low-rate bursty sources
  • Could cache SA state to speed up join latency

83
Group-to-RP mapping distribution(4) Directory
Services
  • Idea enable single shared tree across domains,
    or use source tree only

84
Group-to-RP mapping distribution(4) Directory
services
  • a) single shared tree across domains
  • Put RP in clients domain
  • Optimal placement of the RP if the domain had a
    multicast source or receiver active
  • Policy for RP is consistent with policy for
    domains unicast prefixes
  • Use directory to find RP address for a given
    group

85
Group-to-RP mapping distribution(4) Directory
Services
  • Example
  • Receiver host sends IGMP report for 224.1.1.1
  • First-hop router DNS resolves
  • 1.1.1.224.pim.mcast.net
  • A record returned with IP address of RP
  • First-hop router sends PIM join toward RP

86
Group-to-RP mapping distribution(4) Directory
Services
  • All routers have consistent RP addresses via DNS
  • When dynamic DNS is widely deployed it will be
    easier to change A records
  • In the meantime, use loopback addresses on
    routers and move them around in your domain

87
Group-to-RP mapping distribution(4) Directory
Services
  • When domain group allocation exists, a domain can
    be authoritative for a DNS zone
  • 1.224.pim.mcast.net
  • 128/17.1.224.pim.mcast.net

88
Group-to-RP mapping distribution(4) Directory
Services
  • (b) avoid using shared trees at all
  • Build PIM-SM source trees across domains
  • Put multiple A records in DNS to describe sources
    for the group

1.0.2.224.sources.pim.mcast.net IN CNAME
dino-ss20 IN
CNAME jmeylor-sun dino-ss20 IN A 171.69.58.81 jme
ylor-sun IN A 171.69.127.178
89
Standards Solutions
  • Ultimate scalability of both routing and group
    allocation can be achieved using BGMP/MASC
  • Use BGP4 (MBGP) to deal with topology
    non-congruency

90
Border Gateway Multicast Protocol (BGMP)
  • Use a PIM-like protocol between domains (BGP for
    multicast)
  • BGMP builds shared tree of domains for a group
  • So we can use a rendezvous mechanism at the
    domain level
  • Shared tree is bidirectional
  • Root of shared tree of domains is at root domain

91
Border Gateway Multicast Protocol (BGMP)
  • Runs in routers that border a multicast routing
    domain
  • Runs over TCP like BGP
  • Joins and prunes travel across domains
  • Can build unidirectional source trees
  • MIGP tells the borders about group membership

92
Multicast Address Set Claim (MASC)
  • How does one determine the root domain for a
    given group?
  • Group prefixes are temporarily leased to domains
  • Allocated by ISP who in turn received them from
    its upstream provider

93
Multicast Address Set Claim (MASC)
  • Claims for group allocation resolve collisions
  • Group allocations are advertised across domains
  • Lots of machinery for aggregating group
    allocations

94
Multicast Address Set Claim (MASC)
  • Tradeoff between aggregation and anticipated
    demand for group addresses
  • Group prefix allocations are not assigned to
    domainsthey are leased
  • Applications must know that group addresses may
    go away
  • Work in progress

95
Using BGP4 (MBGP) for Non-Congruency Issues
  • Multiprotocol extensions to BGP4RFC 2283
  • MBGP allows you to build a unicast RIB and
    multicast RIB independently with one protocol
  • Can use the existing or new (mulitcast) peering
    topology
  • MBGP carries unicast prefixes of multicast
    capable sources

96
MBGP Deployment Scenarios
  • 1) Single public interconnect for ISPs to
    multicast peer
  • Each ISP administers their own RP at the
    interconnect
  • That RP as well as all border routers run MBGP
  • Interconnect runs dense-mode PIM
  • Each ISP runs PIM-SM internally

97
MBGP Deployment Scenarios
  • 2) multiple interconnect points between ISPs
  • ISPs can multicast peer for any groups as long as
    their respective RPs are colocated on the same
    interconnect
  • Else use MSDP so that sources known to RPs at a
    given interconnect can tell RPs at other
    interconnects where to join

98
MBGP Deployment Scenarios
  • 3) address range depends on DNS to rendezvous
    or build trees
  • ISPs decide which domains will have
    RPs that they will administer
  • ISPs decide which groups will use source trees
    and dont need RPs
  • ISPs administer DNS databases
Write a Comment
User Comments (0)
About PowerShow.com