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/rfc6826.txt | 675 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 675 insertions(+) create mode 100644 doc/rfc/rfc6826.txt (limited to 'doc/rfc/rfc6826.txt') diff --git a/doc/rfc/rfc6826.txt b/doc/rfc/rfc6826.txt new file mode 100644 index 0000000..b37ed41 --- /dev/null +++ b/doc/rfc/rfc6826.txt @@ -0,0 +1,675 @@ + + + + + + +Internet Engineering Task Force (IETF) IJ. Wijnands, Ed. +Request for Comments: 6826 T. Eckert +Category: Standards Track Cisco Systems, Inc. +ISSN: 2070-1721 N. Leymann + Deutsche Telekom + M. Napierala + AT&T Labs + January 2013 + + + Multipoint LDP In-Band Signaling for + Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths + +Abstract + + Consider an IP multicast tree, constructed by Protocol Independent + Multicast (PIM), that needs to pass through an MPLS domain in which + Multipoint LDP (mLDP) point-to-multipoint and/or multipoint-to- + multipoint Labels Switched Paths (LSPs) can be created. The part of + the IP multicast tree that traverses the MPLS domain can be + instantiated as a multipoint LSP. When a PIM Join message is + received at the border of the MPLS domain, information from that + message is encoded into mLDP messages. When the mLDP messages reach + the border of the next IP domain, the encoded information is used to + generate PIM messages that can be sent through the IP domain. The + result is an IP multicast tree consisting of a set of IP multicast + sub-trees that are spliced together with a multipoint LSP. This + document describes procedures regarding how IP multicast trees are + spliced together with multipoint LSPs. + +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/rfc6826. + + + + + + + + +Wijnands, et al. Standards Track [Page 1] + +RFC 6826 In-Band Signaling with mLDP January 2013 + + +Copyright Notice + + Copyright (c) 2013 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. Conventions Used in This Document . . . . . . . . . . . . 3 + 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. In-Band Signaling for MP LSPs . . . . . . . . . . . . . . . . 4 + 2.1. Transiting Unidirectional IP Multicast Shared Trees . . . 6 + 2.2. Transiting IP Multicast Source Trees . . . . . . . . . . . 6 + 2.3. Transiting IP Multicast Bidirectional Trees . . . . . . . 7 + 3. LSP Opaque Encodings . . . . . . . . . . . . . . . . . . . . . 8 + 3.1. Transit IPv4 Source TLV . . . . . . . . . . . . . . . . . 8 + 3.2. Transit IPv6 Source TLV . . . . . . . . . . . . . . . . . 8 + 3.3. Transit IPv4 Bidir TLV . . . . . . . . . . . . . . . . . . 9 + 3.4. Transit IPv6 Bidir TLV . . . . . . . . . . . . . . . . . . 9 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 + 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 + + + + + + + + + + + + + + + + +Wijnands, et al. Standards Track [Page 2] + +RFC 6826 In-Band Signaling with mLDP January 2013 + + +1. Introduction + + The mLDP (Multipoint LDP) [RFC6388] specification describes + mechanisms for creating point-to-multipoint (P2MP) and multipoint-to- + multipoint (MP2MP) LSPs (Label Switched Paths). These LSPs are + typically used for transporting end-user multicast packets. However, + the mLDP specification does not provide any rules for associating + particular end-user multicast packets with any particular LSP. Other + documents, like [RFC6513], describe applications in which out-of-band + signaling protocols, such as PIM and BGP, are used to establish the + mapping between an LSP and the multicast packets that need to be + forwarded over the LSP. + + This document describes an application in which the information + needed to establish the mapping between an LSP and the set of + multicast packets to be forwarded over it is carried in the "opaque + value" field of an mLDP FEC (Forwarding Equivalence Class) element. + When an IP multicast tree (either a source-specific tree or a + bidirectional tree) enters the MPLS network, the (S,G) or (*,G) + information from the IP multicast control-plane state is carried in + the opaque value field of the mLDP FEC message. As the tree leaves + the MPLS network, this information is extracted from the FEC Element + and used to build the IP multicast control plane. PIM messages can + be sent outside the MPLS domain. Note that although the PIM control + messages are sent periodically, the mLDP messages are not. + + Each IP multicast tree is mapped one-to-one to a P2MP or MP2MP LSP in + the MPLS network. A network operator should expect to see as many + LSPs in the MPLS network as there are IP multicast trees. A network + operator should be aware how IP multicast state is created in the + network to ensure that it does not exceed the scalability numbers of + the protocol, either PIM or mLDP. + +1.1. Conventions Used in This Document + + 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]. + +1.2. Terminology + + ASM: PIM Any Source Multicast + + Egress LSR: One of potentially many destinations of an LSP; also + referred to as leaf node in the case of P2MP and MP2MP LSPs. + + + + + + +Wijnands, et al. Standards Track [Page 3] + +RFC 6826 In-Band Signaling with mLDP January 2013 + + + In-band signaling: Using the opaque value of an mLDP FEC Element to + carry the (S,G) or (*,G) identifying a particular IP multicast + tree. + + Ingress LSR: Source of the P2MP LSP; also referred to as a root + node. + + IP multicast tree: An IP multicast distribution tree identified by + an IP multicast Group address and, optionally, by a Source IP + address, also referred to as (S,G) and (*,G). + + LSR: Label Switching Router + + LSP: Labels Switched Path + + mLDP: Multipoint LDP + + MP2MP LSP: An LSP that connects a set of leaf nodes that may each + independently act as ingress or egress. + + MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP. + + P2MP LSP: An LSP that has one Ingress Label Switching Router (LSR) + and one or more Egress LSRs. + + RP: PIM Rendezvous Point + + SSM: PIM Source-Specific Multicast + + Transit LSP: A P2MP or MP2MP LSP whose FEC Element contains the + (S,G) or (*,G) identifying a particular IP multicast distribution + tree. + + Transit LSR: An LSR that has one or more directly connected + downstream LSRs. + +2. In-Band Signaling for MP LSPs + + Consider the following topology: + + |--- IPM ---|--- MPLS --|--- IPM ---| + + S/RP -- (A) - (U) - (C) - (D) -- (B) -- R + + Figure 1 + + + + + + +Wijnands, et al. Standards Track [Page 4] + +RFC 6826 In-Band Signaling with mLDP January 2013 + + + Nodes A and B are IP-multicast-capable routers and connect to a + Source/RP and a Receiver, respectively. Nodes U, C, and D are MPLS + Label Switched Routers (LSRs). + + LSR D is attached to a network that is capable of MPLS multicast and + IP multicast (see figure 1), and D is required to create a IP + multicast tree due to a certain IP multicast event, like a PIM Join, + MSDP Source Announcement (SA) [RFC3618], BGP Source Active auto- + discovery route [SM-MLDP], or Rendezvous Point (RP) discovery. + Suppose that D can determine that the IP multicast tree needs to + travel through the MPLS network until it reaches LSR U. For + instance, when D looks up the route to the Source or RP [RFC4601] of + the IP multicast tree, it may discover that the route is a BGP route + with U as the BGP next hop. Then D may choose to set up a P2MP or an + MP2MP LSP, with U as root, and to make that LSP become part of the IP + multicast distribution tree. Note that other methods are possible to + determine that an IP multicast tree is to be transported across an + MPLS network using P2MP or MP2MP LSPs. However, these methods are + outside the scope of this document. + + In order to establish a multicast tree via a P2MP or MP2MP LSP using + "in-band signaling", LSR D encodes a P2MP or MP2MP FEC Element, with + the IP address of LSR U as the "Root Node Address" and with the + source and the group encoded into the "opaque value" ([RFC6388], + Sections 2.2 and 3.2). Several different opaque value types are + defined in this document. LSR D MUST NOT use a particular opaque + value type unless it knows (through provisioning or through some + other means outside the scope of this document) that LSR U supports + the root node procedures for that opaque value type. + + The particular type of FEC Element and opaque value used depends on + the IP address family being used, and on whether the multicast tree + being established is a source-specific or a bidirectional multicast + tree. + + When an LSR receives a label mapping or withdraw whose FEC Element + contains one of the opaque value types defined in this document, and + that LSR is not the one identified by the "Root Node Address" field + of that FEC Element, the LSR follows the procedures provided in RFC + 6388. + + When an LSR receives a label mapping or withdraw whose FEC Element + contains one of the opaque value types defined in this document, and + that LSR is the one identified by the Root Node Address field of that + FEC Element, then the following procedure is executed. The multicast + source and group are extracted and passed to the multicast code. If + a label mapping is being processed, the multicast code will add the + downstream LDP neighbor to the olist of the corresponding (S,G) or + + + +Wijnands, et al. Standards Track [Page 5] + +RFC 6826 In-Band Signaling with mLDP January 2013 + + + (*,G) state, creating such state if it does not already exist. If a + label withdraw is being processed, the multicast code will remove the + downstream LDP neighbor from the olist of the corresponding (S,G) or + (*,G) state. From this point on, normal PIM processing will occur. + + Note that if the LSR identified by the Root Node Address field does + not recognize the opaque value type, the MP LSP will be established, + but the root node will not send any multicast data packets on it. + + Source or RP addresses that are reachable in a VPN context are + outside the scope of this document. + + Multicast groups that operate in PIM Dense-Mode are outside the scope + of this document. + +2.1. Transiting Unidirectional IP Multicast Shared Trees + + Nothing prevents PIM shared trees, used by PIM-SM in the ASM service + model, from being transported across an MPLS core. However, it is + not possible to prune individual sources from the shared tree without + the use of an additional out-of-band signaling protocol, like PIM or + BGP [SM-MLDP]. For this reason, transiting shared trees across a + transit LSP is outside the scope of this document. + +2.2. Transiting IP Multicast Source Trees + + IP multicast source trees can be created via PIM operating in either + SSM mode [RFC4607] or ASM mode [RFC4601]. When PIM-SM is used in ASM + mode, the usual means of discovering active sources is to join a + sparse-mode shared tree. However, this document does not provide any + method of establishing a sparse-mode shared tree across an MPLS + network. To apply the technique of this document to PIM-SM in ASM + mode, there must be some other means of discovering the active + sources. One possible means is the use of MSDP [RFC3618]. Another + possible means is to use BGP Source Active auto-discovery routes, as + documented in [SM-MLDP]. However, the method of discovering the + active sources is outside the scope of this document; as a result, + this document does not specify everything that is needed to support + the ASM service model using in-band signaling. + + The source and group addresses are encoded into the a transit TLV as + specified in Sections 3.1 and 3.2. + + + + + + + + + +Wijnands, et al. Standards Track [Page 6] + +RFC 6826 In-Band Signaling with mLDP January 2013 + + +2.3. Transiting IP Multicast Bidirectional Trees + + If a bidirectional IP multicast tree [RFC5015] has to be transported + over an MPLS network using in-band signaling, as described in this + document, it MUST be transported using an MP2MP LSPs. A + bidirectional tree does not have a specific source address; the group + address, subnet mask, and RP are relevant for multicast forwarding. + This document does not provide procedures to discover RP-to-group + mappings dynamically across an MPLS network and assumes the RP is + statically defined. Support of dynamic RP mappings in combination + with in-band signaling is outside the scope of this document. + + The RP for the group is used to select the ingress LSR and the root + of the LSP. The group address is encoded according to the rules of + Sections 3.3 or 3.4, depending on the IP version. The subnet mask + associated with the bidirectional group is encoded in the Transit + TLV. There are two types of bidirectional states in IP multicast, + the group specific state and the RP state. The first type is + typically created when a PIM Join has been received and has a subnet + mask of 32 for IPv4 and 128 for IPv6. The RP state is typically + created via the static RP mapping and has a variable subnet mask. + The RP state is used to build a tree to the RP and is used for + sender-only branches. Each state (group specific and RP state) will + result in a separate MP2MP LSP. The merging of the two MP2MP LSPs + will be done by PIM on the root LSR. No special procedures are + necessary for PIM to merge the two LSPs. Each LSP is effectively + treated as a PIM-enabled interface. Please see [RFC5015] for more + details. + + For transporting the packets of a sender-only branch, we create a + MP2MP LSP. Other sender-only branches will receive these packets and + will not forward them because there are no receivers. These packets + will be dropped. If that effect is undesirable, some other means of + transport has to be established to forward packets to the root of the + tree, for example, a multipoint-to-point LSP for example. A + technique to unicast packets to the root of a P2MP or MP2MP LSP is + documented in Section 3.2.2.1 of [MVPN-MSPMSI]. + + + + + + + + + + + + + + +Wijnands, et al. Standards Track [Page 7] + +RFC 6826 In-Band Signaling with mLDP January 2013 + + +3. LSP Opaque Encodings + + This section documents the different transit opaque encodings. + +3.1. Transit IPv4 Source 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 | Source | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | Group | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 3 + + Length: 8 (octet size of Source and Group fields) + + Source: IPv4 multicast source address, 4 octets + + Group: IPv4 multicast group address, 4 octets + +3.2. Transit IPv6 Source 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 | Source ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ | Group ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 4 + + Length: 32 (octet size of Source and Group fields) + + Source: IPv6 multicast source address, 16 octets + + Group: IPv6 multicast group address, 16 octets. + + + + + + + + +Wijnands, et al. Standards Track [Page 8] + +RFC 6826 In-Band Signaling with mLDP January 2013 + + +3.3. Transit IPv4 Bidir 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 | Mask Len | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RP | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Group | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 5 + + Length: 9 (octet size of Mask Len, RP, and Group fields) + + Mask Len: The number of contiguous one bits that are left-justified + and used as a mask, 1 octet. Maximum value allowed is 32. + + RP: Rendezvous Point (RP) IPv4 address used for the encoded Group, 4 + octets. + + Group: IPv4 multicast group address, 4 octets. + +3.4. Transit IPv6 Bidir 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 | Mask Len | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RP ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Group ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 6 + + Length: 33 (octet size of Mask Len, RP and Group fields) + + Mask Len: The number of contiguous one bits that are left-justified + and used as a mask, 1 octet. Maximum value allowed is 128. + + + + + +Wijnands, et al. Standards Track [Page 9] + +RFC 6826 In-Band Signaling with mLDP January 2013 + + + RP: Rendezvous Point (RP) IPv6 address used for encoded group, 16 + octets. + + Group: IPv6 multicast group address, 16 octets. + +4. Security Considerations + + The same security considerations apply as for the base LDP + specification, as described in [RFC5036]. + +5. IANA Considerations + + IANA has allocated the following values from the "LDP MP Opaque Value + Element basic type" registry: are: + + Transit IPv4 Source TLV type - 3 + + Transit IPv6 Source TLV type - 4 + + Transit IPv4 Bidir TLV type - 5 + + Transit IPv6 Bidir TLV type - 6 + +6. References + +6.1. Normative References + + [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., + "LDP Specification", RFC 5036, October 2007. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [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. + +6.2. Informative References + + [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, + "Protocol Independent Multicast - Sparse Mode (PIM-SM): + Protocol Specification (Revised)", RFC 4601, August 2006. + + [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for + IP", RFC 4607, August 2006. + + + + + +Wijnands, et al. Standards Track [Page 10] + +RFC 6826 In-Band Signaling with mLDP January 2013 + + + [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, + "Bidirectional Protocol Independent Multicast (BIDIR- + PIM)", RFC 5015, October 2007. + + [RFC3618] Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source + Discovery Protocol (MSDP)", RFC 3618, October 2003. + + [RFC6513] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in + MPLS/BGP IP VPNs", RFC 6513, February 2012. + + [SM-MLDP] Rekhter, Y., Aggarwal, R., and N. Leymann, "Carrying PIM- + SM in ASM mode Trees over P2MP mLDP LSPs", Work in + Progress, August 2011. + + [MVPN-MSPMSI] + Cai, Y., Rosen, E., Ed., Napierala, M., and A. Boers, + MVPN: Optimized use of PIM via MS-PMSIs", February 2012. + +7. Acknowledgments + + Thanks to Eric Rosen for his valuable comments on this document. + Also thanks to Yakov Rekhter, Adrian Farrel, Uwe Joorde, Loa + Andersson and Arkadiy Gulko for providing comments on this document. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Wijnands, et al. Standards Track [Page 11] + +RFC 6826 In-Band Signaling with mLDP January 2013 + + +Authors' Addresses + + IJsbrand Wijnands (editor) + Cisco Systems, Inc. + De kleetlaan 6a + Diegem 1831 + Belgium + + EMail: ice@cisco.com + + + Toerless Eckert + Cisco Systems, Inc. + 170 Tasman Drive + San Jose CA, 95134 + USA + + EMail: eckert@cisco.com + + + Nicolai Leymann + Deutsche Telekom + Winterfeldtstrasse 21 + Berlin 10781 + Germany + + EMail: n.leymann@telekom.de + + + Maria Napierala + AT&T Labs + 200 Laurel Avenue + Middletown NJ 07748 + USA + + EMail: mnapierala@att.com + + + + + + + + + + + + + + + +Wijnands, et al. Standards Track [Page 12] + -- cgit v1.2.3