1
|
|
2
|
- Introduction
- Multicast addressing
- Group Membership Protocol
- PIM-SM / SSM
- MSDP
- MBGP
- Summary
|
3
|
- Introduction
- Multicast addressing
- Group Membership Protocol
- PIM-SM / SSM
- MSDP
- MBGP
- Summary
|
4
|
|
5
|
- Any Applications with multiple receivers
- 1-to-many or many-to-many
- Live Video distribution
- Collaborative groupware
- Periodic Data Delivery - "Push" technology
- stock quotes, sports scores, magazines, newspapers
- advertisements
- Server/Web-site replication
- Reducing Network/Resource Overhead
- more efficient to establish multicast tree rather then multiple
point-to-point links
- Resource Discovery
- Distributed Interactive Simulation (DIS)
|
6
|
- Source = source of multicast stream
- Multicast stream = IP packet with multicast address as IP destination
address. a.k.a. multicast group.
- s,g (unicast source, group) reference
- UDP packets (TTL > 1 for routed nets)
- Receiver = receiver (s) of
multicast stream
|
7
|
- The SENDERS send
- Multicast Addressing - rfc1700
- class D (224.0.0.0 - 239.255.255.255)
- The RECEIVERS inform the routers what they want to receive
- Internet Group Management Protocol (IGMP) - rfc2236 -> version 2
- The routers make sure the STREAMS make it to the correct receiving nets.
- Multicast Routing Protocols (PIM-SM/SSM)
- RPF (reverse path forwarding) –
against source address
|
8
|
- Multicast Routing is backwards from Unicast Routing
- Unicast Routing is concerned about where the packet is going.
- Multicast Routing is concerned about where the packet came from.
- Multicast Routing uses “Reverse Path Forwarding”
|
9
|
- What is RPF?
- A router forwards a multicast datagram only if received on the up
stream interface to the source (i.e. it follows the distribution tree).
- The RPF Check
- The source IP address of incoming multicast packets are checked against
a unicast routing table.
- If the datagram arrived on the interface specified in the
routing table for the
source address; then the RPF check
succeeds.
- Otherwise, the RPF Check fails.
|
10
|
- Multicast uses unicast routes to determine path back to source
- IGP, connected, MBGP
- RPF checks ensures packets won’t loop
- Routes contain incoming interface
- Packets matching are forwarded
- Packets mis-matching are dropped
|
11
|
- Group Membership Protocol - enables hosts to dynamically join/leave
multicast groups. Membership info is communicated to nearest router
- Multicast Routing Protocol - enables routers to build a delivery tree
between the sender(s) and receivers of a multicast group
|
12
|
|
13
|
|
14
|
- Source or Shortest Path trees
- More resource intensive; requires more stateà n(S x G)
- You get optimal paths from source to all receivers, minimizes delay
- Best for one-to-many distribution
- Shared or Core Based trees
- Uses less resources; less memory
àn(G)
- You may get sub optimal paths from source to all receivers, depending
on topology
- The RP (core) itself and its location may affect performance
- Best for many-to-many distribution
- May be necessary for source discovery (PIM-SM)
|
15
|
- Introduction
- Multicast addressing
- Group Membership Protocol
- PIM-SM / SSM
- MSDP
- MBGP
- Summary
|
16
|
- IP Multicast Group Addresses
- 224.0.0.0–239.255.255.255
- Class “D” Address Space
- High order bits of 1st Octet =
“1110”
- TTL value defines scope and limits distribution
- IP multicast packet must have TTL > interface TTL or it is
discarded
- values are: 0=host, 1=network, 32=same site, 64=same region, 128=same
continent, 255=unrestricted
- No longer recommended as a reliable scoping mechanism
|
17
|
- draft-albanna-iana-ipv4-mcast-guidelines-xx
- http://www.iana.org/assignments/multicast-addresses
- Examples of Reserved & Link-local Addresses
- 224.0.0.0 - 224.0.0.255 reserved & not forwarded
- 239.0.0.0 - 239.255.255.255 Administrative Scoping
- 224.0.0.1 - All local hosts
- 224.0.0.2 - All local routers
- 224.0.0.4 - DVMRP
- 224.0.0.5 - OSPF
- 224.0.0.6 - Designated Router
OSPF
- 224.0.0.9 - RIP2
- 224.0.0.13 - PIM
- 224.0.0.15 - CBT
- 224.0.0.18 - VRRP
|
18
|
- SDR The defacto
- 224.2.0.0 – 224.2.255.255 (224.2/16) SDP/SAP Block
- Still used, but not required
- Will not scale well
- Limited address space
- Single directory application for ALL content?!?!?
- Web links should prevail
|
19
|
- Administratively Scoped Addresses – rfc2365
- 239.0.0.0–239.255.255.255
- Private address space
- Similar to RFC1918 unicast addresses
- Not used for global Internet traffic
- Used to limit “scope” of multicast traffic
- Same addresses may be in use at different locations for different
multicast sessions
- Examples
- Site-local scope: 239.253.0.0/16
- Organization-local scope: 239.192.0.0/14
|
20
|
- GLOP addresses
- Provides globally available private Class D space
- 233.x.x/24 per AS number
- RFC2770
- How?
- AS number = 16 bits
- Insert the 16 ASN into the middle two octets of 233/8
- Online Glop Calculator:
- http://www.shepfarm.com/multicast/glop.html
|
21
|
- SSM - draft-ietf-ssm-arch-*.txt
- 232/8 – IANA assigned
- One-to-many ONLY (no shared trees)
- Guaranties ONE source on any delivery tree
- Content security (no ‘Captain Midnight’)
- Reduced protocol dependance – more later..
- Solves address allocation issues for interdomain one-to many
- ~tree address is 64 bits – S,G
- Host must learn of source address out-of-band (web page)
- Requires host-to-router source AND group request
- IGMPv3 include-source list
- Hard-coded behavior in 232/8 in most router implementations
- draft-ietf-mboned-ssm232-*.txt
- Configurable to expand range
|
22
|
- RFC 1700 - ethernet
-
224. 10. 8. 5 <-- Class D IP address
- 0000 0001 0000 0000 0101 1110 0xxx xxxx xxxx xxxx xxxx xxxx <-- IANA’s reserved block 01-00-5E
- |
|
- Multicast Bit 0 =
Internet Multicast
-
1 = IANA reserved
- 0000 0001 0000 0000 0101 1110 0000 1010 0000 1000 0000 0101 <-- MAC address 01-00-5E-0A-08-05
- 224.10.8.5 multicast stream maps to 01-00-5E-0A-08-05 ethernet layer 2
address.
- rfc 1469 TR
- rfc 1390 FDDI
- rfc 2226 & 2022 - ATM
- rfc 1209 SMDS (broadcast)
|
23
|
|
24
|
- Introduction
- Multicast addressing
- Group Membership Protocol
- PIM-SM / SSM
- MSDP
- MBGP
- Summary
|
25
|
- How hosts tell routers about group membership
- Routers solicit group membership from directly connected hosts
- RFC 1112 specifies version 1 of IGMP
- RFC 2236 specifies version 2 of IGMP
- Supported on latest service pack
for Windows, newer Windows releases, and most UNIX systems
- IGMP version 3 is specified in IETF draft
- RFC3376
- provides source include-list
capabilities (SSM!)
- Support?
- FreeBSD patch, Linux patch, Window XP
- http://videolab.uoregon.edu
|
26
|
- Router:
- sends Membership Query messages to All Hosts (224.0.0.1)
- query-interval = 125 secs default
- router with lowest IP address is Querier (rest non-queriers)
- If lower-IP address query heard, backoff to non-querier state
- Other Querier Present Interval default: (robust-count x
query-interval) + (0.5 x query-response-interval) = 255 secs
- listens for reports (whether querier or not) and adds group to
membership list for that interface
- query-response-interval = 10 secs default
- timeout (Group member interval) default:
- (robust-count x query-interval) + (1 x query-response-interval) = 260 sec
- robust-count - provides fine-tuning to allow for expected packet loss
on a subnet. Default = 2 (tunable from 2-10)
|
27
|
- Host:
- sends Membership Report messages, if joined
- waits 0-10 sec (def).
- Hosts listen to other host reports
- Only 1 host responds
- Join messages (unsolicited Membership Report) to group address (e.g.
224.10.8.5)
- Leave messages to All Routers (224.0.0.2)
- IGMPv1/2 reports group membership ONLY – No sources
|
28
|
- Router triggers group membership request to PIM.
- Hosts can send unsolicited join membership messages – called reports in
the RFC (usually more than 1)
- Or hosts can join by responding to periodic query from router
|
29
|
- Hosts respond to query to indicate (new or continued) interest in
group(s)
- only 1 host should respond per group
- Hosts fall into idle-member state when same-group report heard.
- After 260 sec with no response, router times out group
|
30
|
- Hosts that support IGMP v2 send leave messages to all routers group
indicating group they’re leaving.
- Router follows up with 2 group-specific queries messages
- IGMP v1 hosts leave by not responding to queries (260 sec timeout)
|
31
|
- H1 wants to receive from S = 1.1.1.1 but not from S = 2.2.2.2
- With IGMPv3, specific sources can be pruned back - S = 2.2.2.2 in this
case
|
32
|
- IGMP Version 2
- multicast router with lowest IP address is elected querier
- IGMPv1 was mcast protocol specific and potentially conflicted.
- Group-Specific Query message is defined. Enables router to transmit
query to specific multicast address rather than to the
"all-hosts" address of 224.0.0.1
- Leave Group message is defined. Last host in group wishes to leave, it
sends Leave Group message to the "all-routers" address of
224.0.0.2. Router then transmits Group-Specific query and if no reports
come in, then the router removes that group from the list of group
memberships for that interface
- IGMP Version 3
- Group-Source Report message is defined. Enables hosts to specify which
senders it can receive or not receive data from.
- Group-Source Leave message is defined. Enables host to specify the
specific IP addresses of a (source,group) that it wishes to leave.
|
33
|
- Introduction
- Multicast addressing
- Group Membership Protocol
- PIM-SM / SSM
- MSDP
- MBGP
- Summary
|
34
|
- Protocol Independent Multicast - sparse mode
- draft-ietf-pim-sm-v2-new-xx
- Obsoletes RFC 2362
- BSR removed from PIM spec.
- explicit join: assumes everyone does not want the data
- uses unicast routing table for
RPF checking
- data and joins are forwarded to RP for initial rendezvous
- all routers in a PIM domain must have RP mapping
- when load exceeds threshold forwarding swaps to shortest path tree
(default is first packet)
- state increases (not everywhere) as number of sources and number of
groups increase
- source-tree state is refreshed when data is forwarded and with
Join/Prune control messages
|
35
|
- Neighboring PIM-SM routers multicast periodic “Hello” messages to each
other - default 30 secs.
- Hello-interval tunable for faster convergence
- On receipt of a Hello message
- a router stores the IP address
and priority for that neighbor
- Router with highest IP address is selected as the DR, if the priorities
match
- When DR goes down:
- new one selected by scanning all neighbors on the interface and
choosing the one with the highest IP address
- DR sends
- “Join/Prune” messages toward the RP from receiver network
- “Register” messages toward the RP from source network
|
36
|
- Allows Source Trees or Shared Trees
- Rendezvous Point (RP)
- Matches senders with receivers
- Provides network source discovery
- Root of shared tree
- Typically use shared tree to bootstrap source tree
- RP’s can be learned via:
- Static configuration – RECOMMENDED
- Auto-RP
- Bootstrap Router
|
37
|
|
38
|
|
39
|
|
40
|
|
41
|
|
42
|
|
43
|
|
44
|
|
45
|
|
46
|
- RP Configuration (static) on ALL routers in PIM domain
|
47
|
- For all routers with externally-facing interfaces
|
48
|
- For all routers when NOT using BSR or Auto-RP
|
49
|
- RP Mapping options
- Static RP
- Recommended
- Easy transition to Anycast-RP
- Allows for a hierarchy of RPs
- Auto-RP
- Fixed convergence timers (slow)
- Must flood RP mapping traffic
- BSR
- No longer in the PIM spec.
- Fixed convergence timers (slow)
- Allows for a hierarchy of RPs
|
50
|
- No shared trees
- No register packets
- No RP mapping required (no RP required!)
- No RP-to-RP source discovery (MSDP)
- Requires IGMP include-source list – IGMPv3
- User-definable range
- IANA specifies 232/8 for global SSM
|
51
|
|
52
|
|
53
|
|
54
|
|
55
|
|
56
|
|
57
|
|
58
|
|
59
|
|
60
|
|
61
|
- RtrA# show ip pim route
- (198.58.3.242/32, 233.15.108.1/32), expires 00:02:32, register
- Incoming interface:
Ethernet0/0/2, RPF nbr 198.58.3.238, metric [110/11112]
- Oif-list: (0) 00000000, timeout-list: (0)
00000000
- Immediate-list: (0) 00000000,
timeout-list: (0) 00000000
- Timeout-interval: 1, JP-holdtime
round-up: 3
|
62
|
- RtrB# show ip mroute
- (*, 224.2.127.254/32), uptime: 1d17h, igmp ip pim
- Incoming interface:
Ethernet0/0/2 (iod: 2), RPF nbr: 198.58.3.220
- Outgoing interface list: (count:
1)
- Ethernet0/0/1 (iod 5), uptime:
1d17h, igmp
|
63
|
- RtrB# show ip mroute
- ...
- (63.105.122.14/32, 224.2.127.254/32), uptime: 00:02:43, mrib ip pim
- Incoming interface:
Ethernet0/0/3 (iod: 3), RPF nbr: 198.58.3.238
- Outgoing interface list: (count:
1)
- Ethernet0/0/1 (iod 5), uptime:
00:00:11, mrib
|
64
|
- RtrB# show ip mroute sum
- IP Multicast Routing Table for Context "default"
- Total number of routes: 2
- Total number of (*,G) routes: 1
- Total number of (S,G) routes: 1
- Group count: 1, average sources per group: 1.0
- Group: 224.2.127.254/32, Source count: 51
- Source packets bytes aps pps bit-rate
- (*,G) 423 439788 1039 0 0 bps
- 80.76.128.66 170 109447 643 0 87 bps
|
65
|
|
66
|
- Introduction
- Multicast addressing
- Group Membership Protocol
- PIM-SM / SSM
- MSDP
- MBGP
- Summary
|
67
|
- Multicast Source Discovery Protocol
- draft-ietf-msdp-spec-xx
- Allows each domain to control its own RP(s)
- Interconnect RPs between domains with TCP connections to pass source
active messages (SAs)
- Can also be used within a domain to provide RP redundancy (Anycast-RP)
- RPs send SA messages for internal sources to MSDP peers
- SAs are Peer-RPF checked before accepting or forwarding
- RPs learn about external sources via SA messages and may trigger
(S,G)joins on behalf of local receivers
- MSDP connections typically parallel MBGP connections
|
68
|
- MSDP peers (inter or intra domain)
- (TCP port 639 w/ higher IP addr LISTENS)
- “FLOOD & join”
- SA (source active) packets periodically sent to MSDP peers indicating:
- source address of active streams
- group address of active streams
- IP address of RP originating the SA
- only originate SA’s for your sources w/in your domain
- “flood & JOIN”
- interested parties can send PIM JOIN’s towards source (creates
inter-domain source trees)
|
69
|
- Initial SA message sent when source first registers
- May optionally encapsulate first data packet
- Subsequent SA messages periodically refreshed every 60 seconds as long
as source still active by originating RP
- Other MSDP peers don’t originate this SA but only forward it if received
- SA messages cached on router for new group members that may join
- Reduced join latency
- Prevent SA storm propagation
|
70
|
|
71
|
|
72
|
|
73
|
|
74
|
|
75
|
- MSDP establishes a neighbor relationship between MSDP peers
- Peers connect using TCP port 639
- Peers send keepalives every 60 secs (fixed)
- Peer connection reset after 75 seconds if no MSDP packets or keepalives
are received
- MSDP peers must run mBGP!
- May be an MBGP peer, a BGP peer or both
- Required for peer-RPF checking of the RP address in the SA to prevent
SA looping
- Exception: BGP is unnecessary when
peering with only a single MSDP peer (default-peer)
|
76
|
- Skip RPF Check and accept SA if:
- Sending MSDP peer is default-peer
- Sending MSDP peer = Mesh-Group peer
- RPF Check the received SA message
- If the MSDP peer IS THE originating RP – then accept.
- Lookup best MBGP path to RP in SA message
- Search mbest
- If path to RP not found, RPF Check Fails; ignore SA message
- Is the sending MSDP Peer also an MBGP peer?
- Yes: Is best path to RP via this MBGP peer?
- If yes, RPF Check Succeeds; process SA message
- No: Is the first AS in the best path to RP = the first AS in the best
path to MSDP peer?
- If yes, RPF Check Succeeds; process SA message
|
77
|
- RPF Check rule example cases
- Case 1: Sending MSDP Peer = iMBGP peer
- Is best path to RP via this MBGP peer?
- Case 2: Sending MSDP Peer = eMBGP peer
- Is best path to RP via this MBGP peer?
- Case 3: Sending MSDP Peer != BGP peer
- Is the next AS in best path to RP = AS of the sending MSDP peer?
|
78
|
|
79
|
|
80
|
|
81
|
|
82
|
|
83
|
|
84
|
|
85
|
|
86
|
|
87
|
- draft-ietf-mboned-anycast-rp-xx.txt
- Within a domain, deploy more than one RP for the same group range
- Sources from one RP are known to other RPs using MSDP
- Give each RP the same /32 IP address
- Sources and receivers use closest RP, as determined by the IGP
- Used intra-domain to provide redundancy and RP load sharing, when an RP
goes down, sources and receivers are taken to new RP via unicast routing
|
88
|
|
89
|
|
90
|
- Introduction
- Multicast addressing
- Group Membership Protocol
- PIM-SM / SSM
- MSDP
- MBGP
- Summary
|
91
|
- MBGP overview
- MBGP capability negotiation
- MBGP NLRI exchange
- Configuration guidelines
|
92
|
- Multiprotocol Extensions to BGP (RFC 2283).
- Tag unicast prefixes as multicast source prefixes for intra-domain mcast
routing protocols to do RPF checks.
- WHY? Allows for interdomain RPF
checking where unicast and multicast paths are non-congruent.
- DO I REALLY NEED IT?
- YES, if:
- ISP to ISP peering
- Multiple-homed networks
- NO, if:
|
93
|
- MBGP: Multiprotocol BGP
(aka multicast BGP in multicast networks)
- Defined in RFC 2283 (extensions to BGP)
- Can carry different route types for different purposes
- Both route types carried in same BGP session
- Does not propagate multicast state information
- Same path selection and validation rules
- AS-Path, LocalPref, MED, …
|
94
|
- New multiprotocol attributes
- MP_REACH_NLRI
- MP_UNREACH_NLRI
- MP_REACH_NLRI and MP_UNREACH_NLRI
- Address Family Information (AFI) = 1 (IPv4)
- Sub-AFI = 1 (NLRI is used for unicast)
- Sub-AFI = 2 (NLRI is used for multicast RPF check)
- Sub-AFI = 3 (NLRI is used for both unicast and multicast RPF check)
- Allows for different policies between multicast and unicast
|
95
|
- BGP routers establish BGP sessions through the OPEN message
- OPEN message contains optional
parameters
- BGP session is terminated if OPEN parameters are not recognised
- New parameter: CAPABILITIES
- Multiprotocol extension
- Multiple routes for same destination
- Configures router to negotiate either or both NLRI
- If neighbor configures both or subset, common NRLI is used in both
directions
- If there is no match, notification is sent and peering doesn’t come up
- If neighbor doesn’t include the capability parameters in open, session
backs off and reopens with no capability parameters
- Peering comes up in unicast-only mode
|
96
|
- Solves part of inter-domain problem
- Can exchange unicast prefixes for multicast RPF checks
- Uses standard BGP configuration knobs
- Permits separate unicast and multicast
topologies if desired
- Still must use PIM to:
- Build distribution trees
- Actually forward multicast traffic
- PIM-SM recommended
|
97
|
- PIM Border Constraints
- Confine registers within domain
- Confine local groups
- Confine RP announcements
- Control SA advertisements via MSDP
- Border RPF check
- RPF check against unicast routes to multicast sources
- MSDP RPF check
- RPF check toward RP in received SAs
|
98
|
|
99
|
- router bgp 1
- address-family ipv4 unicast
- network 198.58.3.0/24
- address-family ipv4 multicast
- network 198.58.3.0/24
- neighbor 198.32.165.2 remote-as 2
- description LabPeer1
- update-source Ethernet0/0/1
- address-family ipv4 unicast
- address-family ipv4 multicast
|
100
|
|
101
|
- RtrA# show ip msdp summary
- MSDP Peer Status Summary, local ASN: 1
- Number of configured peers: 1
- Number of established peers: 1
- Number of shutdown peers: 0
- Peer Peer Connection Uptime/ Last msg (S,G)s
- Address ASN State Downtime Received Received
- 198.58.3.252 2 Established 00:01:13 00:00:10 1
|
102
|
- RtrA# show ip msdp count
- SA State per ASN - 1 total entries
- <asn>: <(S,G)
count>/<group count>
- 2: 1/1
- RtrA# show ip msdp sa-cache
- MSDP SA Route Cache - 1 entries
- Source Group RP ASN Uptime Expires
- 129.241.110.78 224.0.1.1 128.39.0.86 2 02:38:16 00:03:22
|
103
|
- RtrA# show ip mbgp summary
- BGP router identifier 198.58.3.249, local AS number 1
- BGP table version is 844399, IPv4 Multicast config peers 1, capable
peers 1
- 4654 network entries and 4654 paths using 521248 bytes of memory
- BGP attribute entries [22297/1427008], BGP AS path entries
[19571/193760]
- BGP community entries [56/628], BGP clusterlist entries [0/0]
- Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
- 198.58.3.238 4 2
184934 15559 844399 0
0 00:32:34 4653
|
104
|
- proUO# show ip mbgp
- BGP table version is 845065, local router ID is 198.58.3.249
- Status: s-suppressed, x-deleted, d-dampened, h-history, *-valid,
>-best
- Path type: i-internal, e-external, c-confed, l-local, a-aggregate,
r-redist
- Origin codes: i - IGP, e - EGP, ? - incomplete
- Network Next Hop Metric LocPrf Weight Path
- *>i1.0.0.0/8
198.32.177.14
100 2 I
|
105
|
|
106
|
- Introduction
- Multicast addressing
- Group Membership Protocol
- PIM-SM / SSM
- MSDP
- MBGP
- Summary
|
107
|
- IGMP - Internet Group Management Protocol is used by hosts and routers
to tell each other about group membership.
- PIM-SM - Protocol Independent Multicast-Sparse Mode is used to propagate
forwarding state between routers.
- SSM - Source Specific Multicast utilizes a subset of PIM’s functionality
to guaranty source-only trees in the 232/8 range.
- MBGP - Multiprotocol Border Gateway Protocol is used to exchange routing
information for interdomain RPF checking.
- MSDP - Multicast Source Discovery Protocol is used to exchange ASM
active source information between RPs.
|
108
|
- Introduction
- Multicast addressing
- Group Membership Protocol
- PIM-SM / SSM
- MSDP
- MBGP
- Summary
- Who, why, how, why not?
|
109
|
- Financial Networks
- Security Exchanges
- NASDAQ, NYSE, AMSE, HKSE, etc..
- Securities Trading Enterprises
- Enterprises
- Service Providers
- VPN Providers
- MIX
|
110
|
- End-to-end in control (mostly…)
|
111
|
|
112
|
|
113
|
|
114
|
|
115
|
|
116
|
- Central DVMRP global architecture
- MBGP/PIM transit – preMSDP
- MSDP/MBGP/PIM-SM
|
117
|
|
118
|
|
119
|
|
120
|
|
121
|
|
122
|
|
123
|
|
124
|
|
125
|
|
126
|
|
127
|
- Multicast in the Internet is an all-or-nothing solution
- Even Mcast-aware content owners must provide unicast streams to gain
audience size
- Unicast will never scale
- Splitters/Caches just distribute the problem
- Still has a cost-per-user
- As receiver BW increases, problem gets worse.
- Creates a non-functional business model
- Will never bring ~real content to IP.
- Must provide a multicast-only solution for content owners; but how??
|
128
|
- shep@procket.com
- http://www.procket.com
- http://www.shepfarm.com/multicast
|