MSDP Operation

MSDP-speaking routers form peer relationships, similar to BGP peers, over a TCP connection. Two MSDP peers can be in the same PIM-SM domain or in two separate domains. Within a domain, MSDP enables creation of multiple RPs, facilitating redundancy and load balancing. Anycast RP is the primary example of intradomain MSDP.

Between different domains, MSDP enables RPs to exchange source information from their respective domains, allowing interdomain source discovery to occur.

An RP that wants to participate in IMR must speak MSDP. However, an MSDP speaker does not necessarily have to be an RP. Non-RP routers can be configured for MSDP, which may be useful in a domain that does not support multicast sources but does support multicast transit. A non-RP MSDP speaker does not originate any source information but provides transit for source information from other domains.

When an MSDP-speaking RP receives a PIM Register message, it generates an MSDP Source-Active message for the source-group pair and forwards the message to all of its configured MSDP peers. The SA message contains the source address, the group address, and the address of the RP. Additionally, the encapsulated data in the Register message is copied by the RP into the MSDP SA.

Subsequent Register messages for the same source-group pair do not cause the creation of other SA messages, unless sufficient time has passed since the last SA was sent. More specifically, the router generates another SA only if the SA hold-down timer has expired. Each time the router sends an SA, it resets the SA hold-down timer to a default value of 30 seconds.

Upon receiving an SA message, a router checks to see if the message was received from its MSDP RPF-peer for the originator of the message. The rules used for determining the MSDP RPF-peer are different from those used for determining the PIM RPF neighbor. The rules are explained in detail in section 5.4. If the SA is received from a peer other than the RPF peer, the SA is ignored and discarded.

On the other hand, if the message was indeed received from its RPF peer, the SA is forwarded to all other MSDP peers. The process of sending SA messages to all other MSDP peers if received from the appropriate peer is known as peer-RPF flooding. Peer-RPF flooding guarantees the SA message will be delivered throughout the Internet but will not be unnecessarily looped back toward the originator of the message.

If the MSDP-speaking router receiving an SA happens to be an RP, additional processing of the MSDP SA message may be required. The RP determines if its domain has any interested members of the groups included in the message. If so, the RP forwards the encapsulated data packet contained within the message down the RPT for the group and sends a PIM (S,G) Join message toward its RPF neighbor for the source to join the SPT.

MSDP announces the existence of multicast sources. It does not announce the presence of multicast receivers, which is an advantage because the nature of multicast is to have fewer sources than receivers. Some PIM-SM domains do not have any multicast sources (or do not have any multicast sources that need to be announced to the rest of the Internet). MSDP provides an added advantage to these receiver-only domains because they can receive data without advertising group membership to the rest of the Internet.

Earlier drafts of MSDP did not require that every MSDP-speaking router maintain global source state. Routers were not required to maintain a cache of the information received within MSDP SA messages. If a noncaching RP receives a PIM Join message from an interested receiver in its domain, it sends an SA-Request message to an MSDP peer to request source information for that group. An SA-caching MSDP-speaker that receives an SA-Request message replies with an SA-Response message that contains the set of all SA entries it has for the requested group.

Caching SA messages reduces join latency since the RP that receives a PIM Join can quickly determine all the sources for the requested group by looking in its own SA cache without having to ask other MSDP peers. Thus receivers in this domain are delivered multicast traffic much more quickly. SA caching is also helpful when troubleshooting problems related to MSDP. Without a cache, MSDP message tracing is needed to identify the reception of each SA.

Because of these advantages, the more recent versions of the MSDP specification explicitly require SA caching.

Nearly all MSDP deployments have enabled SA caching. MSDP-speaking Juniper Networks routers implement mandatory SA caching, and this behavior cannot be disabled. On Cisco Systems routers, SA caching is a configurable option.

The disadvantage of SA caching is increased state. A caching router maintains state for every source on the Internet.

This method has brought into question the ability of MSDP to scale to millions of sources and provides the potential for SA storms, which are discussed in section 5.7.

This document is created with the unregistered version of CHM2PDF Pilot

This document is created with the unregistered version of CHM2PDF Pilot