Multicast Source Discovery Protocol - MSDP
MSDP Definition
MSDP is an abbreviation for Multicast Source Discovery Protocol, which is designed to solve interconnection between multiple PIM-SM domains (Independent Multicast Sparse Mode Protocol, Protocol Independent Multicast Mode).
The inter-domain multicast solution is used to discover information about multicast sources in other PIM-SM domains.
Currently, MSDP only supports deployment on IPv4 networks, and intra-domain multicast routing protocol must be PIM-SM.
MSDP only makes sense for the ASM (Any-Source Multicast) model.
Introduction:
In PIM-SM mode, the DR (designated router) on the source side registers with the RP, and the DR on the member side initiates RP join messages, so the RP can get information about all multicast sources and multicast group members.
As the size of the network increases and multicast resource management becomes easier, the administrator can divide the PIM network into multiple PIM-SM domains.
At this time, RPs in each domain cannot know information about multicast sources in other domains.
MSDP can solve this problem.
MSDP establishes MSDP peers between routers in different PIM-SM domains (usually on a RP).
MSDP peers exchange SA (Source-Active) messages and share multicast source information.
Finally, it can be used in a single domain.
Multicast users receive multicast data sent by multicast sources in other domains.
MSDP is used to establish peers between ISPs.
Generally, ISPs are reluctant to use other providers' RPs to provide services to their users.
On the one hand, this is done for security reasons, on the other hand, if another provider's RP goes down and services are interrupted, users complain about their own.
With MSDP, each ISP can rely on its own RP to send and receive multicast data on the Internet.
Although MSDP is built for cross-domain multicasting, it also has a special application in the PIM-SM domain, Anycast RP (Anycast RP).
Anycast RP refers to setting up two or more RPs with the same address in the same PIM-SM domain and establishing MSDP peer relationships between these RPs to achieve load balancing and backup between RPs in the domain. ,
Advantage:
MSDP can implement cross-domain multicast and also has the following benefits for ISPs:
A PIM-SM domain can rely on RPs in its own domain to provide services while reducing its dependency on RPs in other domains. It can also control whether the original information of this domain is passed to other domains, which increases the security of the network.
If there is only a recipient in a particular domain, it does not need to be informed of group membership throughout the network and can only receive multicast data by reporting in the PIM-SM domain.
Devices in the same PIM-SM domain do not specifically need to maintain multicast source information and multicast routing table entries for the entire network, saving system resources.
Description of the principle
Peer MSDP:
The primary purpose of using MSDP to implement cross-domain multicast is to establish MSDP peers.
Typically, MSDP peer relationships are configured between RPs in each PIM-SM domain.
MSDP peers exchange SA (Source Active) messages.
SA messages carry (S, G) Information.
By passing information between these MSDP peers, SA messages sent by any RP can be received by all other RPs.
MSDP peers are configured for more than just RPs.
As shown in the figure below, MSDP peers can be created on any PIM router.
The functions of MSDP peers created on PIM routers with different roles are different. ,
Figure: MSDP Peer Location
Source :
https://support.huawei.com/enterprise/en/doc/EDOC1000141938/ff14f8b4/msdp-peers
MSDP peers created on RP:
| Classification of MSDP Partners | Position | Characteristics |
| Source Partner MSDP | The MSDP node closest to the multicast source (source) (typically the source RP, such as RP1) | The originating RP creates an SA message and sends it to the remote MSDP peer to notify the multicast source information registered on the RP. The MSDP source node must be configured on the RP, otherwise the multicast source information cannot be advertised. |
| MSDP peer recipient | MSDP node (for example, RP3) closest to the receiver (Receiver) | Upon receipt of the SA message, the MSDP node on the recipient side joins the SPT based on the multicast source across domains according to the multicast source information contained in the message; when multicast data arrives from the multicast source After that, it is forwarded to the local receiver via RPT. The recipient's MSDP peer must be configured to RP, otherwise information about multicast sources from other domains cannot be retrieved. |
| MSDP Intermediate Partner | MSDP peer with multiple remote MSDP peers (for example, RP2) | An intermediate MSDP peer forwards the SA message received from a remote MSDP peer to other remote MSDP peers, and its role is equivalent to that of a relay station for transmitting multicast source information. |
MSDP peers created on regular PIM routers (not RPs)
Such as RouterA and RouterB, their role is only to forward received SA messages.
MSDP protocol message:
MSDP protocol packets are encapsulated in TCP datagrams, and the format of the protocol packets follows the standard TLV (type-length-value) message format, as shown in the following figure:
Figure: MSDP message format
Source :
https://support.huawei.com/enterprise/en/doc/EDOC1000141938/8813c822/msdp-packets
MSDP message type:
Type 1: Source Active (SA)
Functions:
1. Transfer of several sets (S, G) of information and transfer between several RPs.
Key information included:
• The IP address of the source RP.
• The number (S, G) of elements contained in the message.
• List (S, G) active in the domain
2. Encapsulate PIM-SM multicast data.
Key information included:
• The IP address of the source RP.
• PIM-SM multicast data.
Type 2: Source-Active-Response (SA-Req)
Function:
Actively query the list (S, G) of the specified group G to reduce source attachment latency.
The message contains: the requested group address G.Type 3 Source-Active Response (SA-Resp) ：
Function:
Response to a Source-Active Request message.
The message contains:
• RP source IP address.
• The number (S, G) of elements contained in the message.
• List of actions (S, G) in the domainType 4: Keep Alive
Function:
To maintain communication between MSDP nodes.
It is sent only when there is no other message interaction protocol between the peers.
Type 5 reserved：
Function:
reserved type, currently used as notification.Type 6 Traceroute in Progress and Type 7 Traceroute Reply：
And function type 6: Traceroute function for MSDP, to discover the RPF transmission path of SA messages.
SA messages may carry (S, G) information and may also encapsulate multicast data packets.
MSDP peers exchange information (S, G) by exchanging SA messages.
To avoid a write timeout (S, G) in the SA message, the remote user cannot receive data from the multicast source, the SA message can be encapsulated in a multicast data packet.
Because SA messages are sent periodically when a new group of users enters the domain, you must wait for the SA message period to get valid (S, G) information.
To reduce the time delay for a new user group to join the original SPT, MSDP provides Type 2 and Type 3 SA-Req messages and SA-Resp messages to improve the efficiency of updating active source information.
Equality process:
Installing the MSDP partner:
MSDP peers are established over TCP connections using port 639.
After the two devices enable MSDP and designate each other as MSDP peers, the two devices first compare IP addresses.
If the IP address is less than one end, it will start the ConnectRetry timer and initiate a TCP connection.
The end with the higher IP address is responsible for confirming that a TCP connection has been established on port 639.
After the TCP connection is established, the MSDP peer relationship is established and the peers communicate via the KeepAlive message.
Figure: MSDP Peer Establishment Process
Source :
https://support.huawei.com/enterprise/en/doc/EDOC1000141938/111a9998/msdp-peer-setup
As shown in the figure above, the process for establishing an MSDP peer relationship between RouterA and RouterB is as follows:
Initially, the MSDP session state of both routers is Down.
After enabling MSDP on both ends and designating each other as MSDP peers, both ends compare the addresses used to establish the connection:
RouterA has a small address, enters the Connect state, initiates a connection to RouterB, and starts the ConnectRetry timer. This timer is used to determine the connection retry period.
RouterB has a large address and goes into idle state, waiting for a peer to connect.
After a successful TCP connection is established, the MSDP sessions on both ends go into the Up state.
Both ends of the MSDP peer send a KeepAlive message to notify each other that the MSDP connection status is being maintained.
MSDP Certification:
Encrypted authentication is performed when a TCP connection is established to ensure security. After configuring the authentication function, both ends of the MSDP node must use the same encryption algorithm and password to establish a TCP connection normally, otherwise the connection will not be established.
MSDP supports two encryption methods, MD5 and Keychain, which are mutually exclusive when used. Only one encryption method can be chosen between MSDP nodes.
Transferring information about multicast sources between domains:
As shown in the figure below, the PIM-SM network is divided into 4 PIM-SM domains.
There is an active multicast source (Source) in the PIM-SM1 domain, and RP1 becomes aware of the existence of the multicast source during the multicast source registration process.
If the PIM-SM2 and PIM-SM3 domains also want to know the specific location of the multicast source so that they can receive multicast data from the multicast source, you need to set up MSDP peers between RP1 and RP2, RP2 and RP3 respectively.
Source:
The process of transferring multicast source information between domains is as follows:
When a multicast Source in the PIM-SM1 domain sends the first multicast data packet to multicast group G, DR1 (designated router) encapsulates the multicast data in a register message and sends it to RP1.
Thus, RP1 learns the relevant multicast source information.
As the originating RP, RP1 creates an SA message and periodically sends it to its peer RP2. The SA message contains the address S of the multicast source, the address G of the multicast group, and the address of the source RP (RP1) that originated the SA message.
Upon receipt of the SA message, RP2 performs Reverse Path Forwarding (RPF) verification. The check passes and is sent to RP3, and at the same time, whether there are members of group G in the domain. Since there is no Group G recipient in the PIM-SM2 domain, RP2 does nothing else.
After RP3 receives the SA message, it performs an RPF check and the check passes. Since there are G members in the PIM-SM3 domain, an IGMP entry (*, G) will be generated on RP3 indicating that there are G members in this domain.
RP3 creates (S, G) records, sends (S, G) multicast source join messages, hop by hop, and creates a multicast path (SPT) from the source to RP3. After the multicast data reaches RP3 on the SPT, it is forwarded to the recipient on the RPT.
When the DR3 on the sink side receives the multicast data sent by the source, it can decide for itself whether to initiate an SPT switch.
Manage SA message forwarding:
SA messages are forwarded between MSDP peers.
In addition to RPF validation, filtering of various forwarding policies can be configured to only accept and forward SA messages that arrive on the correct path and are filtered to avoid SA message loops; in addition, you can set up an MSDP Mesh Group between MSDP peers to avoid overflowing SA messages between MSDP peers.
RPF discovery rules for SA messages:
To prevent round-robin SA messages between MSDP peers, MSDP performs RPF checks on received SA messages and strictly controls the inbound direction of message delivery. SA messages that do not conform to the RPF rules will be discarded.
The basic RPF validation rule is: after receiving an SA message, the MSDP device determines which peer is the next hop of the best path to the original RP (that is, the RP that created the SA message) according to the RPF Multicast Routing Information Base (MRIB).
This partner is also referred to as an "RPF Partner". If an SA message is found to have originated from an RPF peer, the SA message is accepted and forwarded to other peers. MRIB includes: MBGP, multicast static routing, unicast routing (including BGP, IGP).
In addition, there are the following RPF check rules, SA messages are respected while forwarding:
Rule 1: The peer that sends the SA message is the original RP, then it receives the SA message and forwards it to other peers.
Rule 2: Accept SA messages from static RPF nodes. A router can establish an MSDP peer relationship with multiple routers at the same time. Users can select one or more of these remote nodes and configure them as static RPF peers.
Rule 3: If the router has only one remote MSDP peer, the remote peer automatically becomes an RPF peer and the router receives SA messages from the remote peer.
Rule 4: The peer that sends the SA message and the local router belong to the same Mesh Group, then the SA message is accepted. SA messages from a Mesh Group are no longer forwarded to members belonging to the Mesh Group, but forwarded to all peers outside the Mesh Group.
Rule 5: If the route to the source RP must span multiple ASs, accept SA messages from peers in the next hop AS (in AS units) if there are multiple remote MSDP nodes in the AS.
Then get the SA message sent from the peer with the highest IP address.
Fully Connected MSDP Group (Mesh Group):
When there are multiple MSDP peers in the network, it is easy to flood SA messages between peers. At the same time, MSDP peers perform RPF checks on every incoming SA message, which places a heavy load on the system. Adding multiple MSDP peers to the same Mesh Group can greatly reduce the number of SA messages sent between those MSDP peers.
All members of a Mesh Group may belong to a single PIM-SM domain or may be distributed across multiple PIM-SM domains; they can all be in one or more ASs.
All members belonging to the same Mesh Group must establish an MSDP peer connection in pairs and recognize each other as a member of the Mesh Group. As shown in the figure below, RouterA, RouterB, RouterC, and RouterD join the same Mesh Group, and each router must be configured to establish an MSDP peer relationship with the other three routers.
Figure: MSDP Peer Connection Between Mesh Group Members
Source:
https://support.huawei.com/enterprise/en/doc/EDOC1000128406/61706d17/principles
When Mesh Group members receive an SA message, they first check the origin of the SA message:
If the SA message comes from an MSDP peer outside the Mesh Group, an RPF check is performed on the SA message.
If the check is passed, it is sent to all other members of the mesh group.
If the SA message originates from an internal member of the Mesh Group, it will be received directly without RPF checking.
At the same time, it is no longer forwarded to other members of the Mesh Group.
SA message filtering:
By default, MSDP does not filter SA messages, and SA messages sent from a domain can be delivered to MSDP peers throughout the network.
However, some (S, G) entries in the PIM-SM domain are only applicable for intra-domain forwarding. For example, some local multicast applications use global multicast group addresses, or multicast sources use private network addresses 10.xxx.
Without filtering, these (S, G) records will be passed to other MSDP peers via SA messages.
To solve this problem, you can set up filtering rules for SA messages (usually using ACLs to define the filtering rules) and use these rules when creating, forwarding, or receiving SA messages to filter SA messages.
Thank you.
