| Internet-Draft | Abbreviated Title | October 2024 |
| Zhang, et al. | Expires 24 April 2025 | [Page] |
PIM usually uses the shortest path computed by routing protocols to build multicast tree. Multi-Topology Routing is a technology to enable service differentiation within an IP network. IGP Flex Algorithm provides a way to compute constraint-based paths over the network. This document defines the PIM message extensions to provide a way to build multicast tree through the specific topology and constraint-based path instead of the shortest path.¶
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 24 April 2025.¶
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.¶
As described in section 3 in [RFC7761], PIM relies on an underlying topology-gathering protocol to populate the MRIB (Multicast Routing Information Base). Usually the MRIB is the best paths over the network based on the IGP metric. In some cases, alternative paths with low latency or high bandwidth are needed for specific requirements.¶
Multi-Topology Routing (MTR) [RFC4915] [RFC5120] is a technology to enable service differentiation within an IP network. To support MTR, an IGP advertises multiple, potentially incongruent, IP topologies, and computes topology specific routes.¶
Flex-Algo [RFC9350] specifies a solution that allows IGPs themselves to compute constraint-based paths over the network. Flex-Algo(FA) can be seen as creating a sub-topology within a topology using algorithm specific constraints and an algorithm specific calculation type. Flex-algo can operate on any topology supported by the IGPs.¶
Advertisement of IGP Flex-Algo [RFC9350] participation requires a data plane context. Currently the following dataplane contexts have been defined:¶
This document defines how PIM can utilize a given combination of a topology, an algorithm, and a dataplane to populate an MRIB. In the remainder of this document, we'll refer to this combination as Topology-Algorithm-Dataplane (TAD).¶
All the routers on a given PIM multicast tree MUST participate in the same TAD.¶
This document defines the PIM message extensions to provide a way to build a multicast tree using a given TAD instead of simple IGP shortest path.¶
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 [RFC2119].¶
This document uses terminologies defined in [RFC7761], [RFC5384], [RFC5496], [RFC4915], [RFC5120] and [RFC9350].¶
[I-D.ietf-pim-pfm-forwarding-enhancements] defines a 'Group Source Info TLV' for announcing sources that supports Sub-TLVs that can be used to advertise various types of information. This document defines a new Sub-TLV that can be used for carrying the topology ID and the Algorithm value associated with the TAD to be used.¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | MT-ID | DP-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MT-ID values are protocol specific. The value advertised therefore has to match an MT-ID value supported by the IGP deployed in the network.¶
[RFC5384] defines a pim Join Attributes are encoded as TLVs into the Encoded-Source Address field of a PIM Join message. This document specifies the TAD Attribute that allows the receiver to select the associated topology or algorithm.¶
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|E| Type | Length | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID | DP-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MT-ID values are protocol specific. The value advertised therefore has to match an MT-ID value supported by the IGP deployed in the network.¶
When TAD is specified, PIM MUST use the topology, algorithm and data-plane specified.¶
PIM Flooding Mechanism and Source Discovery [RFC8364] allows for announcement of active sources. [I-D.ietf-pim-pfm-forwarding-enhancements] defines a 'Group Source Info TLV' for announcing sources that allows for Sub-TLVs that can be used for providing various types of information. The TAD Sub-TLV is advertised with the Group Source Info TLV, and flooded in the network. When MTR is not deployed in the network, the MT-ID in the Sub-TLV MUST be set to zero.¶
The First Hop Router (FHR) advertises the announcing sources carrying the TAD Sub-TLV to the network. All the routers in the network receive the information through PFM function. If two or more FHRs announce same source and group with different TAD because of wrong configurations or other reasons, the LHR SHOULD select the TAD by using the lowest or highest originator address. The highest originator address is preferred.¶
The LHR PIM router on the receiving side specifies the TAD to the multicast source according to the received TAD Sub-TLV or the local policy. The LHR looks up the local TAD aware routing table and gets the upstream neighbor, then the LHR sends the join message to the upstream neighbor with the specified TAD value set in the TAD attribute. The local configured TAD is the same with the advertisement of LHR usually. In case there is inconsistent, the LHR MUST NOT send the J/P message with TAD attribute. When there is no specific TAD in local policy or configuration on LHR, LHR SHOULD use the TAD received by PFM advertisements if there is.¶
When a PIM router receives a J/P message with the TAD attribute, the router checks all the received join messages, if all the received join messages carried the TAD value, then it looks up the TAD specific unicast routes and selects the incoming interface and upstream neighbor. And the continual join messages keep carrying the TAD Attribute. When the LHR stops to use the function defined in this document, LHR MUST send the associated prune message. And the continual prune message MUST carried the attribute.¶
When a PIM router receives the join messages from different neighbors for the same (*,G) or (S,G), in case the router finds that not all the received join messages carried the same TAD value, or unicast routing is unreachable in the TAD aware routing table, the router needs to stop the PIM procedure and sends notification to the network administrator. If the router is FHR, the FHR SHOULD NOT forward the multicast flow until all the received join messages carried the same TAD value.¶
The TAD attribute SHOULD NOT be used with RPF vector attribute([RFC5496]). In case the TAD attribute is also received with the RPF vector attribute, the router SHOULD ignore one of them according to local policy.¶
There should be no more than one TAD attribute in an Encoded-Source Address when PIM build a join message. If the PIM router receives a join message with multiple TAD attributes in an Encoded-Source Address, the first one is RECOMMENDED be used.¶
+----(gR2)------(gR4)----+
/ | | \
/ | | \
Source--(R1)(RP) | | (R6)--Recv
\ | | /
\ | | /
+----(rR3)------(rR5)----+
In Figure 3, there is only a default topology in the network. R1 is the source DR and R6 is last-hop DR. Two multicast flows need to be received by the receiver: flow 1 (192.0.2.1/24, 233.252.0.1/32) and flow 2 (198.51.100.1/24, 233.252.0.2/32). The shortest paths to the two sources are the same: R6-R4-R2-R1. But the bandwidth on the path is not enough for the two flows delivery. Packet loss occurs.¶
The network can be divided into 2 planes by different Flex-Algorithms defined in [RFC9350]. For example, R1/R2/R4/R6 belong to green plane of Algorithm X, and R1/R3/R5/R6 belong to red plane of Algorithm Y.¶
When the soft dataplane defined in [I-D.ginsberg-lsr-flex-soft-dataplane] is used, the TAD combinations can be TAD 1 "FA=X, MT-ID=0, DP-ID=3" and TAD 2 "FA=Y, MT-ID=0, DP-ID=3". All the routers send the participation of Flex-algo X and Y per [I-D.ginsberg-lsr-flex-soft-dataplane]. The IP prefix routes for the sources of flow 1/2 are advertised in default topology.¶
R1 sends the PFM messages for flow 1 with TAD 1 sub-TLV and flow 2 with TAD 2 sub-TLV. After receiving the PFM messages, when JoinDesired(192.0.2.1, 233.252.0.1) ([RFC7761]) is TRUE, R6 looks up the local routing by the TAD 1, and gets the upstream router R4 for flow 1. When JoinDesired(198.51.100.1, 233.252.0.2) is TRUE, the process of R6 for TAD 2 is similar, R6 gets the upstream router R5 for flow 2. Then R6 sends the PIM join messages with the TAD 1 to R4 for flow 1 and TAD 2 to R5 for flow 2. All the routers along the path process the join messages in similar way and the multicast trees for flow 1 and flow 2 are built finally.¶
When the the IP Flex dataplane defined in [RFC9502] is used, the DP-ID field in the TAD combination should be 2. All the routers send the participation of Flex-algo X and Y per [RFC9502]. The IP prefix routes for the sources of flow 1 and 2 are advertised with FA X and Y separately. Similar with the soft dataplane, the multicast trees for flow 1 and flow 2 are built by two different TADs separately.¶
IANA is request to assign a new sub-type for "Group Source Info TAD Sub-TLV" in the "PFM Group Source Info Sub-Types" registry.¶
IANA is request to assign a new sub-type for "TAD Attribute" in the "PIM Join Attribute Types" registry.¶
IANA is request to create a new registry for "Dataplane ID" in the "Interior Gateway Protocol (IGP) Parameters" registry. For now, three values are defined:¶
The consideration mentioned in [RFC7761], [I-D.ietf-pim-pfm-forwarding-enhancements] and [I-D.ginsberg-lsr-flex-soft-dataplane] apply to this document.¶
If PIM routers in the multicast tree select different topology and algorithm based on different local policy, there may be a loop in the network, or the multicast flow cannot be forwarded. Forged router may advertise source and group information with wrong TAD sub-TLV. The network administrator should be careful for the TAD consistency.¶
The authors would like to acknowledge Les Ginsberg, Peter Psenak for their input on this document.¶