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