Notes
Slide Show
Outline
1
IPMulticast
AIT Workshop
May 2003
2
Agenda
  • Introduction
  • Multicast addressing
  • Group Membership Protocol
  • PIM-SM / SSM
  • MSDP
  • MBGP
  • Summary



3
Agenda
  • Introduction
  • Multicast addressing
  • Group Membership Protocol
  • PIM-SM / SSM
  • MSDP
  • MBGP
  • Summary



4
What is Multicasting?
5
Multicast Uses
  • 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)
    • wargames
    • virtual reality

6
Glossary of Terms: the basics
  • 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
IP Multicast building blocks
  • 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 Forwarding
  • 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
Multicast Forwarding
  • 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
Reverse Path Forwarding
  • 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
IP Multicast Components
  • 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
Multicast Distribution Trees
13
Multicast Distribution Trees
14
Multicast Distribution Trees
  •  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
Agenda
  • Introduction
  • Multicast addressing
  • Group Membership Protocol
  • PIM-SM / SSM
  • MSDP
  • MBGP
  • Summary



16
Multicast Addressing
  • 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
Multicast Addressing
  • 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
Dynamic Address Allocation
  • 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
Multicast Addressing
  • 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
Multicast Addressing
  • 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
Multicast Addressing
  • 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
Multicast Addresses - Layer 2
  • 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
Ethernet Multicast Addressing
24
Agenda
  • Introduction
  • Multicast addressing
  • Group Membership Protocol
  • PIM-SM / SSM
  • MSDP
  • MBGP
  • Summary



25
Internet Group Membership(management) Protocol (IGMP)
  • How hosts tell routers about group membership
  • Routers solicit group membership from directly connected hosts
  • RFC 1112 specifies version 1 of IGMP
    •  Supported on Windows 95
  • 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
IGMP Details
  • 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
IGMP Details
  • 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
IGMP Protocol Flow - Join a Group
  • 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
IGMP Protocol Flow - Querier
  • 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
IGMP Protocol Flow - Leave a Group
  • 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
IGMPv3
  • 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 Enhancements
  • 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
Agenda
  • Introduction
  • Multicast addressing
  • Group Membership Protocol
  • PIM-SM / SSM
  • MSDP
  • MBGP
  • Summary



34
PIM-SM
  • 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
PIM-SM Operation
Designated Router (DR)
  • 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
PIM Sparse-Mode :RP
  • 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
PIM-SM Shared Tree Join
38
PIM-SM Sender Registration
39
PIM-SM Sender Registration
40
PIM-SM Sender Registration
41
PIM-SM SPT Cutover
42
PIM-SM SPT Cutover
43
PIM-SM SPT Cutover
44
PIM-SM SPT Cutover
45
PIM-SM SPT Cutover
46
PIM-SM Configuration
  • RP Configuration (static) on ALL routers in PIM domain
47
PIM-SM Configuration
  • For all routers with externally-facing interfaces
48
PIM-SM Configuration
  • For all routers when NOT using BSR or Auto-RP
49
PIM-SM Configuration
  • 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
PIM-SSM
  • 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
PIM-SSM
52
PIM-SSM
53
LAB #1 – PIM-SM
54
LAB #1 – PIM-SM
55
LAB #1 – PIM-SM
56
LAB #1 – PIM-SM
57
LAB #1 – PIM-SM
58
LAB #1 – PIM-SM
59
LAB #1 – PIM-SM
60
LAB #1 – PIM RP state on the RP
61
Lab #1 RP Register State for an active source
  • 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
Lab #1 Shared-tree state on DR
  • 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
Lab #1 Source Tree State
  • 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
Lab #1 Show active multicast state/traffic
  • 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
LAB #1b – PIM-SM – Optional
66
Agenda
  • Introduction
  • Multicast addressing
  • Group Membership Protocol
  • PIM-SM / SSM
  • MSDP
  • MBGP
  • Summary



67
MSDP
  • 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 Operation
  • 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
MSDP Source Active Msgs
  • 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
MSDP Overview
71
MSDP Overview
72
MSDP Overview
73
MSDP Overview
74
MSDP Overview
75
MSDP Peers
  • 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
Receiving SA Messages
  • 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
Receiving SA Messages
  • 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
RPF Check Example
79
RPF Check Example
80
RPF Check Example
81
RPF Check Example
82
RPF Check Example
83
RPF Check Example
84
MSDP Configuration
85
MSDP wrt SSM – Unnecessary!
86
MSDP wrt SSM – Unnecessary!
87
MSDP Application: Anycast-RP
  • 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
    • Fast convergence!
88
Anycast-RP
89
Anycast-RP
90
Agenda
  • Introduction
  • Multicast addressing
  • Group Membership Protocol
  • PIM-SM / SSM
  • MSDP
  • MBGP
  • Summary



91
MBGP—Multiprotocol BGP
  • MBGP overview
  • MBGP capability negotiation
  • MBGP NLRI exchange
  • Configuration guidelines


92
MBGP
  • 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:
      • You are single-homed

93
MBGP Overview
  • MBGP: Multiprotocol BGP
    (aka multicast BGP in multicast networks)
    • Defined in RFC 2283 (extensions to BGP)
    • Can carry different route types for different purposes
      • Unicast
      • Multicast
    • 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
MBGP Overview
  • 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
MBGP—Capability Negotiation
  • 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
MBGP—Summary
  • 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
Multicast Transit Design Objectives
  • 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
LAB #2 – Interdomain
99
MBGP configuration
  • 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
LAB #2 – Interdomain
101
Lab #2 – MSDP sessions
  • 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
Lab #2 – MSDP SAs
  • 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
Lab #2 – MBGP peering session
  • 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
Lab #2 – MBGP received prefixes
  • 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
LAB #2b – Interdomain – Optional
106
Agenda
  • Introduction
  • Multicast addressing
  • Group Membership Protocol
  • PIM-SM / SSM
  • MSDP
  • MBGP
  • Summary



107
The Soup
  • 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
Agenda
  • Introduction
  • Multicast addressing
  • Group Membership Protocol
  • PIM-SM / SSM
  • MSDP
  • MBGP
  • Summary
  • Who, why, how, why not?



109
Who uses Multicast?
  • Financial Networks
    • Security Exchanges
      • NASDAQ, NYSE, AMSE, HKSE, etc..
    • Securities Trading Enterprises
  • Enterprises
  • Service Providers
    • IP core
    • MPLS core
  • VPN Providers
  • MIX


110
How?
Security Exchanges
  • End-to-end in control (mostly…)
111
How?
Security Trading Enterprises
  • End-to-end in control
112
How?
Enterprises
  • End-to-end in control
113
How?
Service Providers (IP)
  • Internal control only
114
How?
Service Providers (MPLS)
  • Internal control only
115
How?
VPN Providers – Rosen opt2 (2547)
  • Internal control only
116
How?
MIX – a brief history
  • Central DVMRP global architecture
    • MBONE – a flat world
  • MBGP/PIM transit – preMSDP
  • MSDP/MBGP/PIM-SM


117
How?
MBONE
118
How?
MBGP/PIM transit – preMSDP
119
How?
MSDP/MBGP/PIM-SM – Today!
120
What’s Right?
121
What’s Right?
122
What’s Wrong?
123
What’s Wrong?
124
What’s Wrong?
125
What’s Wrong?
126
What’s Wrong?
127
What’s Wrong?
  • 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
Thank you!
  • shep@procket.com
  • http://www.procket.com
  • http://www.shepfarm.com/multicast