MULTICAST Tutorial RedIRIS/Red.es Miguel Angel Sotos

MULTICAST Tutorial RedIRIS/Red.es Miguel Angel Sotos

Agenda Introduction Multicast addressing Group Membership Protocol
PIM-SM / SSM MSDP MBGP 2

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

Unicast Multicast What is Multicasting? Server Router Server Router
Explain here what is a mcast tree 4

Multicast Uses Any Applications with multiple receivers
1-to-many or many-to-many Live Video distribution Seminars, conferences, workshops .... Collaborative groupware e-Learning 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 5

A bit of history In 1995 the first mcast network was born: MBone
DVMRP (Distance Vector Multicast Routing Protocol) was the protocol used DVMRP subnetworks was interconnected through the unicast Internet infrastructure with tunnels Flood and Prune technology Very successful in academic circles 6

Problem A bit of history
DVMRP can’t scale to Internet sizes Distance vector-based routing protocol Periodic updates Full table refresh every 60 seconds Table sizes Internet > 40,000 prefixes at that moment Scalability Too many tunnels, hop-count till 32 hops, etc Problem => In 1997, a native protocol is developed, Protocol Independent Multicast 7

The evolution PIM Dense mode Flood and Prune behavior very inefficient
Can cause problems in certain network topologies Creates (S, G) state in EVERY router Even when there are no receivers for the traffic Complex Assert mechanism To determine which router in a LAN will forward the traffic No support for shared trees Prune - podar 8

The evolution PIM Sparse mode Must configure a Rendezvous Point (RP)‏
Statically (on every Router)‏ Using Auto-RP or BSR (Routers learn RP automatically)‏ Very efficient Uses Explicit Join model Traffic only flows to where it’s needed Router state only created along flow paths Scales better than dense mode Works for both sparsely or densely populated networks 9

PIM Dense Mode Overview
Source Initial Flooding Receiver Multicast Packets (S, G) State created in every router in the network! Initial Flooding In this example, multicast traffic being sent by the source is flooded throughout the entire network. As each router receives the multicast traffic via its RPF interface (the interface in the direction of the source), it forwards the multicast traffic to all of its PIM-DM neighbors. Note that this results in some traffic arriving via a non-RPF interface such as the case of the two routers in the center of the drawing. (Packets arriving via the non-RPF interface are discarded.) These non-RPF flows are normal for the initial flooding of data and will be corrected by the normal PIM-DM pruning mechanism. 10

Source Pruning Unwanted Traffic Receiver Multicast Packets Prune Messages Pruning unwanted traffic In the example above, PIM Prunes (denoted by the dashed arrows) are sent to stop the flow of unwanted traffic. Prunes are sent on the RPF interface when the router has no downstream members that need the multicast traffic. Prunes are also sent on non-RPF interfaces to shutoff the flow of multicast traffic that is arriving via the wrong interface (i.e. traffic arriving via an interface that is not in the shortest path to the source.) An example of this can be seen at the second router from the receiver near the center of the drawing. Multicast traffic is arriving via a non- RPF interface from the router above (in the center of the network) which results in a Prune message. 11

Results After Pruning Source Receiver Multicast Packets Flood & Prune process repeats every 3 minutes!!! (S, G) State still exists in every router in the network! Results after Pruning In the final drawing in our example shown above, multicast traffic has been pruned off of all links except where it is necessary. This results in a Shortest Path Tree (SPT) being built from the Source to the Receiver. Even though the flow of multicast traffic is no longer reaching most of the routers in the network, (S, G) state still remains in ALL routers in the network. This (S, G) state will remain until the source stops transmitting. In PIM-DM, Prunes expire after three minutes. This causes the multicast traffic to be re-flooded to all routers just as was done in the “Initial Flooding” drawing. This periodic (every 3 minutes) “Flood and Prune” behavior is normal and must be taken into account when the network is designed to use PIM- DM. 12

This is generally expressed as (S,G).
(S,G) notation For every multicast source there must be two pieces 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 source for a particular group. The router creates a table with the entries (*,G),(S,G). 13

IP Multicast building blocks
The SENDERS send Multicast Addressing - rfc1700 class D ( )‏ 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 14

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" Reverse Path Forwarding Routers forward multicast datagrams received from incoming interface on distribution tree leading to source Routers check the source IP address against their multicast routing tables (RPF check); ensure that the multicast datagram was received on the specified incoming interface 15

Reverse Path Forwarding (RPF)‏
Multicast Forwarding Reverse Path Forwarding (RPF)‏ 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. Reverse Path Forwarding Routers forward multicast datagrams received from incoming interface on distribution tree leading to source Routers check the source IP address against their multicast routing tables (RPF check); ensure that the multicast datagram was received on the specified incoming interface 16

Multicast Forwarding Multicast uses unicast routes to determine path back to source RPF checks ensures packets won’t loop RPF checks are performed against routing table by default If multicast path is different from unicast path, then a multicast table will exist. It will be use for RPF check. Routes contain incoming interface Packets matching are forwarded Packets mis-matching are dropped 17

Example: RPF Checking Multicast Forwarding Source 151.10.3.21
Multicast Forwarding: RPF Checking Source floods network with multicast data Each router has a designated incoming interface (RPF interface) on which multicast data can be received from a given source Each router receives multicast data on one or more interfaces, but performs RPF check to prevent duplicate forwarding Example: Router receives multicast data on two interfaces 1) performs RPF Check on multicast data received on interface E0; RPF Check succeeds because data was received on specified incoming interface from source ; data forwarded through all outgoing interfaces on the multicast distribution tree 2) performs RPF Check on multicast data received on interface E1; RPF Check fails because data was not received on specified incoming interface from source ; data silently dropped RPF Check Fails Packet arrived on wrong interface! Mcast Packets 18

Multicast Distribution Trees
Shortest Path or Source Based Distribution Tree Group Member 1 Source Group Member 2 State Information: (S, G)‏ S = Source G = Group 19

Shared or Core Based Distribution Tree Group Member 1 Source 1 Group Member 2 State Information: (*,G)‏ * = Any Source G = Group Source 2 Core 20

Source or Shortest Path trees More resource intensive; requires more states (S,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 (*,G) You can get suboptimal 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)‏ IANA Reserved Addresses IANA is the responsible Authority for the assignment of reserved class D addresses. Other interesting reserved addresses are: PIMv1 (ALL-ROUTERS - due to transport in IGMPv1)‏ OSPF ALL ROUTERS (RFC1583)‏ OSPF DESIGNATED ROUTERS (RFC1583)‏ RIP2 Routers PIMv2 CISCO-RP-ANNOUNCE (Auto-RP)‏ CISCO-RP-DISCOVERY (Auto-RP) “ftp://ftp.isi.edu/in-notes/iana/assignments/multicast- addresses” is the authoritative source for reserved multicast addresses. Additional Information "Administratively Scoped IP Multicast", June 1997, has a good discussion on scoped addresses. This document is available at: “draft-ietf-mboned-admin-ip-space-03.txt” 21

Multicast Addressing IP Multicast Group Addresses
– 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 IANA Reserved Addresses IANA is the responsible Authority for the assignment of reserved class D addresses. Other interesting reserved addresses are: PIMv1 (ALL-ROUTERS - due to transport in IGMPv1)‏ OSPF ALL ROUTERS (RFC1583)‏ OSPF DESIGNATED ROUTERS (RFC1583)‏ RIP2 Routers PIMv2 CISCO-RP-ANNOUNCE (Auto-RP)‏ CISCO-RP-DISCOVERY (Auto-RP) “ftp://ftp.isi.edu/in-notes/iana/assignments/multicast- addresses” is the authoritative source for reserved multicast addresses. Additional Information "Administratively Scoped IP Multicast", June 1997, has a good discussion on scoped addresses. This document is available at: “draft-ietf-mboned-admin-ip-space-03.txt” 23

Multicast Addressing Administratively Scoped Addresses – RFC 2365
– Private address space Similar to RFC 1918 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: /16 Organization-local scope: /14 IANA Reserved Addresses IANA is the responsible Authority for the assignment of reserved class D addresses. Other interesting reserved addresses are: PIMv1 (ALL-ROUTERS - due to transport in IGMPv1)‏ OSPF ALL ROUTERS (RFC1583)‏ OSPF DESIGNATED ROUTERS (RFC1583)‏ RIP2 Routers PIMv2 CISCO-RP-ANNOUNCE (Auto-RP)‏ CISCO-RP-DISCOVERY (Auto-RP) “ftp://ftp.isi.edu/in-notes/iana/assignments/multicast- addresses” is the authoritative source for reserved multicast addresses. Additional Information "Administratively Scoped IP Multicast", June 1997, has a good discussion on scoped addresses. This document is available at: “draft-ietf-mboned-admin-ip-space-03.txt” 24

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: 25

Multicast Addressing Examples of Reserved & Link-local Addresses reserved & not forwarded Administrative Scoping Source-Specific Multicast All local hosts All local routers DVMRP OSPF Designated Router OSPF RIP2 PIM CBT VRRP IANA Reserved Addresses IANA is the responsible Authority for the assignment of reserved class D addresses. Other interesting reserved addresses are: PIMv1 (ALL-ROUTERS - due to transport in IGMPv1)‏ OSPF ALL ROUTERS (RFC1583)‏ OSPF DESIGNATED ROUTERS (RFC1583)‏ RIP2 Routers PIMv2 CISCO-RP-ANNOUNCE (Auto-RP)‏ CISCO-RP-DISCOVERY (Auto-RP) “ftp://ftp.isi.edu/in-notes/iana/assignments/multicast- addresses” is the authoritative source for reserved multicast addresses. Additional Information "Administratively Scoped IP Multicast", June 1997, has a good discussion on scoped addresses. This document is available at: “draft-ietf-mboned-admin-ip-space-03.txt” 26

Group Membership Protocol PIM-SM / SSM M-BGP MSDP
Introduction Multicast addressing Group Membership Protocol PIM-SM / SSM M-BGP MSDP 27

Internet Group Membership Protocol (IGMP)‏
How hosts tell routers about group membership Routers solicit group membership from directly connected hosts RFC 2236 specifies version 2 of IGMP Supported on every OS IGMP version 3 is the latest version RFC 3376 provides source include-list capabilities (SSM!)‏ Support? Unix latest versions, Window XP, Vista IGMP The primary purpose of IGMP is to permit hosts to commincate their desire to receive multicast traffic to the IP Multicast router(s) on the local network. This, in turn, permits the IP Multicast router(s) to “Join” the specified multicast group and to begin forwarding the multicast traffic onto the network segment. The initial specification for IGMP (v1) was documented in RFC 1112, “Host Extensions for IP Multicasting”. Since that time, many problems and limitations with IGMPv1 have been discovered. This has lead to the development of the IGMPv2 specification which was ratified in November, 1997 as RFC Even before IGMPv2 had been ratified, work on the next generation of the IGMP protocol, IGMPv3, had already begun. However, the IGMPv3 specification is still in the working stage and has not been implemented by any vendors. 28

IGMPv2 Protocol Flow - Join a Group
I want Forwards stream Router adds group I want to JOIN! 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

IGMPv2 Protocol Flow - Querier
Still interested? (general query)‏ I want group Yes, me! 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

IGMPv2 Protocol Flow - Leave a Group
I don’t want anymore < > group I want to leave! Anyone still want this group? Hosts send leave messages to all routers group indicating group they’re leaving. Router follows up with 2 group-specific queries messages 31

IGMPv3 Source = 1.1.1.1 Group = 224.1.1.1 R1 R3 R2 Source = 2.2.2.2
H1 - Member of R1 R3 R2 Source = IGMPv3: MODE_IS_INCLUDE Join , H1 wants to receive from S = but not from S = With IGMPv3, specific sources can be pruned back - S = in this case draft-holbrook-idmr-igmpv3-ssm- 01.txt RFC 3376 Enables hosts to listen only to a specified subset of the hosts sending to the group Video Server IGMPv3 Example (future)‏ In this example, host “H1” has joined group but only wishes to receive traffic from Source Using an as yet unspecified IGMPv3 mechanism, the host can inform the designated router, “R3”, that it is only interested in multicast traffic from Source for Group Router “R3” could then potentially “prune” this specific (S,G) traffic source. 32

IGMP Enhancements IGMP Version 2 IGMP Version 3
multicast router with lowest IP address is elected querier Group-Specific Query message is defined. Enables router to transmit query to specific multicast address rather than to the "all-hosts" address of Leave Group message is defined. Last host in group wishes to leave, it sends Leave Group message to the "all-routers" address of 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

PIM-SM Protocol Independent Multicast - sparse mode
draft-ietf-pim-sm-v2-new-10.txt 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 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 (V1 & V2)‏ Bootstrap Router (V2)‏ 36

PIM-SM Shared Tree Join
Receiver RP (*, G) Join Shared Tree (*, G) State created only along the Shared Tree. PIM-SM Shared Tree Joins In this example, there is an active receiver (attached to leaf router at the bottom of the drawing) has joined multicast group “G”. The leaf router knows the IP address of the Rendezvous Point (RP) for group G and when it sends a (*,G) Join for this group towards the RP. This (*, G) Join travels hop-by-hop to the RP building a branch of the Shared Tree that extends from the RP to the last-hop router directly connected to the receiver. At this point, group “G” traffic can flow down the Shared Tree to the receiver. 37

PIM-SM Sender Registration
Receiver RP Source Shared Tree (S, G) Register (unicast)‏ Source Tree (S, G) State created only along the Source Tree. Traffic Flow PIM-SM Sender Registration As soon as an active source for group G sends a packet the leaf router that is attached to this source is responsible for “Registering” this source with the RP and requesting the RP to build a tree back to that router. The source router encapsulates the multicast data from the source in a special PIM SM message called the Register message and unicasts that data to the RP. When the RP receives the Register message it does two things It de-encapsulates the multicast data packet inside of the Register message and forwards it down the Shared Tree. The RP also sends an (S,G) Join back towards the source network S to create a branch of an (S, G) Shortest-Path Tree. This results in (S, G) state being created in all the router along the SPT, including the RP. (S, G) Join 38

Receiver RP Source Shared Tree Source Tree Traffic Flow (S, G) traffic begins arriving at the RP via the Source tree. RP sends a Register-Stop back to the first-hop router to stop the Register process. (S, G) Register (unicast)‏ (S, G) Register-Stop PIM-SM Sender Registration (cont.)‏ As soon as the SPT is built from the Source router to the RP, multicast traffic begins to flow natively from source S to the RP. Once the RP begins receiving data natively (i.e. down the SPT) from source S it sends a ‘Register Stop’ to the source’s first hop router to inform it that it can stop sending the unicast Register messages. 39

Receiver RP Source Shared Tree Source Tree Traffic Flow Source traffic flows natively along SPT to RP. PIM-SM Sender Registration (cont.)‏ At this point, multicast traffic from the source is flowing down the SPT to the RP and from there, down the Shared Tree to the receiver. From RP, traffic flows down the Shared Tree to Receivers. 40

PIM-SM SPT Switchover RP Source Last-hop router joins the Source Tree.
Receiver RP (S, G) Join Source Source Tree Shared Tree Last-hop router joins the Source Tree. Additional (S, G) State is created along new part of the Source Tree. Traffic Flow PIM-SM Shortest-Path Tree Switchover PIM-SM has the capability for last-hop routers (i.e. routers with directly connected members) to switch to the Shortest-Path Tree and bypass the RP if the traffic rate is above a set threshold called the “SPT-Threshold”. The default value of the SPT-Threshold” in Cisco routers is zero. This means that the default behaviour for PIM-SM leaf routers attached to active receivers is to immediately join the SPT to the source as soon as the first packet arrives via the (*,G) shared tree. In the above example, the last-hop router (at the bottom of the drawing) sends an (S, G) Join message toward the source to join the SPT and bypass the RP. This (S, G) Join messages travels hop-by-hop to the first- hop router (i.e. the router connected directly to the source) thereby creating another branch of the SPT. This also creates (S, G) state in all the routers along this branch of the SPT. 41

PIM-SM SPT Switchover RP Source Traffic Flow
Receiver RP Source Source Tree Shared Tree (S, G)RP-bit Prune Traffic begins flowing down the new branch of the Source Tree. Additional (S, G) State is created along along the Shared Tree to prune off (S, G) traffic. Traffic Flow PIM-SM Shortest-Path Tree Switchover Once the branch of the Shortest-Path Tree has been built, (S, G) traffic begins flowing to the receiver via this new branch. Next, special (S, G)RP-bit Prune messages are sent up the Shared Tree to prune off the redundant (S,G) traffic that is still flowing down the Shared Tree. If this were not done, (S, G) traffic would continue flowing down the Shared Tree resulting in duplicate (S, G) packets arriving at the receiver. 42

PIM-SM SPT Switchover RP Source
Receiver RP Source Source Tree Shared Tree (S, G) Traffic flow is now pruned off of the Shared Tree and is flowing to the Receiver via the Source Tree. Traffic Flow PIM-SM Shortest-Path Tree Switchover As the (S, G)RP-bit Prune message travels up the Shared Tree, special (S, G)RP-bit Prune state is created along the Shared Tree that selectively prevents this traffic from flowing down the Shared Tree. At this point, (S, G) traffic is now flowing directly from the first-hop router to the last-hop router and from there to the receiver. 43

Receiver RP Source Source Tree Shared Tree (S, G) traffic flow is no longer needed by the RP so it Prunes the flow of (S, G) traffic. Traffic Flow (S, G) Prune PIM-SM Shortest-Path Tree Switchover At this point, the RP no longer needs the flow of (S, G) traffic since all branches of the Shared Tree (in this case there is only one) have pruned off the flow of (S, G) traffic. As a result, the RP will send (S, G) Prunes back toward the source to shutoff the flow of the now unnecessary (S, G) traffic to the RP Note: This will occur IFF the RP has received an (S, G)RP-bit Prune on all interfaces on the Shared Tree. 44

Receiver RP Source Source Tree Shared Tree (S, G) Traffic flow is now only flowing to the Receiver via a single branch of the Source Tree. Traffic Flow PIM-SM Shortest-Path Tree Switchover As a result of the SPT-Switchover, (S, G) traffic is now only flowing from the first-hop router to the last-hop router and from there to the receiver. Notice that traffic is no longer flowing to the RP. As a result of this SPT-Switchover mechanism, it is clear that PIM SM also supports the construction and use of SPT (S,G) trees but in a much more economical fashion than PIM DM in terms of forwarding state. 45

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. 46

PIM-SSM No shared trees No register packets No RP required
No RP-to-RP source discovery (MSDP)‏ Requires IGMP include-source list – IGMPv3 Host must learn of source address out-of-band (web page)‏ Requires host-to-router source AND group request Hard-coded behavior in 232/8 Configurable to expand range 47

PIM-SSM Receiver RP Receiver announces desire
to join group G AND source S with an IGMPv3 include-list. IGMPv3 host report (S, G) Join Last-hop router joins the Source Tree. Source Source Tree Traffic Flow (S,G) state is built between the source and the receiver. 48

PIM-SSM RP Source Data flows down the source tree to the receiver.
Traffic Flow 49

MSDP Multicast Source Discovery Protocol RFC 3618
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 may trigger (S,G) joins on behalf of local receivers MSDP connections typically parallel MBGP connections 51

MSDP Operation MSDP peers (inter or intra domain)‏
(TCP port 639 with 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 its sources within its domain interested parties can send PIM JOIN’s towards source (creates inter-domain source trees)‏ 52

MSDP Source Active Messages
Initial SA message sent when source first registers May optionally encapsulate first data packet Subsequent SA messages periodically refreshed every 30 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 53

MSDP Overview r s Domain E Domain C Domain B Domain D Domain A
SA Message , Domain C Domain B Domain D Domain E SA Source Active Messages Domain A r Join (*, )‏ MSDP Peers RP s Register , 54

RP r MSDP Peers (S, )‏ Join s 55

RP r MSDP Peers Multicast Traffic s 56

MSDP Peers MSDP establishes a neighbor relationship between MSDP peers
Peers connect using TCP port 639 MSDP peers may 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)‏ 57

RPF-peer Rules Skip RPF Check and accept SA if:
Sending MSDP peer is default-peer Sending 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-hop toward the originating RP. The one with the highest IP address of all the MSDP peers in the AS path toward the originating RP. The static RPF-peer. 58

MSDP with SSM – Unnecessary!
Domain C Domain B Domain D Domain E Domain A RP r ASM MSDP Peers (irrelevant to SSM)‏ s Source in 232/8 Receiver learns S AND G out of band; ie Web page 59

MSDP with SSM – Unnecessary!
Domain C Domain B Domain D Domain E Domain A RP r ASM MSDP Peers (irrelevant to SSM)‏ s Source in 232/8 Receiver learns S AND G out of band; ie Web page 60

MSDP Application: Anycast-RP
RFC 3446 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! 61

MSDP Anycast-RP RP1 – lo0 RP2 – lo0 Rec Src Y.Y.Y.Y X.X.X.X 10.0.0.1
62

Anycast-RP RP2 – lo0 Y.Y.Y.Y Rec Src RP1 – lo0 X.X.X.X X 63

MBGP Overview Multiprotocol Extensions to BGP (RFC 2858).
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 65

MBGP Overview MBGP: Multiprotocol BGP (multicast BGP in multicast networks)‏ Defined in RFC 2858 (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, … 66

MBGP Overview New multiprotocol attributes: MP_REACH_NLRI
Used to advertise one or more routes to a peer that shares the same path attribute MP_UNREACH_NLRI Used to indicate a previously route is no longer reachable They include the next information: 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)‏ This information is used to build routing tables Allows different policies and topologies between multicast and unicast 67

MBGP—Capability Negotiation
RFC 2842 BGP routers establish BGP sessions through the OPEN message OPEN message contains optional parameters BGP session is terminated if OPEN parameters are not recognised MBGP peers use this procedure to determine if they support MBGP and which AFIs and SAFIs support each one 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 68

Summary 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. 69

Summary ISP Requirements Current solution: MBGP + PIM-SM + MSDP
Environment ISPs run iMBGP and PIM-SM (internally)‏ ISPs multicast peer at a public interconnect Deployment Border routers run eMBGP The interfaces on interconnect run PIM-SM RPs’ MSDP peering must be consistant with eMBGP peering All peers set a common distance for eMBGP 70

MULTICAST Tutorial RedIRIS/Red.es Miguel Angel Sotos

Similar presentations

Presentation on theme: "MULTICAST Tutorial RedIRIS/Red.es Miguel Angel Sotos"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

MULTICAST Tutorial RedIRIS/Red.es Miguel Angel Sotos

Similar presentations

Presentation on theme: "MULTICAST Tutorial RedIRIS/Red.es Miguel Angel Sotos"— Presentation transcript:

Similar presentations

About project

Feedback