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)
No comments yet.