RFC 7442

Carrying Protocol Independent Multicast - Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) Mode Trees over Multipoint LDP (mLDP)

📅 published February 2015, from ietf

Carrying PIM-SM ASM Trees over mLDP ✨

Okay bestie, this one is RFC 7442, and it's a Standards Track doc (the real deal, not a someday-maybe) 💅 It was written by Y. Rekhter (Juniper Networks), R. Aggarwal (Arktan), N. Leymann (Deutsche Telekom), W. Henderickx (Alcatel-Lucent), and Q. Zhao and R. Li (Huawei). It came out in February 2015, and it's published as ISSN 2070-1721. The header doesn't list anything it obsoletes or updates, so it's standing on its own 🌸

The title is "Carrying Protocol Independent Multicast - Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) Mode Trees over Multipoint LDP (mLDP)" and yes, it's a mouthful 🙈

Abstract ✨

When IP multicast trees made by PIM-SM in ASM mode need to cross an MPLS domain, it might be really useful to map them onto Point-to-Multipoint Label Switched Paths (P2MP LSPs). This doc explains how to pull that off when the P2MP LSPs get set up with the Label Distribution Protocol (LDP) extensions for P2MP and Multipoint-to-Multipoint LSPs, which is Multipoint LDP (mLDP) 🦋

Status of This Memo 🎀

This is an Internet Standards Track document.

It's a product of the Internet Engineering Task Force (IETF), so it reflects the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741.

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7442 💖

Copyright (c) 2015 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 (http://trustee.ietf.org/license-info) as they stood on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document. Any Code Components pulled out of this document have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 🫶

Table of Contents 🧚

1. Introduction ....................................................3
   1.1. Specification of Requirements ..............................4
2. Mechanism 1 - Non-transitive Mapping of IP Multicast
   Shared Trees ....................................................4
   2.1. Originating Source Active Auto-discovery Routes
        (Mechanism 1) ..............................................4
   2.2. Receiving Source Active Auto-discovery Routes by LSR .......5
   2.3. Handling (S,G,RPT-bit) State ...............................5
3. Mechanism 2 - Transitive Mapping of IP Multicast Shared Trees ...6
   3.1. In-Band Signaling for IP Multicast Shared Trees ............6
   3.2. Originating Source Active Auto-discovery Routes
        (Mechanism 2) ..............................................7
   3.3. Receiving Source Active Auto-discovery Routes ..............8
   3.4. Pruning Sources Off the Shared Tree ........................8
   3.5. More on Handling (S,G,RPT-bit) State .......................9
4. IANA Considerations .............................................9
5. Security Considerations .........................................9
6. References .....................................................10
   6.1. Normative References ......................................10
   6.2. Informative References ....................................10
Acknowledgements ..................................................11
Authors' Addresses ................................................11

1. Introduction 🦋

[RFC6826] explains how to map P2MP LSPs made by mLDP [RFC6388] onto multicast trees that PIM-SM builds in Source-Specific Multicast (SSM) mode [RFC4607]. This doc is the other half: it shows how to map mLDP P2MP trees onto multicast trees built by PIM-SM in ASM mode. It describes two possible mechanisms for doing that 💅

The first mechanism, in Section 2, is OPTIONAL for implementations. The second one, in Section 3, is REQUIRED for every implementation that claims conformance to this spec ✨

Quick heads up: from a deployment point of view, these two mechanisms are mutually exclusive. On the same network you could deploy one or the other, but not both. Not both, bestie 🙈

You're expected to already know PIM-SM [RFC4601] and mLDP [RFC6388] before reading this.

This doc leans on the procedures in [RFC6826] to support source trees. For example, following those procedures, a Label Switching Router (LSR) may start an mLDP Label Map with the Transit IPv4/IPv6 Source TLV for (S,G) when it gets a PIM (S,G) Join 🧁

This doc uses BGP Source Active auto-discovery routes, as defined in [RFC6514]. To keep things short from here on, we'll just call them "Source Active auto-discovery routes" 🎀

Here's a scenario: the service provider has set up the network so the Rendezvous Point (RP) for a particular ASM group G is always between the receivers and the sources. When it's set up that way, the ingress Provider Edge (PE) for (S,G) is always the same as the ingress PE for the RP. So the Source Active auto-discovery (A-D) routes are never needed at all. If you already know the network is set up like that, mLDP in-band signaling can use a different set of procedures, specified in [RFC7438]. A service provider will provision its PE routers to use either the procedures in [RFC7438] or the ones in this document 🌸

Like [RFC6826], each IP multicast tree gets mapped one-to-one to a P2MP LSP in the MPLS network. This works really well if the MPLS network operator controls how many LSPs get created, or if the number of LSPs for a given service is known to be limited ⭐

Also, the existing BGP Multicast VPN (MVPN) procedures [RFC6514] can already map Internet IP multicast trees to P2MP LSPs. They cover IP multicast trees from PIM-SM in SSM mode and also from PIM-SM in ASM mode. These procedures can also aggregate several IP multicast trees into one P2MP LSP in the MPLS network. The details of that approach are out of scope for this doc 🍓

This doc assumes that a given LSR might have some interfaces that are IP multicast capable, while other interfaces are MPLS capable 🧚

1.1. Specification of Requirements 💜

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]. These are the official BCP 14 key words, so when you see them in caps, they're doing real work 🔥

2. Mechanism 1 - Non-transitive Mapping of IP Multicast Shared Trees 🌈

This mechanism does NOT transit IP multicast shared trees over the MPLS network. So when an LSR creates (*,G) state (because it got PIM messages on one of its IP multicast interfaces), the LSR does not propagate that state in mLDP 🙅‍♀️

Hmm, I need to keep that exact: this mechanism does not transit shared trees. Fixing my own draft: "This mechanism does not transit IP multicast shared trees over the MPLS network." Lowercase, no caps, since no keyword is here 💅

2.1. Originating Source Active Auto-discovery Routes (Mechanism 1) 🦋

Whenever an RP discovers a new multicast source (because it received either PIM Register or Multicast Source Discovery Protocol (MSDP) messages), the RP SHOULD originate a Source Active auto-discovery route. The route carries a single MCAST-VPN Network Layer Reachability Information (NLRI) [RFC6514], built like this:

  • The Route Distinguisher (RD) in this NLRI is set to 0.
  • The Multicast Source field is set to S. This could be either an IPv4 or an IPv6 address. The Multicast Source Length field is set appropriately to reflect the address type.
  • The Multicast Group field is set to G. This could be either an IPv4 or an IPv6 address. The Multicast Group Length field is set appropriately to reflect this address type.

To keep distribution of the Source Active auto-discovery route inside the Autonomous System (AS) of the advertising RP, this route SHOULD carry the NO_EXPORT Community ([RFC1997]) 🎀

Using normal BGP procedures, the Source Active auto-discovery route gets propagated to all other LSRs within the AS ✨

Whenever the RP finds out the source is no longer active, the RP MUST withdraw the Source Active auto-discovery route, but only if the RP advertised one before 🫶

2.2. Receiving Source Active Auto-discovery Routes by LSR 🧁

Picture an LSR that has some interfaces capable of IP multicast and some capable of MPLS multicast 💖

When an LSR creates a new (*,G) entry in its Tree Information Base (TIB), because it got PIM messages on one of its IP multicast interfaces, and that entry has a non-empty outgoing interface list containing one or more IP multicast interfaces, the LSR MUST check whether it has any Source Active auto-discovery routes for that G. If there's such a route, the S of that route is reachable via an MPLS interface, and the LSR doesn't have (S,G) state in its TIB for the (S,G) carried in the route, then the LSR originates the mLDP Label Map with the Transit IPv4/IPv6 Source TLV carrying (S,G), as specified in [RFC6826] 🔥

When an LSR gets a new Source Active auto-discovery route, the LSR MUST check whether its TIB contains a (*,G) entry with the same G as the one carried in that route. If such an entry is found, the S is reachable via an MPLS interface, and the LSR doesn't have (S,G) state in its TIB for the (S,G) carried in the route, then the LSR originates an mLDP Label Map with the Transit IPv4/IPv6 Source TLV carrying (S,G), as specified in [RFC6826] 🌸

2.3. Handling (S,G,RPT-bit) State 🦋

Creating and deleting (S,G,RPT-bit) PIM state ([RFC4601]) on an LSR, when that state comes from PIM messages received on one of its IP multicast interfaces, doesn't trigger any mLDP and/or BGP actions by the LSR. Zero drama, zero actions 🙌

Part 1 of 2 is done, bestie 🧚 Part 2 (Mechanism 2, IANA, Security, and the References) is coming next 💖

3. Mechanism 2 - Transitive Mapping of IP Multicast Shared Trees ✨

Okay bestie, Mechanism 2 is where shared trees get to go on a whole road trip across the MPLS network 🧚. When an LSR creates (*,G) state because it got PIM messages on one of its IP multicast interfaces, it passes that state along in mLDP. It's giving teamwork 🫶

Heads up 💅: if, for a given G, none of the PEs originate an (S,G) mLDP Label Map with the Transit IPv4/IPv6 Source TLV, then no Source Active auto-discovery routes will be used. Another situation where none get used is described in Section 3.2 ("Originating Source Active Auto-discovery Routes (Mechanism 2)"). In all of these scenarios, the only part of Mechanism 2 in play is the in-band signaling for IP Multicast Shared Trees, which is up next 🌸

3.1. In-Band Signaling for IP Multicast Shared Trees

So to support in-band mLDP signaling for shared trees, this document defines two brand new mLDP TLVs: the Transit IPv4 Shared Tree TLV and the Transit IPv6 Shared Tree TLV 🎀

Here's the cute part: they have exactly the same encoding and format as the IPv4/IPv6 Source Tree TLVs from [RFC6826]. The only twist is that where the Source field used to be, they have an RP field carrying the address of the RP 💖

Transit IPv4 Shared Tree TLV:

      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                        | RP            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                               | Group         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Type: 11
  • Length: 8
  • RP: IPv4 RP address, 4 octets.
  • Group: IPv4 multicast group address, 4 octets.

Transit IPv6 Shared Tree TLV:

      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                        | RP            ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                                               | Group         ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Type: 12
  • Length: 32
  • RP: IPv6 RP address, 16 octets.
  • Group: IPv6 multicast group address, 16 octets.

The procedures for in-band signaling of shared trees with mLDP follow the exact same procedures as in-band signaling for source trees in [RFC6826]. The one difference is that the latter signals (S,G) state using Transit IPv4/IPv6 Source TLVs, while the former signals (*,G) state using Transit IPv4/IPv6 Shared Tree TLVs ✨

3.2. Originating Source Active Auto-discovery Routes (Mechanism 2)

Picture an LSR with some interfaces that can do IP multicast and some that can do MPLS multicast 👑

Whenever such an LSR creates an (S,G) state because it received an mLDP Label Map with the Transit IPv4/IPv6 Source TLV for (S,G), the LSR MUST originate a Source Active auto-discovery route if all of the following are true:

  • S is reachable via one of the IP-multicast-capable interfaces,
  • the LSR determines that G is in the PIM-SM in ASM mode range, and
  • the LSR does not have a (*,G) state with one of the IP-multicast-capable interfaces as an incoming interface (iif) for that state.

The route carries a single MCAST-VPN NLRI, built like this 🧩

  • The RD in this NLRI is set to 0.
  • The Multicast Source field is set to S. The Multicast Source Length field is set appropriately to reflect this address type.
  • The Multicast Group field is set to G. The Multicast Group Length field is set appropriately to reflect this address type.

To keep the Source Active auto-discovery route from spreading past the AS of the advertising LSR, this route SHOULD carry the NO_EXPORT Community ([RFC1997]) 🌈

Using the normal BGP procedures, the Source Active auto-discovery route then gets propagated to all other LSRs within the AS 🦋

Whenever the LSR receiving an mLDP Label Map with the Transit IPv4/IPv6 Source TLV for (S,G) deletes the (S,G) state it previously created, the LSR that deletes the state MUST also withdraw the Source Active auto-discovery route, if such a route was advertised when the state was created. No loose ends, periodt 💀

Also, note this one 🙈: whenever an LSR creates an (S,G) state because it received an mLDP Label Map with the Transit IPv4/IPv6 Source TLV for (S,G) with S reachable via one of the IP-multicast-capable interfaces, AND the LSR already has a (,G) state with the RP reachable via one of the IP-multicast-capable interfaces (from an mLDP Label Map with the Transit IPv4/IPv6 Shared Tree TLV for (,G)), the LSR does not originate a Source Active auto-discovery route. Only one of them needs to show up to the party 🥂

3.3. Receiving Source Active Auto-discovery Routes

Good news: receiving Source Active auto-discovery routes works exactly the same as it does for Mechanism 1 ✨

3.4. Pruning Sources Off the Shared Tree

Okay, this section is the drama arc 🎭. After an LSR gets a new Source Active auto-discovery route for (S,G), it checks four things: (a) it has the (*,G) entry in its TIB, (b) the incoming interface (iif) list for that entry contains one of the IP interfaces, (c) at least one of the MPLS interfaces is in the outgoing interface (oif) list for that entry, and (d) the LSR does not originate an mLDP Label Mapping message for (S,G) with the Transit IPv4/IPv6 Source TLV. If all of those are true, then the LSR MUST transition the (S,G,RPT-bit) downstream state to the Prune state 🙅‍♀️

Conceptually, the PIM state machine on the LSR acts "as if" it received Prune(S,G,rpt) on one of its MPLS interfaces, even though it never actually got one 🧠 Depending on the (S,G,RPT-bit) state on the iif, this may end up with the LSR using PIM procedures to prune S off the Shared (*,G) tree.

Then, the LSR MUST keep the (S,G,RPT-bit) downstream state machine in the Prune state for as long as (a) the outgoing interface (oif) list for (*,G) contains one of the MPLS interfaces, (b) the LSR has at least one Source Active auto-discovery route for (S,G), and (c) the LSR does not originate the mLDP Label Mapping message for (S,G) with the Transit IPv4/IPv6 Source TLV. Once one or more of those conditions stop being valid, the LSR MUST transition the (S,G,RPT-bit) downstream state machine to the NoInfo state 🍓

Last tea ☕: except for the scenario in the first paragraph of this section, the PIM procedures on the LSR are enough on their own to make sure pruning sources off the shared tree behaves correctly 💜

3.5. More on Handling (S,G,RPT-bit) State

The creation and deletion of (S,G,RPT-bit) state on an LSR, when that state comes from PIM messages received on one of its IP multicast interfaces, does not trigger any mLDP and/or BGP actions by the LSR. Quiet, but it's the vibe 🤫✨

4. IANA Considerations 🌷

IANA maintains a registry called "Label Distribution Protocol (LDP) Parameters," with a subregistry called "LDP MP Opaque Value Element basic type." IANA has allocated two new values, as shown here:

      Value | Name                         | Reference
      ------+------------------------------+------------
        11  | Transit IPv4 Shared Tree TLV | [RFC7442]
        12  | Transit IPv6 Shared Tree TLV | [RFC7442]

5. Security Considerations 🚨

Buckle up, this part is serious 😭 All of the security considerations for mLDP ([RFC6388]) apply here, no exceptions.

From the security point of view, using Shared Tree TLVs is no different from using Source TLVs [RFC6826]. Same risks, same care, same energy 🛡️👑

6. References 📚

6.1. Normative References

[RFC1997]  Chandra, R., Traina, P., and T. Li, "BGP Communities
           Attribute", RFC 1997, August 1996,
           <http://www.rfc-editor.org/info/rfc1997>.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997,
           <http://www.rfc-editor.org/info/rfc2119>.

[RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
           "Protocol Independent Multicast - Sparse Mode (PIM-SM):
           Protocol Specification (Revised)", RFC 4601, August 2006,
           <http://www.rfc-editor.org/info/rfc4601>.

[RFC6388]  Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
           Thomas, "Label Distribution Protocol Extensions for Point-
           to-Multipoint and Multipoint-to-Multipoint Label Switched
           Paths", RFC 6388, November 2011,
           <http://www.rfc-editor.org/info/rfc6388>.

[RFC6514]  Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
           Encodings and Procedures for Multicast in MPLS/BGP IP
           VPNs", RFC 6514, February 2012,
           <http://www.rfc-editor.org/info/rfc6514>.

[RFC6826]  Wijnands, IJ., Ed., Eckert, T., Leymann, N., and M.
           Napierala, "Multipoint LDP In-Band Signaling for Point-to-
           Multipoint and Multipoint-to-Multipoint Label Switched
           Paths", RFC 6826, January 2013,
           <http://www.rfc-editor.org/info/rfc6826>.

6.2. Informative References

[RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
           IP", RFC 4607, August 2006,
           <http://www.rfc-editor.org/info/rfc4607>.

[RFC7438]  Wijnands, IJ., Ed., Rosen, E., Gulko, A., Joorde, U., and
           J. Tantsura, "Multipoint LDP (mLDP) In-Band Signaling
           with Wildcards", RFC 7438, January 2015,
           <http://www.rfc-editor.org/info/rfc7438>.

Acknowledgements 🫶

The use of Source Active auto-discovery routes was borrowed from [RFC6514]. Some text in this document was borrowed from [RFC6514], and some of the text was also borrowed from [RFC6826]. Shoutout to the borrowing 🙌

Big thanks to Arkadiy Gulko for his review and comments. We'd also love to thank Xuxiaohu, Gregory Mirsky, Rajiv Asati, and Adrian Farrel for their review and comments 💖

Authors' Addresses 💌

Yakov Rekhter
Juniper Networks, Inc.
EMail: yakov@juniper.net


Rahul Aggarwal
Arktan
EMail: raggarwa_1@yahoo.com


Nicolai Leymann
Deutsche Telekom
Winterfeldtstrasse 21
Berlin  10781
Germany
EMail: N.Leymann@telekom.de


Wim Henderickx
Alcatel-Lucent
EMail: wim.henderickx@alcatel-lucent.com


Quintin Zhao
Huawei
EMail: quintin.zhao@huawei.com


Richard Li
Huawei
EMail: renwei.li@huawei.com
📦 where this page comes from