MVPN

Overview

An SP determines whether a particular VPN is multicast-enabled. If it is, it corresponds to a “Multicast Domain”. A PE which attaches to a particular multicast-enabled VPN is said to belong to the corresponding Multicast Domain. For each Multicast Domain, there is a default “Multicast Distribution Tree (MDT)” through the backbone, connecting ALL of the PEs that belong to that Multicast Domain. A given PE may be in as many Multicast Domains as there are VPNs attached to that PE. However, each Multicast Domain has its own MDT. The MDTs are created by running PIM in the backbone.

In a departure from the usual multicast tree distribution procedures, the Default MDT for a Multicast Domain is constructed automatically as the PEs in the domain come up. Construction of the Default MDT does not depend on the existence of multicast traffic in the domain; it will exist before any such multicast traffic is seen. Default MDTs correspond to the “MI-PMSIs” of [MVPN-ARCH].

Inclusive and Selective PMSIs

We will distinguish between two different kinds of PMSI(there is a third type of PMSI but I haven’t covered it here):

“Multidirectional Inclusive” PMSI (MI-PMSI) – [Also known as default mdt]: A Multidirectional Inclusive PMSI is one that enables ANY PE attaching to a particular MVPN to transmit a message such that it will be received by EVERY other PE attaching to that MVPN. There is at most one MI-PMSI per MVPN. An MI-PMSI can be thought of as an overlay broadcast network connecting the set of PEs supporting a particular MVPN.

“Selective” PMSI (S-PMSI) [Also known as data mdt]: A Selective PMSI is one that provides a mechanism wherein a particular PE in an MVPN can multicast messages so that they will be received by a subset of the other PEs of that MVPN. There may be an arbitrary number of S-PMSIs per PE per MVPN.

In BGP/IP MPLS VPNs, each CE router is a unicast routing adjacency of a PE router, but CE routers at different sites do NOT become unicast routing adjacencies of each other. This important characteristic is retained for multicast routing — a CE router becomes a PIM adjacency of a PE router, but CE routers at different sites do NOT become PIM adjacencies of each other. Multicast packets from within a VPN are received from a CE router by an ingress PE router. The ingress PE encapsulates the multicast packets and (initially) forwards them along the Default MDT tree to all the PE routers connected to sites of the given VPN. Every PE router attached to a site of the given VPN thus receives all multicast packets from within that VPN. If a particular PE routers is not on the path to any receiver of that multicast group, the PE simply discards that packet.

If a large amount of traffic is being sent to a particular multicast group, but that group does not have receivers at all the VPN sites it can be wasteful to forward that group’s traffic along the Default MDT. Therefore, we also specify a method for establishing individual MDTs for specific multicast groups. We call these “Data MDTs”. A Data MDT delivers VPN data traffic for a particular multicast group only to those PE routers which are on the path to receivers of that multicast group. Using a Data MDT has the benefit of reducing the amount of multicast traffic on the backbone, as well reducing the load on some of the PEs; it has the disadvantage of increasing the amount of state that must be maintained by the P routers. The SP has complete control over this tradeoff. Data MDTs correspond to the S-PMSIs.

Multicast VRFs

The notion of a “VRF”, defined in [RFC4364], is extended to include multicast routing entries as well as unicast routing entries. Each VRF has its own multicast routing table. When a multicast data or control packet is received from a particular CE device, multicast routing is done in the associated VRF. Each PE router runs a number of instances of PIM-SM, as many as one per VRF. In each instance of PIM-SM, the PE maintains a PIM adjacency with each of the PIM-capable CE routers associated with that VRF. The multicast routing table created by each instance is specific to the corresponding VRF. We will refer to these PIM instances as “VPN-specific PIM instances”, or “PIM C-instances”.

Each PE router also runs a “provider-wide” instance of PIM-SM (a “PIM P-instance”), in which it has a PIM adjacency with each of its IGP neighbors (i.e., with P routers), but NOT with any CE routers, and not with other PE routers (unless they happen to be adjacent in the SP’s network). The P routers also run the P-instance of PIM, but do NOT run a C-instance.

In order to help clarify when we are speaking of the PIM P-instance and when we are speaking of a a PIM C-instance, we will also apply the prefixes “P-” and “C-” respectively to control messages, addresses, etc. Thus a P-Join would be a PIM Join which is processed by the PIM P-instance, and a C-Join would be a PIM Join which is processed by a C-instance. A P-group address would be a group address in the SP’s address space, and a C-group address would be group address in a VPN’s address space.

Multicast Domains

Model of Operation

A “Multicast Domain (MD)” is essentially a set of VRFs associated with interfaces that can send multicast traffic to each other. From the standpoint of PIM C-instance, a multicast domain is equivalent to a multi-access interface. The PE routers in a given MD become PIM adjacencies of each other in the PIM C-instance.

Each multicast VRF is assigned to one MD. Each MD is configured with a distinct, multicast P-group address, called the “Default MDT group address”. This address is used to build the Default MDT for the MD.

When a PE router needs to send PIM C-instance control traffic to the other PE routers in the MD, it encapsulates the control traffic, with its own IPv4 address as source IP address and the Default MDT group address as destination IP address. Note that the Default MDT is part of P-instance of PIM, whereas the PEs that communicate over the Default MDT are PIM adjacencies in a C-instance. Within the C-instance, the Default MDT appears to be a multi-access network to which all the PEs are attached.

The Default MDT does not only carry the PIM control traffic of the MD’s PIM C-instance. It also, by default, carries the multicast data traffic of the C-instance. In some cases though, multicast data traffic in a particular MD will be sent on a Data MDT rather than on the Default MDT.

Multicast Tunnels

An MD can be thought of as a set of PE routers connected by a “multicast tunnel (MT)”. From the perspective of a VPN-specific PIM instance, an MT is a single multi-access interface. In the SP network, a single MT is realized as a Default MDT combined with zero or more Data MDTs.

Auto-Discovery

Any of the variants of PIM may be used to set up the Default MDT: PIM-SM, Bidirectional PIM [BIDIR], or PIM-SSM [SSM]. Except in the case of PIM-SSM, the PEs need only know the proper P-group address in order to begin setting up the Default MDTs. The PEs will then discover each others’ addresses by virtue of receiving PIM control traffic, e.g., PIM Hellos, sourced (and encapsulated) by each other. However, in the case of PIM-SSM, the necessary MDTs for an MD cannot be set up until each PE in the MD knows the source address of each of the other PEs in that same MD. This information needs to be auto-discovered.

A new BGP Address Family, MDT-SAFI is defined. The NLRI for this address family consists of an:

• RD
• IPv4 unicast address
• multicast group address

A given PE router in a given MD constructs an NLRI in this family from:

• Its own IPv4 address. If it has several, it uses the one which it will be placing in the IP source address field of multicast packets that it will be sending over the MDT.
• An RD which has been assigned to the MD.
• The P-group address, an IPv4 multicast address which is to be used as the IP destination address field of multicast packets that will be sent over the MDT.

When a PE distributes this NLRI via BGP, it may include a Route Target Extended Communities attribute. This RT must be an “Import RT” [RFC4364] of each VRF in the MD. The ordinary BGP distribution procedures used by [RFC4364] will then ensure that each PE learns the MDT-SAFI “address” of each of the other PEs in the MD, and that the learned MDT-SAFI addresses get associated with the right VRFs.

The encoding of the MDT-SAFI is specified in the following

subsection:

MDT-SAFI

BGP messages in which:-

• AFI=1 and
  
• SAFI=66
  

are “MDT-SAFI” messages.

The NLRI format is 8-byte-RD:IPv4-address followed by the MDT group address. i.e. The MP_REACH attribute for this SAFI will contain one or more tuples of the following form :

+——————————-+

|                                                       |

| RD:IPv4-address (12 octets) |

|                                                       |

+——————————-+

| Group Address (4 octets) |

+——————————-+

The IPv4 address identifies the PE that originated this route, and the RD identifies a VRF in that PE. The group address must be an IPv4 multicast group address, and is used to build the P-tunnels. All PEs attached to a given MVPN must specify the same group-address, even if the group is an SSM group. MDT-SAFI routes do not carry RTs, and the group address is used to associated a received MDT-SAFI route with a VRF.

More detail in MVPN can be found in draft-rosen-vpn-mcast-12.txt

Bidirectional PIM (bidir PIM)

Introduction

RFC5015 specifies Bidirectional PIM (BIDIR-PIM), a variant of PIM Sparse-Mode (PIM-SM) that builds bidirectional shared trees connecting multicast sources and receivers.

The shared tree for each multicast group is rooted at a multicast router called the Rendezvous Point (RP). Different multicast groups can use separate RPs within a PIM domain.

Bidirectional PIM dispenses with both encapsulation and source state by allowing packets to be natively forwarded from a source to the RP using shared tree state.

Terminology

RFC 5015 introduces some terminology for bidirectional PIM.

The following terms have special significance for BIDIR-PIM:

Multicast Routing Information Base (MRIB)

The multicast topology table, which is typically derived from the unicast routing table. It is used by PIM for establishing the RPF interface. In PIM-SM, the MRIB is also used to make decisions regarding where to forward Join/Prune messages, whereas in BIDIR-PIM, it is used as a source for routing metrics for the DF election process.

Rendezvous Point Address (RPA)

An RPA is an address that is used as the root of the distribution tree for a range of multicast groups. The RPA must be routable from all routers in the PIM domain. The RPA does not need to correspond to an address for an interface of a real router. In this respect, BIDIR-PIM differs from PIM-SM, which requires an actual router to be configured as the Rendezvous Point (RP). Join messages from receivers for a BIDIR-PIM group propagate hop-by-hop towards the RPA.

Rendezvous Point Link (RPL)

An RPL for a particular RPA is the physical link to which the RPA belongs. In BIDIR-PIM, all multicast traffic to groups mapping to a specific RPA is forwarded on the RPL of that RPA. The RPL is special within a BIDIR-PIM domain as it is the only link on which a Designated Forwarder election does not take place

Upstream

Towards the root (RPA) of the tree. The direction used by packets traveling from sources to the RPL.

Downstream

Away from the root of the tree. The direction on which packets travel from the RPL to receivers.

Designated Forwarder (DF)

The protocol presented in this document is largely based on the concept of a Designated Forwarder (DF). A single DF exists for each RPA on every link within a BIDIR-PIM domain (this includes both multi-access and point-to-point links). The only exception is the RPL on which no DF exists. The DF is the router on the link with the best route to the RPA (determined by comparing MRIB provided metrics). A DF for a given RPA is in charge of forwarding downstream traffic onto its link, and forwarding upstream traffic from its link towards the RPL. It does this for all the bidirectional groups that map to the RPA. The DF on a link is also responsible for processing Join messages from downstream routers on the link as well as ensuring that packets are forwarded to local receivers (discovered through a local membership mechanism such as IGMP).

State Summarization Macros

Using this state, we define the following “macro” definitions that we will use in the descriptions of the state machines and pseudocode in the following sections.

olist(G) =

RPF_interface(RPA(G)) (+) joins(G) (+) pim_include(G)

RPF_interface(RPA) is the interface the MRIB indicates would be used to route packets to RPA. The olist(G) is the list of interfaces on which packets to group G must be forwarded. The macro pim_include(G) indicates the interfaces to which traffic might be forwarded because of hosts that are local members on that interface.

Data Packet Forwarding Rules

The BIDIR-PIM packet forwarding rules are defined below in

pseudocode.

iif is the incoming interface of the packet.

G is the destination address of the packet (group address).

RPA is the Rendezvous Point Address for this group.

First we check to see whether the packet should be accepted based on TIB state and the interface that the packet arrived on. A packet is accepted if it arrives on the RPF interface to reach the RPA (downstream traveling packet) or if the router is the DF on the interface the packet arrives (upstream traveling packet). If the packet should be forwarded, we build an outgoing interface list for the packet. Finally, we remove the incoming interface from the outgoing interface list we’ve created, and if the resulting outgoing interface list is not empty, we forward the packet out of those interfaces.

On receipt of data to G on interface iif:

if( iif == RPF_interface(RPA) || I_am_DF(RPA,iif) ) {

oiflist = olist(G) (-) iif

forward packet on all interfaces in oiflist

}

Hopefully the above makes sense. If you want further details please see RFC 5015.

(Note: The above text was taken from RFC 5015)

PIM-SSM

IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols. For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-specific multicast use.

The SSM destination address 232.0.0.0 is reserved, and it must not be used as a destination address. Similarly, FF3x::4000:0000 is also reserved. The goal of reserving these two addresses is to preserve one invalid SSM destination for IPv4 and IPv6, which can be useful in an implementation as a null value.

The address range 232.0.0.1 – 232.0.0.255 is currently reserved for allocation by IANA.

The policy for allocating the rest of the SSM addresses to sending applications is strictly locally determined by the sending host.

When allocating SSM addresses dynamically, a host or host operating system MUST NOT allocate sequentially starting at the first allowed address. It is RECOMMENDED to allocate SSM addresses to applications randomly, while ensuring that allocated addresses are not given simultaneously to multiple applications (and avoiding the reserved addresses).

As described in the post “Layer 2 Multicast Addresses“, the mapping of an IP packet with an SSM destination address onto a link-layer multicast address does not take into account the datagram’s full source IP address (on commonly-used link layers like Ethernet). If all hosts started at the first allowed address, then with high probability, many source-specific channels on shared-medium local area networks would use the same link-layer multicast address. As a result, traffic destined for one channel subscriber would be delivered to another’s IP module, which would then have to discard the datagram.

Packet Forwarding

A router that receives an IP datagram with a source-specific destination address MUST silently drop it unless a neighboring host or router has communicated a desire to receive packets sent from the source and to the destination address of the received packet.

With PIM-SSM, successful establishment of an (S,G) forwarding path from the source S to any receiver depends on hop-by-hop forwarding of the explicit join request from the receiver toward the source. The protocol(s) and algorithms that are used to select the forwarding path for this explicit join must provide a loop-free path.

Protocol Behavior

A network can concurrently support SSM in the SSM address range and any-source multicast in the rest of the multicast address space, and it is expected that this will be commonplace. In such a network, a router may receive a non-source-specific, or “(*,G)” in conventional terminology, request for delivery of traffic in the SSM range from a neighbor that does not implement source-specific multicast in a manner compliant with this document. A router that receives such a non-source-specific request for data in the SSM range MUST NOT use the request to establish forwarding state and MUST NOT propagate the request to other neighboring routers. A router MAY log an error in such a case. This applies both to any request received from a host (e.g., an IGMPv1 or IGMPv2 [IGMPv2] host report) and to any request received from a routing protocol (e.g., a PIM-SM (*,G) join).

(The majority of the text above was taken from RFC4607.)

Layer 2 Multicast Addresses

Network Interface cards can accept Ethernet frames destined towards the following MAC addresses.

• BIA (Mac Address of the NIC)
• 0xFFFF.FFFF.FFFF (Broadcast Address)
• A range of multicast Address

In this post we will discuss the range of multicast addresses.

Ethernet Multicast Addresses

An Ethernet multicast address consists of the

• The IANA owned OUI MAC address 01:00:5e (24 bits) – which includes a multicast bit.
• IANA owns the OUI MAC address 01:00:5e, therefore multicast packets are delivered by using the Ethernet MAC address range 01:00:5e:00:00:00 – 01:00:5e:7f:ff:ff.
• The lower 23 bits of the multicast IP address are mapped into the remaining 23 bits of available ethernet address space.

The multicast addresses are in the range is 224.0.0.0 through 239.255.255.255. Therefore we can conclude the following:

• All multicast addresses have the first four bits in the first octet set to 1110.
• Therefore 28 bits remaining in the IP address to identify a unique multicast address.

The Diagram below illustrates the multicast MAC address range as well as an example of a Multicast Layer 3 Address encoding.

Multicast IP Address Encoding

When encoding layer 3 multicast addresses, the following observations can be seen.

• The first octect In the layer 3 address ie 239 in our example is not encoded.
• As all layer multicast addresses begin with 1110 as the first octect.
• As the remaining four bits in the 1^st octet of the multicast IP address are not encoded, we can say that 4 configurable bits are lost.
• We can also note that as the 4^th Octet in the Multicast MAC address has an upper limit of 7F, only 7 bits are available to encode the 2^nd octet of the multicast IP addresses which means an additional configurable bit is lost in encoding.
• Therefore a total of 5 configurable bits are lost during multicast IP to MAC encoding.
• The net result here is that 32 unique Multicast IP addresses when encoded will result in the same Multicast MAC address.

The diagram below illustrates how 32 Multicast Layer 3 addresses are encoded into 1 Multicast MAC Address.

Electing an RP (in brief)

The PIMv2 RFC states:

“This specification does not mandate the use of a single mechanism to provide routers with the information to perform the group-to-RP mapping. Currently four mechanisms are possible, and all four have associated problems:

1. Static Configuration: A PIM router MUST support the static configuration of group-to-RP mappings. Such a mechanism is not robust to failures, but does at least provide a basic interoperability mechanism.
2. Embedded-RP: Embedded-RP defines an address allocation policy in which the address of the Rendezvous Point (RP) is encoded in an IPv6 multicast group address.
3. Cisco’s Auto-RP: Auto-RP uses a PIM Dense-Mode multicast group to announce group-to-RP mappings from a central location.
4. BootStrap Router (BSR): RFC 2362 specifies a bootstrap mechanism based on the automatic election of a bootstrap router (BSR). Any router in the domain that is configured to be a possible RP reports its candidacy to the BSR, and then a domain-wide flooding mechanism distributes the BSR’s chosen set of RPs throughout the domain.

In this post we will look briefly at 1,3 and 4.

Static Configuration

Configuring a Static RP is fairly straight forward. The same RP is configured on each router in the multicast domain. There are some variations here where you can assign groups to different RPs to distributre the multicast load in the network.

Auto-RP

Auto-RP makes use of two multicast groups ie 224.0.1.39 and 224.0.1.40. The first address is 224.0.1.39 is used by the candidate RPs to announce their availability to be the RP for all or some multicast groups. The mapping agents listen for the candidate RP announcements and then send out group to RP mappings to the multicast group 224.0.1.40 address.

BSR

Within each multicast domain at least one of the routers must be configured as a candidate-BSR. The candidate BSR(s) each send Boot Strap Messages(BSM) out of all its interfaces to the ALL-PIM-ROUTERS (224.0.0.13) address. When a router receives Bootstrap message sent to `ALL-PIM-ROUTERS’ it performs the following:

1. If the message was not sent by the RPF neighbor towards the BSR address included, the message is dropped. (ie if a PIM router receives a message from the BSR on an interface which is not the route back to the BSR, the BSM is dropped.)
2. If the BSM is received on an interface which is the outgoing interface back towards the BSR then forwarded out all PIM interfaces, excluding the one over which the message arrived, to `ALL-PIM-ROUTERS’ group, with a TTL of 1.

The original messages sent out by the BSR do not contain any RP information as the candidate-RP has yet to be configured. Once a candidate-RP has been configured it sends a unicast candidate-RP advertisement to the BSR which in turn sends out a BSM containing the RP information to all the routers in the multicast domain.

The BSR collects the information from all candidate RPs. It places the information for all candidate RPs into subsequent Bootstrap messages. The BSR performs the election of the active RP of each group range only for its own use. Each router in the domain is responsible for running the RP-selection hash algorithm on the candidate RP information contained in the Bootstrap messages.

Note:

BSR differs from Auto-RP in that BSR does not create or require that any state is maintained in the mroute table. When using Auto-RP a method must be implemented to dense-flood the RP information throughout the multicast domain. This can be done in one of two ways, either implement PIM-Sparse-Dense mode or use the Auto-RP listener feature.

PIM Assert Messages

Where multiple PIM routers peer over a shared LAN, it is possible for more than one upstream router to have valid forwarding state for a packet, which can lead to packet duplication. PIM does not attempt to prevent this from occurring. Instead, it detects when this has happened and elects a single forwarder amongst the upstream routers to prevent further duplication. This election is performed using PIM Assert messages. Assert messages are also received by downstream routers on the LAN, and these cause subsequent Join/Prune messages to be sent to the upstream router that won the Assert.

The above content was taken from RFC 4601

Building the shared and shortest path Tree

The Shared tree is rooted at the RP and the shortest path tree is rooted at the Source of the multicast traffic.

The following processes will be discussed.

1. Building the shared tree between the receivers and the RP
2. Forwarding unicast PIM Register packets from the source to the RP
3. Building the shortest Path tree between the RP and the source
4. Building the Shortest-Path Tree between the Source and Receiver

Building the shared tree between the receivers and the RP

1. A multicast receiver expresses its interest in receiving traffic destined for a multicast group. Typically, it does this using IGMP or MLD.
2. One of the receiver’s local routers is elected as the Designated Router (DR) for that subnet.
3. On receiving the receiver’s expression of interest, the DR then sends a PIM Join message towards the RP for that multicast group.
4. This Join message is known as a (*,G) Join because it joins group G for all sources to that group.
5. The (*,G) Join travels hop-by-hop towards the RP for the group, and in each router it passes through, a multicast tree state for group G is instantiated.
6. Eventually, the (*,G) Join either reaches the RP or reaches a router that already has (*,G) Join state for that group.
7. When many receivers join the group, their Join messages converge on the RP and form a distribution tree for group G that is rooted at the RP.
8. This is known as the RP Tree (RPT), and is also known as the shared tree because it is shared by all sources sending to that group.
9. Join messages are resent periodically so long as the receiver remains in the group.
10. When all receivers on a leaf-network leave the group, the DR will send a PIM (*,G) Prune message towards the RP for that multicast group.
11. However, if the Prune message is not sent for any reason, the state will eventually time out.

Forwarding unicast PIM Register packets to the RP

1. A multicast data sender just starts sending data destined for a multicast group.
2. The sender’s local router (DR) takes those data packets, unicast-encapsulates them, and sends them directly to the RP.
3. The RP receives these encapsulated data packets, decapsulates them, and forwards them onto the shared tree.
4. The packets then follow the (*,G) multicast tree state in the routers on the RP Tree being replicated wherever the RP Tree branches, and eventually reaching all the receivers for that multicast group.
5. The process of encapsulating data packets to the RP is called registering, and the encapsulation packets are known as PIM Register packets.
6. At this stage, multicast traffic is flowing encapsulated to the RP, and then natively over the RP tree to the multicast receivers.

Building the shortest Path tree between the RP and the source

1. Register-encapsulation of data packets is inefficient for two reasons:
   1. Encapsulation and decapsulation may be relatively expensive operations for a router to perform, depending on whether or not the router has appropriate hardware for these tasks.
   2. Traveling all the way to the RP, and then back down the shared tree may result in the packets traveling a relatively long distance to reach receivers that are close to the sender. For some applications, this increased latency or bandwidth consumption is undesirable
2. Therefore when the RP receives a register-encapsulated data packet from source S on group G, it will normally initiate an (S,G) source-specific Join towards S.
3. This Join message travels hop-by-hop towards S, instantiating (S,G) multicast tree state in the routers along the path.
4. (S,G) multicast tree state is used only to forward packets for group G if those packets come from source S.
5. Eventually the Join message reaches S’s subnet or a router that already has (S,G) multicast tree state.
6. Packets from S start to flow following the (S,G) tree state towards the RP.
7. While the RP is in the process of joining the source-specific tree for S, the data packets will continue being encapsulated to the RP.
8. When packets from S also start to arrive natively at the RP, the RP will be receiving two copies of each of these packets.
9. At this point, the RP starts to discard the encapsulated copy of these packets.
10. The RP then sends a Register-Stop message back to S’s DR to prevent the DR from unnecessarily encapsulating the packets.
11. At this stage, traffic will be flowing natively from S along a source-specific tree to the RP, and from there along the shared tree to the receivers.
12. Where the two trees intersect, traffic may transfer from the source-specific tree to the RP tree and thus avoid taking a long detour via the RP.

Building the Shortest-Path Tree between the Source and Receiver

1. Although having the RP join back towards the source removes the encapsulation overhead, it does not completely optimize the forwarding paths.
2. For many receivers, the route via the RP may involve a significant detour when compared with the shortest path from the source to the receiver.
3. To obtain lower latencies or more efficient bandwidth utilization, a router on the receiver’s LAN, typically the DR, may initiate a transfer from the shared tree to a source-specific shortest-path tree (SPT).
4. To do this, it issues an (S,G) Join towards S.
5. This instantiates state in the routers along the path to S.
6. Eventually, this join either reaches S’s subnet or reaches a router that already has (S,G) state.
7. When this happens, data packets from S start to flow following the (S,G) state until they reach the receiver.
8. At this point, the receiver (or a router upstream of the receiver) will be receiving two copies of the data: one from the SPT and one from the RPT.
9. When the first traffic starts to arrive from the SPT, the DR or upstream router starts to drop the packets for G from S that arrive via the RP tree.
10. In addition, it sends an (S,G) Prune message towards the RP. This is known as an (S,G,rpt) Prune.
11. The Prune message travels hop-by-hop, instantiating state along the path towards the RP indicating that traffic from S for G should NOT be forwarded in this direction.
12. The prune is propagated until it reaches the RP or a router that still needs the traffic from S for other receivers.
13. By now, the receiver will be receiving traffic from S along the shortest-path tree between the receiver and S.
14. In addition, the RP is receiving the traffic from S, but this traffic is no longer reaching the receiver along the RP tree.
15. As far as the receiver is concerned, this is the final distribution tree.

The above content was taken from RFC 4601

Pim Packet Formats

The following information was taken from the RFCs below.

• RFC 4601(Obsoletes RFC 2362) — Protocol Independent Multicast – Sparse Mode (PIM-SM)
• RFC 5059 — Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)

To read the RFCs please visit the links below.

ftp://ftp.rfc-editor.org/in-notes/rfc4601.txt

ftp://ftp.rfc-editor.org/in-notes/rfc5059.txt

The following PIM packets formats are described within rfc 4601 and 5059.

RFC 4601 PIM Packet Formats

• Hello Message Format
• Register Message Format
• Register-Stop Message Format
• Join/Prune Message Format
• Assert Message Format

RFC 5059 PIM Packet Formats

• Bootstrap Message Format
• Candidate-RP-Advertisement Message Format

PIM Packet Header

All PIM control messages have IP protocol number 103. PIM messages are either unicast (e.g., Registers and Register-Stop) or multicast with TTL 1 to the ‘ALL-PIM-ROUTERS’ group (e.g., Join/Prune, Asserts, etc.). Candidate-RP-Advertisement messages are unicast to a BSR. Usually, Bootstrap messages are multicast with TTL 1 to the ALL-PIM-ROUTERS group, but in some circumstances (described in section 3.5.2 RFC 5059) Bootstrap messages may be unicast to a specific PIM neighbor.

The source address used for unicast messages is a domain-wide reachable address; the source address used for multicast messages is the link-local address of the interface on which the message is being sent.

The IPv4 ‘ALL-PIM-ROUTERS’ group is ‘224.0.0.13′. The IPv6 ‘ALL-PIM-ROUTERS’ group is ‘ff02::d’.

All the PIM Packets have the common header below.

The Pim Version is 2.

The Message type is one of those listed in the table below.

The “Reserved” field is set to zero on transmission and ignored upon receipt.

The “Checksum” is a standard IP checksum.

PIM Hello Packet

The PIM Hello packet contains the PIM common header as described above as well as a series of optional fields namely. Optiontype, OptionLength and OptionValue. Multiple Options triplets can be transmitted in the hello packet.

The OptionType is one of those listed in the table below.

Whether all of these options are implemented in IOS will be examined in subsequent posts.

Register Message Format

A Register message is sent by the DR to the RP when a multicast packet needs to be transmitted on the RP-tree. The IP source address is set to the address of the DR, the destination address to the RP’s address. The IP TTL of the PIM packet is the system’s normal unicast TTL.

The Register-Stop packet format

A Register-Stop is unicast from the RP to the sender of the Register message. The IP source address is the address to which the register was addressed. The IP destination address is the source address of the register message.

Join/Prune Message Format

A Join/Prune message is sent by routers towards upstream sources and RPs. Joins are sent to build shared trees (RP trees) or source trees (SPT). Prunes are sent to prune source trees when members leave groups as well as sources that do not use the shared tree.

Assert Message Format

The Assert message is used to resolve forwarder conflicts between routers on a link. It is sent when a router receives a multicast data packet on an interface on which the router would normally have forwarded that packet. Assert messages may also be sent in response to an Assert message from another router.

Multicast posts

In the next few weeks, time permitting I will try and cover the following range of subjects around multicast.

• PIM-V2
• PIM-SM
• PIM-SSM
• PIM-bidir
• Inter-domain Multicast
• MVPN
• Inter-As MVPN

To begin with here is a list of some important reserved multicast addresses.

Inter-AS Option B – Revisited

Consider the topology below.

Watch the video below or download and watch it on your iphone.