| Internet-Draft | Static Multicast Distribution Trees | January 2024 |
| Nandy, et al. | Expires 10 July 2024 | [Page] |
This document specifies the Static Provision of Multicast route as an alternate to Layer 3 Multicast protocols like PIM-SM (Protocol Independent Multicast - Sparse Mode), PIM SSM (Source-Specific Multicast), or PIM BIDI (Bidirectional). It works like a standalone Multicast Route provisioning feature that can interoperate with other dynamic Multicast protocols like PIM-SM or with L2 protocols like IGMP (Internet Group Management Protocol) and MLD (Multicast Listener Discovery). This feature can function with/without the use of Unicast Routing Protocols to build the Multicast tree.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 10 July 2024.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This document specifies a static protocol for efficiently routing multicast groups that may span across wide-area (and inter-domain) internet as well as small enterprises and Data Center networks that use IP Multicast.¶
One general issue with Layer 3 multicast protocols is that they can become extremely complex to operate as well as debug as they may span an entire enterprise network. They also depend on Unicast Routing Protocols for creating the Multicast Tree and performing RPF (Reverse Path Forwarding) checks thereby making the operation even more complex both configuration-wise as well as from the point of view of resolving issues.¶
It has been also found that enabling a full-fledged layer 3 protocol like PIM-SM or PIM-BIDI might not be an ideal option for relatively simpler topologies like a centralized router that is routing multicast traffic across L2 domains. The nature of tree formation in a protocol like PIM-SM also tends in unsuitable for any sort of summarization.¶
The proposal is to create Static Multicast Route that works very similarly to Static Unicast Route. The Static Multicast Routes in theory will look very similar to Dynamic Multicast Routes in the Multicast FIB. The Route will have an incoming Interface (typically RPF interface towards the Source or RP), Source address, Group address as the Key, and a list of Outgoing Interfaces as Value. This way, Multicast Tree can be formed statically without the requirement of any dynamic Protocols like PIM.¶
The Static provisioning of Multicast Routes will also be quite handy for small-scale enterprises with limited L3 connectivity as well for overlay Networks where we don't want PIM to run on top of Tunnels like VxLAN.¶
This can also be useful if we want to provision the network statically through a Centralized SDWAN controller or a Cloud-based Network Management System. The different use cases and detailed functions are explained in subsequent sections.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].¶
In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying significance described in RFC 2119.¶
Static multicast route works similar to the static unicast route where the user explicitly specifies the incoming interface, source address, group address and the set of downstream interfaces to replicate the traffic. In a typical multicast network, source and group addresses are learnt from the data traffic and the set of downstream interfaces are derived from IGMP joins from clients or PIM joins from the adjacent multicast routers. However, with increasing number of clients and routers, these dynamic protocols pose some processing overhead on the routers. With static multicast route, this can be avoided.¶
Typical static multicast route looks like¶
[Incoming Interface, Source, Group]. [Set of downstream interfaces]¶
where, Incoming Interface is the l3 interface from where the traffic is received on the router. User can choose not to explicitly specify the incoming interface, but choose the interface based on RPF checks based on the unicast routes.¶
Source is the source ip address of the streaming device. It can be * also, which indicates any source ip address.¶
Group is the multicast ip address of the group for which the traffic is streamed.¶
Downstream interface is an L3 interface on which a PIM join is received or to which the receivers are connected.¶
Source/Group address can also be configured with subnet mask. If there are multicast sources/groups falling in the same subnet range and having the same set of downstream interfaces to send the traffic to, then the static multicast route can be configured with subnet mask for source/group.¶
When a static multicast route is configured, it will stay until the user removes it. However, static multicast route can also be configured with an expiry time so that it will be removed automatically from the MFIB after the expiry time.¶
A null multicast route is a multicast route which drops the traffic at the incoming port without replicating traffic to any of the downstream interfaces. It can be configured statically by specifying null interface as downstream for a specific multicast flow.¶
The states of a static multicast route are straight forward as it is user configured. A static multicast route will be considered active as far as the incoming interface and the port(s) on which the incoming traffic is replicated is operational. The interfaces that are down will not be included in the forwarding port list of the multicast entry programmed. Static multicast route will not timeout based on traffic inactivity, but can be configured with an expiry- time so that the entry will be automatically removed after the expiry time.¶
An important case that needs to be considered here is when a statically configured multicast route is also learnt by the dynamic multicast routing protocol, say PIM-SM. In such cases, the user configured multicast routes should take precedence over the PIM learnt routes by default. If the set of downstream interfaces learnt from PIM/IGMP are different from the statically configured downstream interfaces, a choice can be given to the administrator to program the combination of both statically and dynamically learnt downstream interfaces for the mroute (multicast route). Also, dynamically learnt multicast routes can be preferred over the matching static multicast entries by associating administrative distance with the static and dynamic mroutes. Likewise, a backup static multicast route can be supported by associating a higher administrative distance value with the static multicast routes. A backup route will be considered for programming when the primary static multicast becomes inactive.¶
A static multicast route can also be configured without explicitly mentioning the incoming interface, in which case the incoming interface is derived from the unicast route to reach the source address. The advantage of this approach is that if the primary path to the multicast source goes down, the corresponding static multicast route can still be operational through the alternate path selected by unicast routing protocols. If the source address is not reachable via any path, the static multicast route should not be programmed into the multicast route table and should be considered inactive.¶
Interoperation of static multicast routes with dynamic multicast protocols is mentioned in Section 5 below.¶
A static multicast route can stay on the forwarding path even as its multicast software is restarted or during a Management Module failover.¶
A restarting router can adjust its forwarding in a timely manner after the restart if it detects that the static multicast route is no more operational. In such cases, the inactive static multicast routes should be cleared from the forwarding table and backup routes should be programmed as applicable.¶
Multicast routing protocols like PIM and IGMP are responsible for construction of the multicast delivery tree on overlay networks. These traditional multicast routing protocols achieve this by exchanging mroutes in control packets along with configuring policies across all devices in the overlay. Coupling ip mobility and ip multicast in Overlay networks can induce issues like network inactivity due to overhead of encapsulation/decapsulation, large bandwidth consumption, multicast routing state maintenance, latency and frequent recalculation and construction of multicast delivery tree in many devices in the overlay. For a multicast network managed by centralized controllers, we need to address requirements such as: separate multicast flow calculation on behalf of each node in the Overlay Network, application aware traffic forwarding with flow-based priorities, and dynamically respond to network changes. Similar requirements arise in multi-fabric deployments running VxLAN overlay or IPsec based SD-WAN overlay networks.¶
In such network deployments, the border gateway router, which is part of the fabric as well as the overlay network, can function as the hybrid router running both legacy for intra-fabric and static/controller programmed multicast routing for overlay. The IGMP/PIM joins originated from the receivers/clients in the customer network through legacy multicast routing protocols (PIM, IGMP, MLD etc) are learnt on the border gateway routers and these joins, along with the path to source through the overlay, are used derive/configure the static multicast route. A multicast distribution tree is formed for each flow on every border router based on the overlay interfaces through which the Source is reachable. As mentioned above, source reachability information is either available in the Unicast Routing table or can be statically configured. Multiple distribution trees may be formed per border router if there are multiple sources that the clients are interested in. The Simple Service Discovery Protocol (SSDP) is an application layer protocol and one of the key protocols that implement Universal Plug and Play (UPnP). SSDP enables network devices to discover and advertise network services by sending multicast discovery and advertisement messages to multicast IPv4 group address 239.255.255.250:1900 or multicast IPv6 group address FF0x::C[1]. Because of the nature of the way UPnP works, each device will generate a unique multicast flow (Source IP, SSDP Group IP). In a multicast network with a large number of end user devices, this can bloat up the multicast hardware/software resources as each device will create a unique (S, G) flow and the resources are limited. In networks, where there is a need to control/drop/minimize SSDP traffic, summarized static multicast routes can be configured to save network resources and to avoid denial of services.¶
Static Multicast Distribution Trees can be used in cases where there is a fixed source and set of clients like video conferencing where interruptions due to route updates can be avoided.¶
The Static Multicast Route feature will interop with the PIM-SM and PIM-SSM protocol features. The Static Multicast Route will mostly be in the last Hops/Client-side to be interoperated by the PIM-SM protocol. The section below describes the interoperability with PIM- SM/PIM-SSM.¶
+----------------------------+
+------+ | +------+ iface3 +------+ |
|Source| | | R4 +--------+Client| |
+------+ | +--+---+ +------+ |
¶
| | |iface2 |¶
| RP | | |
+--+---+ +------+ iface1| +--+---+ STATIC |
| R1 +-------+ R2 +-------|---+ R3 | MROUTES |
+------+ +------+ | +------+ |
+----------------------------+
Fig. 1
¶
Static multicast routes give the flexibility to the user to program a specific path for multicast traffic from the source till the client without having to rely on the underlying protocols to build a multicast route. They can be configured on all the routers in the path or on a specific section of routers. The remaining section of routers can be configured to run the native PIM protocol. In Fig. 1, static multicast routes are configured on routers R3 and R4 whereas PIM protocol builds the multicast routes on routers R1 and R2. R3 acts as a gateway where the static multicast routes terminate.¶
There are two ways of programming a static mroute. One is (S, G) based and the other is (*, G) based as explained in the next sections.¶
This section describes the non summarized multicast routes where the flow contains a specific source. In Fig 1, on R3, a static mroute is programmed as follows.¶
Flow Incoming Outgoing
Interface Interface
S,G Iface 1 Iface 2
Similarly on R4, a static mroute is programmed as follows.
Flow Incoming Outgoing
Interface Interface
S,G Iface 2 Iface 3
It is to be noted that PIM protocol is enabled on R3 but not on R4.
¶
The source would have registered to R2 (RP) via the native PIM path. So R1 and R2 will contain the multicast routes.¶
On R3, where the static multicast routes terminate, a redistribute command is configured to inform PIM about the static mroute. This will ensure that PIM creates an Upstream (S, G) state and sends an S, G join to R2 via iface 1. This join reaches R1 which forwards the source traffic to R2 which in turn starts routing the (S, G) traffic to iface 1. This traffic will be routed on R3 and R4 based on the static mroutes programmed and will eventually reach the clients. It is to be noted that on R3, PIM immediately switches to Source specific Tree (SPT) without having to go via RP Tree since the Source is already known.¶
The difference from the conventional PIM protocol is the trigger to create the Upstream (S, G) state. In general, it is created only when multicast data packet is received. But in case of static mroutes, the redistribute option can also create the Upstream (S, G) state.¶
On an incoming interface I1, when there are multiple sources S1..n, , sending multicast traffic to a single group G, and if the outgoing interfaces are also the same, then instead of having individual mroutes for every (I1, Si, G) where i = 1..n, a single summarized (*,G) mroute entry on interface I1 is programmed which will help in saving hardware resources.¶
There are two types of summarizations.¶
i) Implicit Summarization - The network administrator configures multiple static mroutes with same group address, same incoming and outgoing interfaces but different source addresses. These routes are implicitly summarized into a single (*, G) mroute entry.¶
ii) Explicit Summarization - The network administrator explicitly configures a summarized (*, G) static mroute without specifying the source ip.¶
+----------------------------+
+---------+ | +------+ iface3 +------+ |
|Source S1| | | R4 +--------+Client| |
+---------+ | +--+---+ +------+ |
¶
| | |iface2 |¶
| RP | | |
+--+---+ +------+ iface1| +--+---+ STATIC |
| R1 +-------+ R2 +-------|---+ R3 | MROUTES |
+------+ +------+ | +------+ |
| +----------------------------+
|
+---------+
|Source S2|
+---------+
Fig. 2
¶
In Fig. 2, On R3, two static mroutes are programmed for different sources but for same group, with same incoming and outgoing interface as follows:¶
Flow Incoming Outgoing
Interface Interface
S1,G Iface 1 Iface 2
S2,G Iface 1 Iface 2
¶
This implies that multicast traffic incoming on interface 1, destined to group G from sources S1 and S2, will be routed to interface 2. These multicast routes are implicitly summarized into a single multicast route entry as follows:¶
Flow Incoming Outgoing
Interface Interface
*,G Iface 1 Iface 2
¶
Similarly on R4, two static multicast routes are programmed as follows.¶
Flow Incoming Outgoing
Interface Interface
S1,G Iface 2 Iface 3
S2,G Iface 2 Iface 3
which will be summarized as
Flow Incoming Outgoing
Interface Interface
*,G Iface 2 Iface 30
¶
On R3, where the static multicast routes terminate, a redistribute command is configured for PIM. Since the source ip addresses are specified, PIM will create Upstream (S, G) states for S1 and S2 and sends (S, G) joins towards both the sources on iface 1.¶
The joins reach R1, which forwards multicast traffic from sources S1 and S2 to R2 which in turn starts routing the traffic to iface 1. This traffic will be routed on R3 and R4 based on the static mroutes programmed and will eventually reach the clients. Like in the earlier case, PIM immediately switches to Source Specific Tree (SPT) for all the specified sources without having to go via RP Tree since the source ip addresses are already known.¶
On R3, a static mroute can be programmed without mentioning the source ip as follows:¶
Flow Incoming Outgoing
Interface Interface
*,G Iface 1 Iface 2
¶
This implies that multicast traffic incoming on interface 1, destined to group G from any source, will be routed to interface 2. Similarly on R4, a static mroute is programmed as follows:¶
Flow Incoming Outgoing
Interface Interface
*,G Iface 2 Iface 3
¶
On R3, where the static multicast routes terminate, redistribute command is configured for PIM. Since the source ip is not known in this case, PIM creates an Upstream (*, G) state and sends a (*, G) PIM join towards the RP router .R2 on iface 1. RP will be aware of all the sources since they would have registered to it via the native PIM protocol.¶
Once the (*, G) join is received, R2 starts routing the traffic to iface 1. This traffic will be routed on R3 and R4 based on the static mroutes programmed and will eventually reach the clients. It is to be noted that the traffic continues to flow via the RP-Tree path and there will not be a source tree switch.¶
For a same group address, it is possible to have both summarized and non-summarized multicast routes. Consider the following scenario:¶
+-----------------------------+
| |
+---------+ | +------+ iface4 +-------+ |
| | | | | | | |
|Source S1| | | R4 +--------+Client1| |
| | | | | | | |
+---------+ | +--+---+ +-------+ |
| | | |
| | |iface2 |
| | | |
| RP | | |
| | | |
+--+---+ +------+ iface1| +--+---+ iface3 +-------+ |
| | | | | | | | | |
| R1 +-------+ R2 +-------|---+ R3 +--------+Client2| |
| | | | | | | | | |
+------+ +------+ | +------+ +-------+ |
| | |
| +-----------------------------+
|
-------------
| |
| |
| |
+---------+ +---------+
| | | |
|Source S2| |Source S3|
| | | |
+---------+ +---------+
Fig. 3
¶
Client 1 is interested in traffic from Sources S1 and S2 traffic whereas Client 2 is interested in traffic from Source S3. The following static multicast routes will be programmed in R3:¶
Flow Incoming Outgoing
Interface Interface
*,G Iface 1 Iface 2
S3,G Iface 1 Iface 3
¶
It can be seen that there is a summarized multicast route to cater to Sources S1 and S2 traffic and a specific S, G mroute entry to cater to Source S3 traffic. Since the outgoing interface is different for S3, G it cannot be summarized into the (*, G) entry.¶
When lookup happens in the multicast routing table, (S, G) entries are given precedence over (*, G) entry. If a matching (S, G) entry is not found, then a summarized (*, G) entry for that group (if present) will be selected for forwarding. In this case when the traffic streamed from Source S3 lands on R3, the (S3, and G) mroute entry will be used for forwarding the traffic. (*, G) entry will be used for all other sources (other than S3) which stream to group G on Iface 1.¶
In a typical network with Static Multicast Routes, we will not be requiring RP. The Network that Requires RP will be either exporting Static Multicast Routes from downstream or will be a pure PIM-SM/PIM BIDI-based network.¶
The RP router by itself will never require a Static Multicast Route to be configured for any Sources that are registering on it. We do not want to have the RPT path from RP to Client be static.¶
Static Multicast Route both summarized and non-summarized can interop with PIM-BIDI. The Designated Forwarded for that particular subnet can pick up the Summarized Multicast Route and forward it towards the RP.¶
The router in a subnet that is not a DF will actually export the Static Multicast Route towards the DF for it forward the same towards the RP.¶
In the same way, any traffic hitting southbound to a Router that is both PIM BIDI and Static Multicast Route enabled, the protocol can simply program the entry as per the Static Multicast Route if that is configured.¶
The Static Multicast Route option can be used to misdirect network traffic by providing incorrect downstream interfaces. This can be either a Denial of Service attack, where the downstream interface configured has no active clients connected or configuring multiple invalid static multicast routes to use up system resources. Care should be taken to explicitly remove stale static multicast routes to avoid traffic drops, and duplications and to optimize resource usage. Static multicast routes should be configured in a manageable manner and scale. This is also significant as the static multicast route configuration can impact the way PIM control packets are handled, as explained in section 5.¶
This document does not contain any IANA actions.¶
This document was prepared using 2-Word-v2.0.template.dot.¶