From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7442.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc7442.txt (limited to 'doc/rfc/rfc7442.txt') diff --git a/doc/rfc/rfc7442.txt b/doc/rfc/rfc7442.txt new file mode 100644 index 0000000..b1d41ea --- /dev/null +++ b/doc/rfc/rfc7442.txt @@ -0,0 +1,619 @@ + + + + + + +Internet Engineering Task Force (IETF) Y. Rekhter +Request for Comments: 7442 Juniper Networks +Category: Standards Track R. Aggarwal +ISSN: 2070-1721 Arktan + N. Leymann + Deutsche Telekom + W. Henderickx + Alcatel-Lucent + Q. Zhao + R. Li + Huawei + February 2015 + + + Carrying Protocol Independent Multicast - Sparse Mode (PIM-SM) + in Any-Source Multicast (ASM) Mode Trees over Multipoint LDP (mLDP) + +Abstract + + When IP multicast trees created by Protocol Independent Multicast - + Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) mode need to pass + through an MPLS domain, it may be desirable to map such trees to + Point-to-Multipoint Label Switched Paths (P2MP LSPs). This document + describes how to accomplish this in the case where such P2MP LSPs are + established using Label Distribution Protocol (LDP) Extensions for + P2MP and Multipoint-to-Multipoint LSPs: Multipoint LDP (mLDP). + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7442. + + + + + + + + + + + +Rekhter, et al. Standards Track [Page 1] + +RFC 7442 PIM-SM over P2MP mLDP LSPs February 2015 + + +Copyright Notice + + 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) 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 Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without 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 + + + + + + + + + + + + +Rekhter, et al. Standards Track [Page 2] + +RFC 7442 PIM-SM over P2MP mLDP LSPs February 2015 + + +1. Introduction + + [RFC6826] describes how to map Point-to-Multipoint Label Switched + Paths (P2MP LSPs) created by mLDP [RFC6388] to multicast trees + created by Protocol Independent Multicast - Sparse Mode (PIM-SM) in + Source-Specific Multicast (SSM) mode [RFC4607]. This document + describes how to map mLDP P2MP trees to multicast trees created by + PIM-SM in Any-Source Multicast (ASM) mode. It describes two possible + mechanisms for doing this. + + The first mechanism, described in Section 2, is OPTIONAL for + implementations, but the second mechanism, described in Section 3, is + REQUIRED for all implementations claiming conformance to this + specification. + + Note that from a deployment point of view these two mechanisms are + mutually exclusive. That is, on the same network one could deploy + either one of the mechanisms, but not both. + + The reader of this document is expected to be familiar with PIM-SM + [RFC4601] and mLDP [RFC6388]. + + This document relies on the procedures in [RFC6826] to support source + trees. For example, following these procedures a Label Switching + Router (LSR) may initiate an mLDP Label Map with the Transit + IPv4/IPv6 Source TLV for (S,G) when receiving a PIM (S,G) Join. + + This document uses BGP Source Active auto-discovery routes, as + defined in [RFC6514]. For the sake of brevity in the rest of this + document, we'll refer to these routes as just "Source Active + auto-discovery routes". + + Consider a deployment scenario where the service provider has + provisioned the network in such a way that the Rendezvous Point (RP) + for a particular ASM group G is always between the receivers and the + sources. If the network is provisioned in this manner, the ingress + Provider Edge (PE) for (S,G) is always the same as the ingress PE for + the RP, and thus the Source Active auto-discovery (A-D) routes are + never needed. If it is known a priori that the network is + provisioned in this manner, mLDP in-band signaling can be supported + using a different set of procedures, as specified in [RFC7438]. A + service provider will provision the PE routers to use either the + procedures in [RFC7438] or those described in this document. + + + + + + + + +Rekhter, et al. Standards Track [Page 3] + +RFC 7442 PIM-SM over P2MP mLDP LSPs February 2015 + + + Like [RFC6826], each IP multicast tree is mapped one-to-one to a P2MP + LSP in the MPLS network. This type of service works well if the + number of LSPs that are created is under the control of the MPLS + network operator, or if the number of LSPs for a particular service + is known to be limited. + + It is to be noted that the existing BGP Multicast VPN (MVPN) + procedures [RFC6514] can be used to map Internet IP multicast trees + to P2MP LSPs. These procedures would accomplish this for IP + multicast trees created by PIM-SM in SSM mode, as well as for IP + multicast trees created by PIM-SM in ASM mode. Furthermore, these + procedures would also support the ability to aggregate multiple IP + multicast trees to one P2MP LSP in the MPLS network. The details of + this particular approach are out of scope for this document. + + This document assumes that a given LSR may have some interfaces that + are IP multicast capable, while other interfaces would be 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]. + +2. Mechanism 1 - Non-transitive Mapping of IP Multicast Shared Trees + + This mechanism does not transit IP multicast shared trees over the + MPLS network. Therefore, when an LSR creates (*,G) state (as a + result of receiving PIM messages on one of its IP multicast + interfaces), the LSR does not propagate this state in mLDP. + +2.1. Originating Source Active Auto-discovery Routes (Mechanism 1) + + Whenever (as a result of receiving either PIM Register or Multicast + Source Discovery Protocol (MSDP) messages) an RP discovers a new + multicast source, the RP SHOULD originate a Source Active + auto-discovery route. The route carries a single MCAST-VPN Network + Layer Reachability Information (NLRI) [RFC6514], constructed as + follows: + + + 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. + + + + + +Rekhter, et al. Standards Track [Page 4] + +RFC 7442 PIM-SM over P2MP mLDP LSPs February 2015 + + + + 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 constrain distribution of the Source Active auto-discovery route + to the Autonomous System (AS) of the advertising RP, this route + SHOULD carry the NO_EXPORT Community ([RFC1997]). + + Using the normal BGP procedures, the Source Active auto-discovery + route is propagated to all other LSRs within the AS. + + Whenever the RP discovers that the source is no longer active, the RP + MUST withdraw the Source Active auto-discovery route if such a route + was previously advertised by the RP. + +2.2. Receiving Source Active Auto-discovery Routes by LSR + + Consider an LSR that has some of its interfaces capable of IP + multicast and some capable of MPLS multicast. + + When, as a result of receiving PIM messages on one of its IP + multicast interfaces, an LSR creates in its Tree Information Base + (TIB) a new (*,G) entry with a non-empty outgoing interface list that + contains one or more IP multicast interfaces, the LSR MUST check to + see if it has any Source Active auto-discovery routes for that G. If + there is such a route, S of that route is reachable via an MPLS + interface, and the LSR does not have (S,G) state in its TIB for (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 receives a new Source Active auto-discovery route, the + LSR MUST check to see if its TIB contains a (*,G) entry with the same + G as that carried in the Source Active auto-discovery route. If such + an entry is found, S is reachable via an MPLS interface, and the LSR + does not have (S,G) state in its TIB for (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 + + The creation and deletion of (S,G,RPT-bit) PIM state ([RFC4601]) on + an LSR that resulted from receiving PIM messages on one of its IP + multicast interfaces do not result in any mLDP and/or BGP actions by + the LSR. + + + + + + +Rekhter, et al. Standards Track [Page 5] + +RFC 7442 PIM-SM over P2MP mLDP LSPs February 2015 + + +3. Mechanism 2 - Transitive Mapping of IP Multicast Shared Trees + + This mechanism enables transit of IP multicast shared trees over the + MPLS network. Therefore, when an LSR creates (*,G) state as a result + of receiving PIM messages on one of its IP multicast interfaces, the + LSR propagates this state in mLDP, as described below. + + Note that in the deployment scenarios where, for a given G, none of + the PEs originate an (S,G) mLDP Label Map with the Transit IPv4/IPv6 + Source TLV, no Source Active auto-discovery routes will be used. One + other scenario where no Source Active auto-discovery routes will be + 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 that is used is the in-band signaling + for IP Multicast Shared Trees, as described in the next section. + +3.1. In-Band Signaling for IP Multicast Shared Trees + + To provide support for in-band mLDP signaling of IP multicast shared + trees, this document defines two new mLDP TLVs: the Transit IPv4 + Shared Tree TLV and the Transit IPv6 Shared Tree TLV. + + These two TLVs have exactly the same encoding/format as the IPv4/IPv6 + Source Tree TLVs defined in [RFC6826], except that instead of the + Source field they have an RP field that carries the address of the + RP, as follows: + + 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. + + + + + +Rekhter, et al. Standards Track [Page 6] + +RFC 7442 PIM-SM over P2MP mLDP LSPs February 2015 + + + 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. + + Procedures for in-band signaling for IP multicast shared trees with + mLDP follow the same procedures as those for in-band signaling for + IP multicast source trees, as specified in [RFC6826], except that + while the latter signals (S,G) state using Transit IPv4/IPv6 Source + TLVs, the former signals (*,G) state using Transit IPv4/IPv6 Shared + Tree TLVs. + +3.2. Originating Source Active Auto-discovery Routes (Mechanism 2) + + Consider an LSR that has some of its interfaces capable of IP + multicast and some capable of MPLS multicast. + + Whenever such an LSR creates an (S,G) state as a result of receiving + 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. + + + + + + + + +Rekhter, et al. Standards Track [Page 7] + +RFC 7442 PIM-SM over P2MP mLDP LSPs February 2015 + + + The route carries a single MCAST-VPN NLRI, constructed as follows: + + + 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 constrain distribution of the Source Active auto-discovery route + to 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 is 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 that was + 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. + + Note that whenever an LSR creates an (S,G) state as a result of + receiving 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 as a result + of receiving 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. + +3.3. Receiving Source Active Auto-discovery Routes + + Procedures for receiving Source Active auto-discovery routes are the + same as those for Mechanism 1. + +3.4. Pruning Sources Off the Shared Tree + + If, after receiving a new Source Active auto-discovery route for + (S,G), the LSR determines that (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, then the LSR MUST transition the + (S,G,RPT-bit) downstream state to the Prune state. (Conceptually, + the PIM state machine on the LSR will act "as if" it had received + + + +Rekhter, et al. Standards Track [Page 8] + +RFC 7442 PIM-SM over P2MP mLDP LSPs February 2015 + + + Prune(S,G,rpt) on one of its MPLS interfaces, without actually having + received one.) Depending on the (S,G,RPT-bit) state on the iif, this + may result in the LSR using PIM procedures to prune S off the Shared + (*,G) tree. + + 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 these conditions + become no longer valid, the LSR MUST transition the (S,G,RPT-bit) + downstream state machine to the NoInfo state. + + Note that except for the scenario described in the first paragraph of + this section, it is sufficient to rely solely on the PIM procedures + on the LSR to ensure the correct behavior when pruning sources off + the shared tree. + +3.5. More on Handling (S,G,RPT-bit) State + + The creation and deletion of (S,G,RPT-bit) state on an LSR that + resulted from receiving PIM messages on one of its IP multicast + interfaces do not result in any mLDP and/or BGP actions by the LSR. + +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 follows: + + Value | Name | Reference + ------+------------------------------+------------ + 11 | Transit IPv4 Shared Tree TLV | [RFC7442] + 12 | Transit IPv6 Shared Tree TLV | [RFC7442] + +5. Security Considerations + + All of the security considerations for mLDP ([RFC6388]) apply here. + + From the security considerations point of view, the use of Shared + Tree TLVs is no different than the use of Source TLVs [RFC6826]. + + + + + + + + + +Rekhter, et al. Standards Track [Page 9] + +RFC 7442 PIM-SM over P2MP mLDP LSPs February 2015 + + +6. References + +6.1. Normative References + + [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities + Attribute", RFC 1997, August 1996, + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997, + . + + [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, + "Protocol Independent Multicast - Sparse Mode (PIM-SM): + Protocol Specification (Revised)", RFC 4601, August 2006, + . + + [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, + . + + [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, + . + + [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, + . + +6.2. Informative References + + [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for + IP", RFC 4607, August 2006, . + + [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, + . + + + + + + + +Rekhter, et al. Standards Track [Page 10] + +RFC 7442 PIM-SM over P2MP mLDP LSPs February 2015 + + +Acknowledgements + + The use of Source Active auto-discovery routes was borrowed from + [RFC6514]. Some text in this document was borrowed from [RFC6514]. + + Some of the text in this document was borrowed from [RFC6826]. + + We would like to acknowledge Arkadiy Gulko for his review and + comments. + + We would also like 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 + + + + + +Rekhter, et al. Standards Track [Page 11] + -- cgit v1.2.3