idnits 2.17.1 draft-ietf-mpls-mldp-in-band-wildcard-encoding-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 26, 2014) is 3411 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-03) exists of draft-ietf-bess-mvpn-global-table-mcast-00 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group IJ. Wijnands, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Updates: 6826,7246 (if approved) E. Rosen 5 Intended status: Standards Track Juniper Networks, Inc. 6 Expires: May 30, 2015 A. Gulko 7 Thomson Reuters 8 U. Joorde 9 Deutsche Telekom 10 J. Tantsura 11 Ericsson 12 November 26, 2014 14 mLDP In-Band Signaling with Wildcards 15 draft-ietf-mpls-mldp-in-band-wildcard-encoding-03 17 Abstract 19 There are scenarios in which an IP multicast tree traverses an MPLS 20 domain. In these scenarios, it can be desirable to convert the IP 21 multicast tree "seamlessly" to an MPLS multipoint label switched path 22 (MP-LSP) when it enters the MPLS domain, and then to convert it back 23 to an IP multicast tree when it exits the MPLS domain. Previous 24 documents specify procedures that allow certain kinds of IP multicast 25 trees (either "Source-Specific Multicast" trees or "Bidirectional 26 Multicast" trees) to be attached to an MPLS Multipoint Label Switched 27 Path (MP-LSP). However, the previous documents do not specify 28 procedures for attaching IP "Any Source Multicast" trees to MP-LSPs, 29 nor do they specify procedures for aggregating multiple IP multicast 30 trees onto a single MP-LSP. This document specifies the procedures 31 to support these functions. It does so by defining "wildcard" 32 encodings that make it possible to specify, when setting up an MP- 33 LSP, that a set of IP multicast trees, or a shared IP multicast tree, 34 should be attached to that MP-LSP. Support for non-bidirectional IP 35 "Any Source Multicast" trees is subject to certain applicability 36 restrictions that are discussed in this document. This document 37 updates RFCs 6826 and 7246. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on May 30, 2015. 56 Copyright Notice 58 Copyright (c) 2014 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5 75 3. Wildcards in mLDP Opaque Value TLVs . . . . . . . . . . . . . 6 76 3.1. Encoding the Wildcards . . . . . . . . . . . . . . . . . 7 77 3.2. Wildcard Semantics . . . . . . . . . . . . . . . . . . . 7 78 3.3. Backwards Compatibility . . . . . . . . . . . . . . . . . 8 79 3.4. Applicability Restrictions with regard to ASM . . . . . . 8 80 4. Some Wildcard Use Cases . . . . . . . . . . . . . . . . . . . 9 81 4.1. PIM shared tree forwarding . . . . . . . . . . . . . . . 9 82 4.2. IGMP/MLD Proxying . . . . . . . . . . . . . . . . . . . . 10 83 4.3. Selective Source mapping . . . . . . . . . . . . . . . . 10 84 5. Procedures for Wildcard Source Usage . . . . . . . . . . . . 11 85 6. Procedures for Wildcard Group Usage . . . . . . . . . . . . . 12 86 7. Determining the MP-LSP Root (Ingress LSR) . . . . . . . . . . 12 87 8. Anycast RP . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 89 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 90 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 91 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 92 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 93 12.2. Informative References . . . . . . . . . . . . . . . . . 14 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 96 1. Introduction 98 [RFC6826] and [RFC7246] specify procedures for mLDP ("Multicast 99 Extensions to the Label Distribution Protocol") that allow an IP 100 multicast tree (either a "Source-Specific Multicast" tree or a 101 "Bidirectional multicast" tree) to be attached "seamlessly" to an 102 MPLS Multipoint Label Switched Path (MP-LSP). This can be useful, 103 for example, when there is multicast data that originates in a domain 104 that supports IP multicast, then has to be forwarded across a domain 105 that supports MPLS multicast, then has to forwarded across another 106 domain that supports IP multicast. By attaching an IP multicast tree 107 to an MP-LSP, data that is traveling along the IP multicast tree can 108 be moved seamlessly to the MP-LSP when it enters the MPLS multicast 109 domain. The data then travels along the MP-LSP through the MPLS 110 domain. When the data reaches the boundary of the MPLS domain, it 111 can be moved seamlessly to an IP multicast tree. This ability to 112 attach IP multicast trees to MPLS MP-LSPs can be useful in either VPN 113 context or global context. 115 In mLDP, every MP-LSP is identified by the combination of a "root 116 node" (or "Ingress LSR") and an "Opaque Value" that, in the context 117 of the root node, uniquely identifies the MP-LSP. These are encoded 118 into an mLDP "FEC Element". To set up an MP-LSP, the Egress LSRs 119 originate mLDP control messages containing the FEC element. A given 120 FEC Element value identifies a single MP-LSP, and is passed upstream 121 from the Egress LSRs, through the intermediate LSRs, to the Ingress 122 LSR. 124 In IP multicast, a multicast tree is identified by the combination of 125 an IP source address ("S") and an IP group address ("G"), usually 126 written as "(S,G)". A tree carrying traffic of multiple sources is 127 identified by its group address, and the identifier is written as 128 "(*,G)". 130 When an MP-LSP is being set up, the procedures of [RFC6826] and 131 [RFC7246], known as "mLDP In-Band Signaling", allow the Egress LSRs 132 of the MP-LSP to encode the identifier of an IP multicast tree in the 133 "Opaque Value" field of the mLDP FEC Element that identifies the MP- 134 LSP. Only the Egress and Ingress LSRs are aware that the mLDP FEC 135 Elements contain encodings of the IP multicast tree identifier; 136 intermediate nodes along the MP-LSP do not take any account of the 137 internal structure of the FEC Element's Opaque Value, and the 138 internal structure of the Opaque Value does not affect the operation 139 of mLDP. By using mLDP In-Band Signaling, the Egress LSRs of an MP- 140 LSP inform the Ingress LSR that they expect traffic of the identified 141 IP multicast tree (and only that traffic) to be carried on the MP- 142 LSP. That is, mLDP In-Band Signaling not only sets up the MP-LSP, it 143 also binds a given IP multicast tree to the MP-LSP. 145 If multicast is being done in a VPN context [RFC7246], the mLDP FEC 146 elements also contain a "Route Distinguisher" (RD) (see [RFC7246]), 147 as the IP multicast trees are identified not merely by "(S,G)" but by 148 "(RD,S,G)". The procedures of this document are also applicable in 149 this case. Of course, when an Ingress LSR processes an In-Band 150 Signaling Opaque Value that contains an RD, it does so in the context 151 of the VPN associated with that RD. 153 If mLDP In-Band Signaling is not used, some other protocol must be 154 used to bind an IP multicast tree to the MP-LSP, and this requires 155 additional communication mechanisms between the Ingress LSR and the 156 Egress LSRs of the MP-LSP. The purpose of mLDP In-Band Signaling is 157 to eliminate the need for these other protocols. 159 When following the procedures of [RFC6826] and [RFC7246] for non- 160 bidirectional trees, the Opaque Value has an IP Source Address (S) 161 and an IP Group Address (G) encoded into it, thus enabling it to 162 identify a particular IP multicast (S,G) tree. Only a single IP 163 source-specific multicast tree (i.e., a single "(S,G)") can be 164 identified in a given FEC element. As a result, a given MP-LSP can 165 carry data from only a single IP source-specific multicast tree 166 (i.e., a single "(S,G) tree"). However, there are scenarios in which 167 it would be desirable to aggregate a number of (S,G) trees on a 168 single MP-LSP. Aggregation allows a given number of IP multicast 169 trees to use a smaller number of MP-LSPs, thus saving state in the 170 network. 172 In addition, [RFC6826] and [RFC7246] do not support the attachment of 173 an "Any Source Multicast" (ASM) shared tree to an MP-LSP, except in 174 the case where the ASM shared tree is a "bidirectional" tree (i.e., a 175 tree set up by BIDIR-PIM [RFC5015]). However, there are scenarios in 176 which it would be desirable to attach a non-bidirectional ASM shared 177 tree to an MP-LSP. 179 This document specifies a way to encode an mLDP "Opaque Value" in 180 which either the "S" or the "G" or both are replaced by a "wildcard" 181 (written as "*"). Procedures are described for using the wildcard 182 encoding to map non-bidirectional ASM shared trees to MP-LSPs, and 183 for mapping multiple (S,G) trees (with a common value of S or a 184 common value of G) to a single MP-LSP. 186 Some example scenarios where wildcard encoding is useful are: 188 o PIM Shared tree forwarding with "threshold infinity". 190 o IGMP/MLD proxying. 192 o Selective Source mapping. 194 These scenarios are discussed in Section 4. Note that this list of 195 scenarios is not meant to be exhaustive. 197 This draft specifies only the mLDP procedures that are specific to 198 the use of wildcards. mLDP In-Band Signaling procedures that are not 199 specific to the use of wildcards can be found in [RFC6826] and 200 [RFC7246]. Unless otherwise specified in this document, those 201 procedures still apply when wildcards are used. 203 2. Terminology and Definitions 205 Readers of this document are assumed to be familiar with the 206 terminology and concepts of the documents listed as Normative 207 References. For convenience, some of the more frequently used terms 208 appear below. 210 IGMP: 211 Internet Group Management Protocol. 213 In-band signaling: 214 Using the opaque value of a mLDP FEC element to carry the (S,G) or 215 (*,G) identifying a particular IP multicast tree. This draft also 216 allows (S,*) to be encoded in the opaque value; see Section 6. 218 Ingress LSR: 219 Root node of a MP-LSP. When mLDP In-Band Signaling is used, the 220 Ingress LSR receives mLDP messages about a particular MP-LSP from 221 "downstream", and emits IP multicast control messages "upstream". 222 The set of IP multicast control messages that are emitted upstream 223 depends upon the contents of the LDP Opaque Value TLVs. The 224 Ingress LSR also receives IP multicast data messages from 225 "upstream" and sends them "downstream" as MPLS packets on a MP- 226 LSP. 228 IP multicast tree: 229 An IP multicast distribution tree identified by a IP multicast 230 group address and optionally a Source IP address, also referred to 231 as (S,G) and (*,G). 233 MLD: 234 Multicast Listener Discovery. 236 mLDP: 237 Multipoint LDP. 239 MP-LSP: 240 A P2MP or MP2MP LSP. 242 PIM: 243 Protocol Independent Multicast. 245 PIM-ASM: 246 PIM Any Source Multicast. 248 PIM-SM: 249 PIM Sparse Mode 251 PIM-SSM: 252 PIM Source Specific Multicast. 254 RP: 255 The PIM Rendezvous Point. 257 Egress LSR: 258 The Egress LSRs of an MP-LSP are LSPs that receive MPLS multicast 259 data packets from "upstream" on that MP-LSP, and that forward that 260 data "downstream" as IP multicast data packets. The Egress LSRs 261 also receive IP multicast control messages from "downstream", and 262 send mLDP control messages "upstream". When In-Band Signaling is 263 used, the Egress LSRs construct Opaque Value TLVs that contain IP 264 source and/or group addresses, based on the contents of the IP 265 multicast control messages received from downstream. 267 Threshold Infinity: 268 A PIM-SM procedure where no source specific multicast (S,G) trees 269 are created for multicast packets that are forwarded down the 270 shared tree (*,G). 272 TLV: 273 A protocol element consisting of a type field, followed by a 274 length field, followed by a value field. Note that the value 275 field of a TLV may be sub-divided into a number of sub-fields. 277 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 278 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 279 "OPTIONAL" in this document are to be interpreted as described in RFC 280 2119 [RFC2119]. 282 3. Wildcards in mLDP Opaque Value TLVs 284 [RFC6826] and [RFC7246] define the following Opaque Value TLVs: 285 Transit IPv4 Source TLV, Transit IPv6 Source TLV, Transit VPNv4 286 Source TLV, and Transit VPNv6 Source TLV. The value field of each 287 such TLV is divided into a number of sub-fields, one of which 288 contains an IP source address, and one of which contains an IP group 289 address. Per those documents, these fields must contain valid IP 290 addresses. 292 This document extends the definition of those TLVs by allowing either 293 the IP Source Address field or the IP Group Address field (or both) 294 to specify a "wildcard" rather than a valid IP address. 296 3.1. Encoding the Wildcards 298 A value of all zeroes in the IP Source Address sub-field is used to 299 represent a wildcard source address. A value of all zeroes in the IP 300 Group Address sub-field is used to represent the wildcard group 301 address. Note that the lengths of these sub-fields are as specified 302 in the previous documents. 304 3.2. Wildcard Semantics 306 If the IP Source Address sub-field contains the wildcard, and the IP 307 Group Address sub-field contains an IP multicast group address that 308 is NOT in the SSM address range (see Section 4.8 of [RFC4601]), the 309 TLV identifies a PIM-SM shared tree. Please see Section 3.4 for the 310 applicability restrictions that apply to this case. 312 If the IP Source Address sub-field contains the wildcard, and the IP 313 Group Address sub-field contains an IP multicast group address that 314 is in the SSM address range, the TLV identifies the collection of PIM 315 trees with the given group address. 317 If the IP Source Address sub-field contains a non-zero IP address, 318 and the IP Group Address sub-field contains the wildcard, the TLV 319 identifies the collection of PIM-SSM trees that have the source 320 address as their root. 322 Procedures for the use of the wildcards are discussed in Sections 4, 323 5 and 6. Please note that, as always, the structure of an Opaque 324 Value TLV does not affect the operation of mLDP. The structure is 325 meaningful only to the IP multicast modules at the ingress and egress 326 LSRs. 328 Procedures for the use of a wildcard group in the following TLVs 329 (defined in [RFC6826] or [RFC7246]) are outside the scope of the 330 current document: Transit IPv4 Bidir TLV, Transit IPv6 Bidir TLV, 331 Transit VPNv4 Bidir TLV, Transit VPNv6 Bidir TLV. 333 Procedures for the use of both a wildcard source and a wildcard group 334 in the same TLV are outside the scope of the current document. 336 Note that the Bidir TLVs do not have a "Source Address" sub-field, 337 and hence the notion of a wildcard source is not applicable to them. 339 3.3. Backwards Compatibility 341 The procedures of this document do not change the behavior described 342 in [RFC6826] and [RFC7246]. 344 A correctly operating Egress LSR that supports [RFC6826] and/or 345 [RFC7246], but that does not support this document, will never 346 generate mLDP FEC Element Opaque values that contain source or group 347 wildcards. 349 Neither [RFC6826] nor [RFC7246] specifies the behavior of an Ingress 350 LSR that receives mLDP FEC Element Opaque values that contain zeroes 351 in the Source Address or Group Address sub-fields. However, if an 352 Ingress LSR supports [RFC6826] and/or [RFC7246], but does not support 353 this document, it has no choice but to treat any such received FEC 354 elements as invalid; the procedures specified in [RFC6826] and 355 [RFC7246] do not work when the Opaque values contain zeroes in the 356 Source Address or Group Address sub-fields. 358 The procedures of this document thus presuppose that if an Egress LSR 359 uses wildcard encodings when setting up an MP-LSP, then the Ingress 360 LSR (i.e., the root of the multipoint LSP) supports the procedures of 361 this document. An Egress LSR MUST NOT use wildcard encodings when 362 setting up a particular multipoint LSP unless it is known a priori 363 that the Ingress LSR supports the procedures of this document. How 364 this is known is outside the scope of this document. 366 3.4. Applicability Restrictions with regard to ASM 368 In general, support for non-bidirectional PIM-ASM trees requires (a) 369 a procedure for determining the set of sources for a given ASM tree 370 ("source discovery"), and (b) a procedure for pruning a particular 371 source off a shared tree ("source pruning"). No such procedures are 372 specified in this document. Therefore the combination of a wildcard 373 source with an ASM group address MUST NOT be used unless it is known 374 a priori that neither source discovery nor source pruning are needed. 375 How this is known is outside the scope of this document. Section 4 376 describes some use cases in which source discovery and source pruning 377 are not needed. 379 There are of course use cases where source discovery and/or source 380 pruning is needed. These can be handled with procedures such as 381 those specified in [RFC6513], [RFC6514], and [GTM]. Use of mLDP In- 382 Band Signaling is NOT RECOMMENDED for those cases. 384 4. Some Wildcard Use Cases 386 This section discusses a number of wildcard use cases. The set of 387 use cases here is not meant to be exhaustive. In each of these use 388 cases, the Egress LSRs construct mLDP Opaque Value TLVs that contain 389 wildcards in the IP Source Address or IP Group Address sub-fields. 391 4.1. PIM shared tree forwarding 393 PIM [RFC4601] has the concept of a "shared tree", identified as 394 (*,G). This concept is only applicable when G is an IP Multicast 395 Group address that is not in the SSM address range (i.e., is an ASM 396 group address). Every ASM group is associated with a Rendezvous 397 Point (RP), and the (*,G) tree is built towards the RP (i.e., its 398 root is the RP). The RP for group G is responsible for forwarding 399 packets down the (*,G) tree. The packets forwarded down the (*,G) 400 tree may be from any multicast source, as long as they have an IP 401 destination address of G. 403 The RP learns about all the multicast sources for a given group, and 404 then joins a source-specific tree for each such source. I.e., when 405 the RP for G learns that S has multicast data to send to G, the RP 406 joins the (S,G) tree. When the RP receives multicast data from S 407 that is destined to G, the RP forwards the data down the (*,G) tree. 408 There are several different ways that the RP may learn about the 409 sources for a given group. The RP may learn of sources via PIM 410 Register messages [RFC4601], via MSDP [RFC3618] or by observing 411 packets from a source that is directly connected to the RP. 413 In PIM, a PIM router that has receivers for a particular ASM 414 multicast group G (known as a "last hop" router for G) will first 415 join the (*,G) tree. As it receives multicast traffic on the (*,G) 416 tree, it learns (by examining the IP headers of the multicast data 417 packets) the sources that are transmitting to G. Typically, when a 418 last hop router for group G learns that source S is transmitting to 419 G, the last hop router joins the (S,G) tree, and "prunes" S off the 420 (*,G) tree. This allows each last hop router to receive the 421 multicast data along the shortest path from the source to the last 422 hop router. (Full details of this behavior can be found in 423 [RFC4601].) 425 In some cases, however, a last hop router for group G may decide not 426 to join the source trees, but rather to keep receiving all the 427 traffic for G from the (*,G) tree. In this case, we say that the 428 last hop router has "threshold infinity" for group G. This is 429 optional behaviour documented in [RFC4601]. "Threshold infinity" is 430 often used in deployments where the RP is between the multicast 431 sources and the multicast receivers for group G, i.e., in deployments 432 where it is known that the shortest path from any source to any 433 receiver of the group goes through the RP. In these deployments, 434 there is no advantage for a last hop router to join a source tree, 435 since the data is already traveling along the shortest path. The 436 only effect of executing the complicated procedures for joining a 437 source tree and pruning the source off the shared tree would be to 438 increase the amount of multicast routing state that has to be 439 maintained in the network. 441 To efficiently use mLDP In-Band Signaling in this scenario, it is 442 necessary for the Egress LSRs to construct an Opaque Value TLV that 443 identifies a (*,G) tree. This is done by using the wildcard in the 444 IP Source Address sub-field, and setting the IP Group Address sub- 445 field to G. 447 Note that these mLDP In-Band Signaling procedures do not support PIM- 448 ASM in scenarios where "threshold infinity" is not used. 450 4.2. IGMP/MLD Proxying 452 There are scenarios where the multicast senders and receivers are 453 directly connected to an MPLS routing domain, and where it is desired 454 to use mLDP rather than PIM to set up "trees" through that domain. 456 In these scenarios we can apply "IGMP/MLD proxying" and eliminate the 457 use of PIM. The senders and receivers consider the MPLS domain to be 458 single hop between each other. [RFC4605] documents procedures where 459 a multicast routing protocol is not necessary to build a 'simple 460 tree'. Within the MPLS domain, mLDP will be used to build a MP-LSP, 461 but this is hidden from the senders and receivers. The procedures 462 defined in [RFC4605] are applicable, since the senders and receivers 463 are considered to be one hop away from each other. 465 For mLDP to build the necessary MP-LSP, it needs to know the root of 466 the tree. Following the procedures as defined in [RFC4605] we depend 467 on manual configuration of the mLDP root for the ASM multicast group. 468 Since the MP-LSP for a given ASM multicast group will carry traffic 469 from all the sources for that group, the Opaque Value TLV used to 470 construct the MP-LSP will contain a wildcard in the IP Source Address 471 sub-field. 473 4.3. Selective Source mapping 475 In many IPTV deployments, the content servers are gathered into a 476 small number of sites. Popular channels are often statically 477 configured, and forwarded over a core MPLS network to the Egress 478 routers. Since these channels are statically defined, they MAY also 479 be forwarded over a multipoint LSP with wildcard encoding. The sort 480 of wildcard encoding that needs to be used (Source and/or Group) 481 depends on the Source/Group allocation policy of the IPTV provider. 482 Other options are to use MSDP [RFC3618] or BGP "Auto-Discovery" 483 procedures [RFC6513] for source discovery by the Ingress LSR. Based 484 on the received wildcard, the Ingress LSR can select from the set of 485 IP multicast streams for which it has state. 487 5. Procedures for Wildcard Source Usage 489 The decision to use mLDP In-Band Signaling is made by the IP 490 multicast component of an Egress LSR, based on provisioned policy. 491 The decision to use (or not to use) a wildcard in the IP Source 492 Address sub-field of an mLDP Opaque Value TLV is also made by the IP 493 multicast component, again based on provisioned policy. Following 494 are some example policies that may be useful: 496 1. Suppose that PIM is enabled, an Egress LSR needs to join a non- 497 bidirectional ASM group G, and the RP for G is reachable via a 498 BGP route. The Egress LSR may choose the BGP Next Hop of the 499 route to the RP to be the Ingress LSR (root node) of the MP-LSP 500 corresponding to the (*,G) tree. (See also Section 7.) The 501 Egress LSR may identify the (*,G) tree by using an mLDP Opaque 502 Value TLV whose IP Source Address sub-field contains a wildcard, 503 and whose IP Group Address sub-field contains G. 505 2. Suppose that PIM is not enabled for group G, and an IGMP/MLD 506 group membership report for G has been received by an Egress LSR. 507 The Egress LSR may determine the "proxy device" for G (see 508 Section 4.2). It can then set up an MP-LSP for which the proxy 509 device is the Ingress LSR. The Egress LSR needs to signal the 510 Ingress LSR that the MP-LSP is to carry traffic belonging to 511 group G; it does this by using an Opaque Value TLV whose IP 512 Source Address sub-field contains a wildcard, and whose IP Group 513 Address sub-field contains G. 515 As the policies needed in any one deployment may be very different 516 than the policies needed in another, this document does not specify 517 any particular set of policies as being mandatory to implement. 519 When the Ingress LSR receives an mLDP Opaque Value TLV that has been 520 defined for In-Band Signaling, the information from the sub-fields of 521 that TLV is passed to the IP multicast component of the Ingress LSR. 522 If the IP Source Address sub-field contains a wildcard, the IP 523 multicast component must determine how to process it. The processing 524 MUST follow the rules below: 526 1. If PIM is enabled and the group identified in the Opaque Value 527 TLV is a non-bidirectional ASM group, the Ingress LSR acts as if 528 it had received a (*,G) IGMP/MLD report from a downstream node, 529 and the procedures defined in [RFC4601] are followed. 531 2. If PIM is enabled and the identified group is a PIM-SSM group, 532 all multicast sources known for the group on the Ingress LSR are 533 to be forwarded down the MP-LSP. In this scenario, it is assumed 534 that the Ingress LSR is already receiving all the necessary 535 traffic. How the Ingress LSR receives this traffic is outside 536 the scope of this document. 538 3. If PIM is not enabled for the identified group, the Ingress LSR 539 acts as if it had received a (*,G) IGMP/MLD report from a 540 downstream node, and the procedures as defined in [RFC4605] are 541 followed. The ingress LSR should forward the (*,G) packets to 542 the egress LSR through the MP-LSP identified by the Opaque Value 543 TLV. (See also Section 4.2.) 545 6. Procedures for Wildcard Group Usage 547 The decision to use mLDP In-Band Signaling is made by the IP 548 multicast component of an Egress LSR, based on provisioned policy. 549 The decision to use (or not to use) a wildcard in the IP Group 550 Address sub-field of an mLDP Opaque Value TLV is also made by the IP 551 multicast component of the Egress LSR, again based on provisioned 552 policy. As the policies needed in any one deployment may be very 553 different than the policies needed in another, this document does not 554 specify any particular set of policies as being mandatory to 555 implement. 557 When the Ingress LSR (i.e., the root node of the MP-LSP) receives an 558 mLDP Opaque Value TLV that has been defined for In-Band Signaling, 559 the information from the sub-fields of that TLV is passed to the IP 560 multicast component of the Ingress LSR. If the IP Group Address sub- 561 field contains a wildcard, the Ingress LSR examines its IP multicast 562 routing table, to find all the IP multicast streams whose IP source 563 address is the address specified in the IP Source Address sub-field 564 of the TLV. All these streams SHOULD be forwarded down the MP-LSP 565 identified by the Opaque Value TLV. Note that some of these streams 566 may have SSM group addresses, while some may have ASM group 567 addresses. 569 7. Determining the MP-LSP Root (Ingress LSR) 571 Documents [RFC6826] and [RFC7246] describe procedures by which an 572 Egress LSR may determine the MP-LSP root node address corresponding 573 to a given IP multicast stream, based upon the IP address of the 574 source of the IP multicast stream. When a wildcard source encoding 575 is used, PIM is enabled, and the group is a non-bidirectional ASM 576 group, a similar procedure is applied. The only difference from the 577 above mentioned procedures is that the Proxy device or RP address is 578 used instead of the Source to discover the mLDP root node address. 580 Other procedures for determining the root node are also allowed, as 581 determined by policy. 583 8. Anycast RP 585 In the scenarios where mLDP In-Band Signaling is used, it is unlikely 586 that the RP-to-Group mappings are being dynamically distributed over 587 the MPLS core. It is more likely that the RP address is statically 588 configured at each multicast site. In these scenarios, it is 589 advisable to configure an Anycast RP Address at each site, in order 590 to provide redundancy. See [RFC3446] for more details. 592 9. Acknowledgements 594 We would like to thank Loa Andersson, Pranjal Dutta, Lizhong Jin, and 595 Curtis Villamizar for their review and comments. 597 10. IANA Considerations 599 There are no new allocations required from IANA. 601 11. Security Considerations 603 There are no security considerations other then ones already 604 mentioned in [RFC5036], [RFC6826] and [RFC7246]. 606 12. References 608 12.1. Normative References 610 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 611 Requirement Levels", BCP 14, RFC 2119, March 1997. 613 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 614 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 615 Protocol Specification (Revised)", RFC 4601, August 2006. 617 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 618 "Internet Group Management Protocol (IGMP) / Multicast 619 Listener Discovery (MLD)-Based Multicast Forwarding 620 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 622 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 623 Specification", RFC 5036, October 2007. 625 [RFC6826] Wijnands, IJ., Eckert, T., Leymann, N., and M. Napierala, 626 "Multipoint LDP In-Band Signaling for Point-to-Multipoint 627 and Multipoint-to-Multipoint Label Switched Paths", RFC 628 6826, January 2013. 630 [RFC7246] Wijnands, IJ., Hitchen, P., Leymann, N., Henderickx, W., 631 Gulko, A., and J. Tantsura, "Multipoint Label Distribution 632 Protocol In-Band Signaling in a Virtual Routing and 633 Forwarding (VRF) Table Context", RFC 7246, June 2014. 635 12.2. Informative References 637 [GTM] Zhang, J., Giulano, L., Rosen, E., Subramanian, K., 638 Pacella, D., and J. Schiller, "Global Table Multicast with 639 BGP-MVPN Procedures", internet-draft draft-ietf-bess-mvpn- 640 global-table-mcast-00, November 2014. 642 [RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast 643 Rendevous Point (RP) mechanism using Protocol Independent 644 Multicast (PIM) and Multicast Source Discovery Protocol 645 (MSDP)", RFC 3446, January 2003. 647 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 648 Protocol (MSDP)", RFC 3618, October 2003. 650 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 651 "Bidirectional Protocol Independent Multicast (BIDIR- 652 PIM)", RFC 5015, October 2007. 654 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 655 VPNs", RFC 6513, February 2012. 657 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 658 Encodings and Procedures for Multicast in MPLS/BGP IP 659 VPNs", RFC 6514, February 2012. 661 Authors' Addresses 663 IJsbrand Wijnands (editor) 664 Cisco Systems, Inc. 665 De kleetlaan 6a 666 Diegem 1831 667 BE 669 Email: ice@cisco.com 670 Eric C. Rosen 671 Juniper Networks, Inc. 672 10 Technology Park Drive 673 Westford, MA 01886 674 US 676 Email: erosen@juniper.net 678 Arkadiy Gulko 679 Thomson Reuters 680 195 Broadway 681 New York NY 10007 682 US 684 Email: arkadiy.gulko@thomsonreuters.com 686 Uwe Joorde 687 Deutsche Telekom 688 Hammer Str. 216-226 689 Muenster D-48153 690 DE 692 Email: Uwe.Joorde@telekom.de 694 Jeff Tantsura 695 Ericsson 696 300 Holger Way 697 San Jose, CA 95134 698 US 700 Email: jeff.tantsura@ericsson.com