4: Multicast Routing 2
Inter-Domain Routing
Technologie-Zentrum Informatik
Typical Intra-Domain Multicast Architecture
S
S
R
R
DATA
© 2003 Olaf Bergmann, Jörg Ott
Connecting Multicast-Domains
Intra-Domain Intra-DomainS
R
R
R
S
MBR
Technologie-Zentrum InformatikInter-Domain Multicast Routing
`
Issues:
y Address clashes
y Finding active sources
y Broadcast/prune vs explicit join
y SSM vs ASM/SFM
y Parallel paths
y (Multicast) Route changes
y Support for distribution tree optimizations `
2 different approaches:
y Create shared tree in multicast border routers
© 2003 Olaf Bergmann, Jörg Ott
Generic MBR Architecture
`
Only one routing protocol for each interface
`
Components change forwarding entry for “their” interface
`
Single incoming interface per forwarding entry
`
Components typically have separate multicast routing table
`
Event-driven communication between components and routing logic
DVMRP MOSPF PIM-SM CBTIGMP Protocol components
Shared forwarding cache
Network interfaces Routing logic (S1,G1) → (iif, { oif, ... }) ... Technologie-Zentrum Informatik
MBR routing process
`
On incoming data, the dispatcher determines the iif owner
`
iif owner may drop incoming packet
(e.g. not in scope boundaries, RPF check failed, etc.)
`
Creation of (S,G) entry triggers alert for outgoing interfaces
→ enable flooding
`
Deletion of (S,G) entry trigger alert for incoming interface
→ prune/leave
`
Adding outgoing interface to (S,G) entry triggers alert for incoming
interface
→ join/graft
`
Create (*,*) entries for externally-reached sources towards tree root
y Owned by routing logic (“interop dispatcher”)
y Clear state after prunes
y Create entries for joins
© 2003 Olaf Bergmann, Jörg Ott
Applicability to Existing Protocols
`
Dense-mode
y
Components are wildcard-receivers for internal sources
y
Wildcard-receivers for external sources if no domain-wide reports
available
`
Sparse-mode
y
MBRs need to be on shared distribution tree
→ create wildcard entries for every group at every RP/Core
y
Act as DR for external sources
Technologie-Zentrum Informatik
Example: Sender in PIM-SM-Domain
R
R
S
R
RP
PIM-SM
DVMRP
R
© 2003 Olaf Bergmann, Jörg Ott
Example: Sender in PIM-SM-Domain
R
R
S
R
RP
PIM-SM
DVMRP
R
Technologie-Zentrum InformatikPIM-SM Router Operation
`
MBR encapsulates data from external sources in Register message
y Use B-Bit to avoid multiple registrations
y RP sends data downstream `
Downstream router operation:
y Look for specific routing state (S,G) or (*,G) → forward downstream
y Look for matching (*,*,RP) entry
→ forward packets if data arrived on incoming interface
y Otherwise, drop packets `
MBR treated as group member
y Gets multicast data from senders within PIM-SM-domain
y Forwards to DVMRP-domain
© 2003 Olaf Bergmann, Jörg Ott
Example: Sender in DVMRP-Domain
S
R
R
R
RP
PIM-SM
DVMRP
encapsulated data packet sent via unicast to RPR
Technologie-Zentrum Informatik
Overlay Routing Architecture
`
Sparse-Mode approach relies on shared tree
y
Slow convergence in case of route changes
y
External single point of failure (due to unidirectional tree)
`
BGMP: Border Gateway Multicast Protocol
y
Like BGP-4 for unicast routing
y
Can use any M-IGP (DVMRP, MOSPF, CBT, PIM, …)
y
Bidirectional routing tree → build global multicast RIB
y
SSM only on demand
y
Worse loop prevention (no RPF checks)
© 2003 Olaf Bergmann, Jörg Ott Domain B Domain A Domain C
R
Domain D allocated root domain for GIGMP join for group G
Report to border routers BGMP join Technologie-Zentrum Informatik Domain B
Domain Hierarchies in BGMP
Domain A Domain CR
S
Domain D allocated root domain for GMulticast data
for group G
© 2003 Olaf Bergmann, Jörg Ott
BGMP Routing
`
Join/Prune is distributed to allocated root domain
y BGMP for communication between border routers
y Specific multicast routing protocol for interior communication `
Data is sent to multicast group as usual
y Border routers forward to next hop for specified group
y Forwarded downstream from root domain `
Must support specific M-IGP protocols
y Deal with RPF-checks
y Tree optimizations Technologie-Zentrum Informatik Domain B
Domain Hierarchies in BGMP
Domain A Domain CR
S
Domain D allocated root domain for GMulticast data
for group G
encapsulate data to make RPF check succeed© 2003 Olaf Bergmann, Jörg Ott Domain B Domain A Domain C
R
S
Domain D allocated root domain for GMulticast data
for group G
source-specific join prune other branchesTechnologie-Zentrum Informatik Domain B
Domain Hierarchies in BGMP
Domain A Domain CR
S
Domain D allocated root domain for GMulticast data
for group G
data sent along optimized SPT
© 2003 Olaf Bergmann, Jörg Ott
Address Allocation
`
MALLOC (RFC 2908)
y Overall allocation architecture
y Scope, lifetime, timeliness, resource management, … `
MASC (RFC 2909)
y Claim set of address prefixes
y CIDR-like aggregation for routers `
MZAP (RFC 2776)
y Announce information about local zone hierarchy
y To be used for address claims `
MADCAP (RFC 2730)
y Allocate multicast address for instant use
→ support dynamic groups such as ad-hoc-networks
y Similar to DHCP
Technologie-Zentrum Informatik