idnits 2.17.1 draft-ietf-mpls-mldp-in-band-wildcard-encoding-00.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 (March 3, 2014) is 3706 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) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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: September 4, 2014 A. Gulko 6 Thomson Reuters 7 U. Joorde 8 Deutsche Telekom 9 J. Tantsura 10 Ericsson 11 March 3, 2014 13 mLDP In-Band Signaling with Wildcards 14 draft-ietf-mpls-mldp-in-band-wildcard-encoding-00 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 exists 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), either in the context of a particular VPN or in a 27 "global" (non-VPN) context. However, the previous documents do not 28 specify procedures for attaching IP "Any Source Multicast" trees to 29 MP-LSPs, nor do they specify procedures "aggregating" multiple IP 30 multicast trees onto a single MP-LSP. This document specifies the 31 procedures to support these functions. It does so by defining 32 "wildcard" encodings making it possible to specify, when setting up 33 an MP-LSP, that a set of IP multicast trees or a shared IP multicast 34 tree should be attached to that MP-LSP. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on September 4, 2014. 53 Copyright Notice 55 Copyright (c) 2014 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5 72 3. Wildcards in mLDP Opaque Value TLVs . . . . . . . . . . . . . 7 73 4. Some Wildcard Use Cases . . . . . . . . . . . . . . . . . . . 8 74 4.1. PIM shared tree forwarding . . . . . . . . . . . . . . . . 8 75 4.2. IGMP/MLD proxying . . . . . . . . . . . . . . . . . . . . 9 76 4.3. Selective Source mapping . . . . . . . . . . . . . . . . . 10 77 5. Procedures for Wildcard Source Usage . . . . . . . . . . . . . 10 78 6. Procedures for Wildcard Group Usage . . . . . . . . . . . . . 11 79 7. Determining the MP-LSP Root (Ingress LSR) . . . . . . . . . . 11 80 8. Anycast RP . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 82 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 83 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 12.1. Normative References . . . . . . . . . . . . . . . . . . . 12 86 12.2. Informative References . . . . . . . . . . . . . . . . . . 13 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 89 1. Introduction 91 [RFC6826] and [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] specify 92 procedures for mLDP (Multiple Extensions to the Label Distribution 93 Protocol) that allow an IP multicast tree (either a "Source-Specific 94 Multicast" tree or a "Bidirectional multicast" tree) to be attached 95 "seamlessly" to an MPLS multipoint label switched path (MP-LSP). 96 This can be useful, for example, when there is multicast data that 97 originates in a domain that supports IP multicast, then has to be 98 forwarded across a domain that supports MPLS multicast, then has to 99 forwarded across another domain that supports IP multicast. By 100 attaching an IP multicast tree to an MP-LSP, data that is traveling 101 along the IP multicast tree is moved to the MP-LSP. The data then 102 travels along the MP-LSP through the MPLS domain. When the reaches 103 the boundary of the MPLS domain, it can be seamlessly passed along an 104 IP multicast tree. This can be useful in either VPN context or 105 global context. 107 When following the procedures of those documents, a given MP-LSP can 108 carry data from only a single IP source-specific multicast tree 109 (i.e., a single "(S,G) tree"). However, there are scenarios in which 110 it would be desirable to "aggregate" a number of (S,G) trees on a 111 single MP-LSP. Aggregation allows a given number of IP multicast 112 trees to using a smaller number of MP-LSPs, thus saving state in the 113 network. 115 In addition, the previous documents do not support the attachment of 116 an "Any Source Multicast" (ASM) shared tree to an MP-LSP (except in 117 the case where the ASM shared tree is a "bidirectional" tree (i.e., a 118 tree set up by BIDIR-PIM [RFC5015]. However, there are scenarios in 119 which it would be desirable to attach a non-bidirectional ASM shared 120 tree to an MP-LSP. 122 In mLDP, every MP-LSP is identified by the combination of a "root 123 node" (or "Ingress LSR") and an "Opaque Value" that uniquely 124 identifies the MP-LSP in the context of the root node. When mLDP in- 125 band signaling is used (for non-bidirectional trees), the Opaque 126 Value has an IP Source Address (S) and an IP Group Address (G) 127 encoded into it, thus enabling it to identify a particular IP 128 multicast (S,G) tree. 130 This document specifies a way to encode an mLDP "Opaque Value" that 131 replaces either the "S" or the "G" or both by a "wildcard". 132 Procedures are described for using the wildcard encoding to map non- 133 bidirectional ASM shared trees to MP-LSPs, and for mapping multiple 134 (S,G) trees (with a common value of S or a common value of G) to a 135 single MP-LSP. 137 Some example scenarios where wildcard encoding is useful are: 139 o PIM Shared tree forwarding with threshold infinity. 141 o IGMP/MLD proxying. 143 o Selective Source mapping. 145 These scenarios are discussed in Section 4. Note that this list of 146 scenarios is not meant to be exhaustive. 148 This draft specifies only the mLDP procedures that are specific to 149 the use of wildcards. mLDP in-band signaling procedures that are not 150 specific to the use of wildcards can be found in [RFC6826] and 151 [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling]. Unless otherwise 152 specified in this document, those procedures still apply when 153 wildcards are used. 155 2. Terminology and Definitions 157 Readers of this document are assumed to be familiar with the 158 terminology and concepts of the documents listed as Normative 159 References. For convenience, some of the more frequently used terms 160 appear below. 162 IGMP: 163 Internet Group Management Protocol. 165 In-band signaling: 166 Using the opaque value of a mLDP FEC element to carry the (S,G) or 167 (*,G) identifying a particular IP multicast tree. 169 Ingress LSR: 170 Root node of a MP-LSP. When in-band signaling is used, the 171 Ingress LSR receives mLDP messages about a particular MP-LSP from 172 "downstream", and emits IP multicast control messages "upstream". 173 The set of IP multicast control messages that are emitted upstream 174 depends upon the contents of the LDP Opaque Value TLVs. The 175 Ingress LSR also receives IP multicast data messages from 176 "upstream" and sends them "downstream" as MPLS packets on a MP- 177 LSP. 179 IP multicast tree: 180 An IP multicast distribution tree identified by a IP multicast 181 group address and optionally a Source IP address, also referred to 182 as (S,G) and (*,G). 184 MLD: 185 Multicast Listener Discovery. 187 mLDP: 188 Multipoint LDP. 190 MP-LSP: 191 A P2MP or MP2MP LSP. 193 PIM: 194 Protocol Independent Multicast. 196 PIM-ASM: 197 PIM Any Source Multicast. 199 PIM-SM: 200 PIM Sparse Mode 202 PIM-SSM: 203 PIM Source Specific Multicast. 205 RP: 206 The PIM Rendezvous Point. 208 Egress LSR: 209 The Egress LSRs of an MP-LSP are LSPs that receive MPLS multicast 210 data packets from "upstream" on that MP-LSP, and that forward that 211 data "downstream" as IP multicast data packets. The Egress LSRs 212 also receive IP multicast control messages from "downstream", and 213 send mLDP control messages "upstream". When in-band signaling is 214 used, the Egress LSRs construct Opaque Value TLVs that contain IP 215 source and/or group addresses, based on the contents of the IP 216 multicast control messages received from downstream. 218 Threshold Infinity: 219 A PIM-SM procedure where no source specific multicast (S,G) trees 220 are created for multicast packets that are forwarded down the 221 shared tree (*,G). 223 TLV: 224 A protocol element consisting of a type field, followed by a 225 length field, followed by a value field. Note that the value 226 field of a TLV may be sub-divided into a number of sub-fields. 228 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 229 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 230 document are to be interpreted as described in RFC 2119 [RFC2119]. 232 3. Wildcards in mLDP Opaque Value TLVs 234 [RFC6826] and [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] define the 235 following TLVs: Transit IPv4 Source TLV, Transit IPv6 Source TLV, 236 Transit VPNv4 Source TLV, and Transit VPNv6 Source TLV. The value 237 fields of each such TLV is divided into a number of sub-fields, one 238 of which contains an IP source address, and one of which contains an 239 IP group address. Per those documents, these fields must contain 240 valid IP addresses. 242 This document extends the definition of those TLVs by allowing either 243 the IP Source Address field or the IP Group Address field (or both) 244 to specify a "wildcard" rather than a valid IP address. 246 A value of all zeroes in the IP Source Address sub-field is used to 247 represent a wildcard source address. A value of all zeroes in the IP 248 Group Address sub-field is used to represent the wildcard group 249 address. Note that the lengths of these sub-fields is as specified 250 in the previous documents. 252 If the IP Source Address sub-field contains the wildcard, and the IP 253 Group Address sub-field contains an IP multicast group address, say 254 G, that is NOT in the SSM address range (see Section 4.8 of 255 [RFC4601]), the TLV identifies a PIM-SM shared tree. 257 If the IP Source Address sub-field contains the wildcard, and the IP 258 Group Address sub-field contains an IP multicast group address, say 259 G, that is in the SSM address range, the TLV identifies the 260 collection of PIM-SSM trees with the given group address. 262 If the IP Source Address sub-field contains a non-zero IP address, 263 and the IP Group Address sub-field contains the wildcard, the TLV 264 identifies the collection of PIM-SSM trees that have the source 265 address as their root. 267 Procedures for the use of the wildcards are discussed in Sections 4, 268 5 and 6. Please note that, as always, the structure of the Opaque 269 Value TLVs does not actually affect the operation of mLDP, but only 270 affects the interface between mLDP and IP multicast. 272 At the present time, there are no procedures defined for the use of a 273 wildcard group in the following TLVs that are defined in [RFC6826] or 274 [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling]: Transit IPv4 Bidir TLV, 275 Transit IPv6 Bidir TLV, Transit VPNv4 Bidir TLV, Transit VPNv6 Bidir 276 TLV. Such procedures may be added in a later revision of this 277 document. Note that the Bidir TLVs do not have a "Source Address" 278 sub-field, and hence the notion of a wildcard source is not 279 applicable to them. 281 At the present time, there are no procedures defined for the use of 282 both a wildcard source and a wildcard group in the same TLV. Such 283 procedures may be added in a later revision of this document. 285 4. Some Wildcard Use Cases 287 This section discusses a number of wildcard use cases. The set of 288 use cases here is not meant to be exhaustive. In each of these use 289 cases, the Egress LSRs construct mLDP Opaque Value TLVs that contain 290 wildcards in the IP Source Address or IP Group Address sub-fields. 292 4.1. PIM shared tree forwarding 294 PIM [RFC4601] has the concept of a "shared tree", identified as 295 (*,G). This concept is only applicable when G is an IP Multicast 296 Group address that is not in the SSM address range (i.e., is an ASM 297 group address). Every ASM group is associated with a Rendezvous 298 Point (RP), and the (*,G) tree is built towards the RP (i.e., its 299 root is the RP). The RP for group G is responsible for forwarding 300 packets down the (*,G) tree. The packets forwarded down the (*,G) 301 tree may be from any multicast source, as long as they have an IP 302 destination address of G. 304 The RP learns about all the multicast sources for a given group, and 305 then joins a source-specific tree for each such source. I.e., when 306 the RP for G learns that S has multicast data to send to G, the RP 307 joins the (S,G) tree. When the RP receives multicast data from S 308 that is destined to G, the RP forwards the data down the (*,G) tree. 309 There are several different ways that the RP may learn about the 310 sources for a given group. The RP may learn of sources via PIM 311 Register messages [RFC4601], via MSDP [RFC3618] or by observing 312 packets from a source that is directly connected to the RP. 314 In PIM, a PIM router that has receivers for a particular ASM 315 multicast group G (known as a "last hop" router for G) will first 316 join the (*,G) tree. As it receives multicast traffic on the (*,G) 317 tree, it learns (by examining the IP headers of the multicast data 318 packets) the sources that are transmitting to G. Typically, when a 319 last hop router for group G learns that source S is transmitting to 320 G, the last hop router joins the (S,G) tree, and "prunes" S off the 321 (*,G) tree. This allows each last hop router to receive the 322 multicast data along the shortest path from the source to the last 323 hop router. (Full details of this behavior can be found in 324 [RFC4601].) 326 In some cases, however, a last hop router for group G may decide not 327 to join the source trees, but rather to keep receiving all the 328 traffic for G from the (*,G) tree. In this case, we say that the 329 last hop router has "threshold infinity" for group G. This is 330 optional behaviour documented in [RFC4601]. "Threshold infinity" is 331 often used in deployments where the RP is between the multicast 332 sources and the multicast receivers for group G, i.e., in deployments 333 where it is known that the shortest path from any source to any 334 receiver of the group goes through the RP. In these deployments, 335 there is no advantage for a last hop router to join a source tree, 336 since the data is already traveling along the shortest path. The 337 only effect of executing the complicated procedures for joining a 338 source tree and pruning the source off the shared tree would be to 339 increase the amount of multicast routing state that has to be 340 maintained in the network. 342 To efficiently use mLDP in-band signaling in this scenario, it is 343 necessary for the Egress LSRs to construct an Opaque Value TLV that 344 identifies a (*,G) tree. This is done by using the wildcard in the 345 IP Source Address sub-field, and setting the IP Group Address sub- 346 field to G. 348 Note that these mLDP in-band signaling procedures do not support PIM- 349 ASM in scenarios where "threshold infinity" is not used. 351 4.2. IGMP/MLD proxying 353 There are scenarios where the multicast senders and receivers are 354 directly connected to an MPLS routing domain, and where it is desired 355 to use mLDP rather than PIM to set up "trees" through that domain. 357 In these scenarios we can apply "IGMP/MLD proxying" and eliminate the 358 use of PIM. The senders and receivers consider the MPLS domain to be 359 single hop between each other. [RFC4605] documents procedures where 360 a multicast routing protocol is not nessesary to build a 'simple 361 tree'. Within the MPLS domain, mLDP will be used to build a MP-LSP, 362 but this is hidden from the senders and receivers. The procedures 363 defined in [RFC4605] are applicable, since the senders and receivers 364 are considered to be one hop away from each other. 366 For mLDP to build the necessary MP-LSP, it needs to know the root of 367 the tree. Following the procedures as defined in [RFC4605] we use 368 the "proxy-device" as the mLDP root for the ASM multicast group. 369 Since the MP-LSP for a given ASM multicast group will carry traffic 370 from all the sources for that group, the Opaque Value TLV used to 371 construct the MP-LSP will contain a wildcard in the IP Source Address 372 sub-field. 374 4.3. Selective Source mapping 376 In many IPTV deployments, the content servers are gathered into a 377 small number of sites. Popular channels are often statically 378 configured, and forwarded over a core MPLS network to the egress 379 routers. Since these channels are statically defined, they MAY also 380 be forwarded over a multipoint LSP with wildcard encoding. The sort 381 of wildcard encoding that needs to be used (Source and/or Group) 382 depends on the Source/Group allocation policy of the IPTV provider. 383 Other options are to use MSDP [RFC3618] or BGP "Auto-Discovery" 384 procedures [RFC6513] for source discovery by the Ingress LSR. Based 385 on the received wildcard, the Ingress LSR can select from the set of 386 IP multicast streams for which it has state. 388 5. Procedures for Wildcard Source Usage 390 The IP multicast component on an Egress LSR determines when a 391 wildcard is to be used in the IP Source Address sub-field of an mLDP 392 Opaque Value TLV. How the IP multicast component determines this is 393 a local matter, and may need to be explicitly configured. It MAY 394 however use the following rules (with or without explicit 395 configuration); 397 1. Suppose that PIM is enabled, and an Egress LSR needs to join a 398 non-bidirectional ASM group G, and the RP for G is reachable via 399 a BGP route. The Egress LSR MAY choose the BGP Next Hop of the 400 route to the RP to be the Ingress LSR (root node) of the MP-LSP 401 corresponding to the (*,G) tree. (See also Section 7.) The 402 Egress LSR MAY identify the (*,G) tree by using an mLDP Opaque 403 Value TLV whose IP Source Address sub-field contains a wildcard, 404 and whose IP Group Address sub-field contains G. 406 2. If PIM is not enabled for group G, and an IGMP/MLD group 407 membership report for G has been received, the Egress LSR may 408 determine the "proxy device" for G (following the procedures 409 defined in [RFC4605]). It can then set up an MP-LSP using the 410 proxy device as the Ingress LSR. The Egress LSR then needs to 411 signal the Ingress LSR that the MP-LSP is to carry traffic 412 belonging to group G. It does this by using an Opaque Value TLV 413 whose IP Source Address sub-field contains a wildcard, and whose 414 IP Group Address sub-field contains G. 416 When the Ingress LSR receives an mLDP Opaque Value TLV that has been 417 defined for in-band signaling, the information from the sub-fields of 418 that TLV is passed to the IP multicast component of the Ingress LSR. 419 If the IP Source Address sub-field contains a wildcard, the IP 420 multicast component must determine how to process it. How the 421 wildcard is processed is a local matter, subject to the rules below: 423 1. If PIM is enabled and the group identified in the Opaque Value 424 TLV is a non-bidirectional ASM group, the Ingress LSR acts as if 425 it had received a (*,G) IGMP/MLD report from a downstream node, 426 and the procedures defined in [RFC4601] are followed. 428 2. If PIM is enabled and the identified group is a PIM-SSM group, 429 all multicast sources known for the group on the Ingress LSR are 430 to be forwarded down the MP-LSP. 432 3. If PIM is not enabled for identified group, the Ingress LSR acts 433 as if it had received a (*,G) IGMP/MLD report from a downstream 434 node, and the procedures as defined in [RFC4605] are followed. 436 6. Procedures for Wildcard Group Usage 438 The IP multicast component on an Egress LSR determines when a 439 wildcard is to be used in the IP Group Address sub-field of an mLDP 440 Opaque Value TLV. How the IP multicast component determines this is 441 a local matter, and may need to be explicitly configured. 443 When the Ingress LSR (i.e., the root node of the MP-LSP) receives an 444 mLDP Opaque Value TLV that has been defined for in-band signaling, 445 the information from the sub-fields of that TLV is passed to the IP 446 multicast component of the Ingress LSR. If the IP Group Address sub- 447 field contains a wildcard, the Ingress LSR examines its IP multicast 448 routing table, to find all the IP multicast streams whose IP source 449 address is the address specified in the IP Source Address sub-field 450 of the TLV. All these streams SHOULD be forwarded down the MP-LSP 451 identified by the Opaque Value TLV. Note that some of these streams 452 may have SSM group addresses, while some may have ASM group 453 addresses. 455 7. Determining the MP-LSP Root (Ingress LSR) 457 Documents [RFC6826] and [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] 458 describe procedures by which an Egress LSR may determine the MP-LSP 459 root node address corresponding to a given IP multicast stream, based 460 upon the IP address of the source of the IP multicast stream. When a 461 wildcard source encoding is used, PIM is enabled, and the group is a 462 non-bidirectional ASM group, a similar procedure is applied. The 463 only difference from the above mentioned procedures is that the Proxy 464 device or RP address is used instead of the Source to discover the 465 mLDP root node address. 467 In all other cases some sort of manual configuration is applied in 468 order to find the root node. Note, finding the root node is a local 469 implementation matter and not limited to the solutions mentioned in 470 this document. 472 8. Anycast RP 474 In the scenarios where in-band signaling is used, it is unlikely that 475 the RP-to-Group mappings are being dynamically distributed over the 476 MPLS core. It is more likely that the RP address is statically 477 configured at each multicast site. In these scenarios, it is 478 advisable to configure an Anycast RP Address at each site, in order 479 to provide redundancy. See [RFC3446] for more details. 481 9. Acknowledgements 483 We would like to thank Loa Andersson for his review and comments. 485 10. IANA Considerations 487 There are no new allocations required from IANA. 489 11. Security Considerations 491 There are no security considerations other then ones already 492 mentioned in [RFC6826] and 493 [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling]. 495 12. References 497 12.1. Normative References 499 [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] 500 Wijnands, I., Hitchen, P., Leymann, N., Henderickx, W., 501 arkadiy.gulko@thomsonreuters.com, a., and J. Tantsura, 502 "Multipoint Label Distribution Protocol In-Band Signaling 503 in a VRF Context", 504 draft-ietf-l3vpn-mldp-vrf-in-band-signaling-03 (work in 505 progress), January 2014. 507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 508 Requirement Levels", BCP 14, RFC 2119, March 1997. 510 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 511 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 512 Protocol Specification (Revised)", RFC 4601, August 2006. 514 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 515 "Internet Group Management Protocol (IGMP) / Multicast 516 Listener Discovery (MLD)-Based Multicast Forwarding 517 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 519 [RFC6826] Wijnands, IJ., Eckert, T., Leymann, N., and M. Napierala, 520 "Multipoint LDP In-Band Signaling for Point-to-Multipoint 521 and Multipoint-to-Multipoint Label Switched Paths", 522 RFC 6826, January 2013. 524 12.2. Informative References 526 [RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast 527 Rendevous Point (RP) mechanism using Protocol Independent 528 Multicast (PIM) and Multicast Source Discovery Protocol 529 (MSDP)", RFC 3446, January 2003. 531 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 532 Protocol (MSDP)", RFC 3618, October 2003. 534 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 535 "Bidirectional Protocol Independent Multicast (BIDIR- 536 PIM)", RFC 5015, October 2007. 538 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 539 VPNs", RFC 6513, February 2012. 541 Authors' Addresses 543 IJsbrand Wijnands (editor) 544 Cisco 545 De kleetlaan 6a 546 Diegem, 1831 547 Belgium 549 Phone: 550 Email: ice@cisco.com 551 Eric Rosen 552 Cisco 553 1414 Massachusetts Avenue 554 Boxborough, MA 01719 555 USA 557 Phone: 558 Email: erosen@cisco.com 560 Arkadiy Gulko 561 Thomson Reuters 562 195 Broadway 563 New York NY 10007 564 USA 566 Email: arkadiy.gulko@thomsonreuters.com 568 Uwe Joorde 569 Deutsche Telekom 570 Hammer Str. 216-226 571 Muenster D-48153 572 DE 574 Email: Uwe.Joorde@telekom.de 576 Jeff Tantsura 577 Ericsson 578 300 Holger Way 579 San Jose, california 95134 580 usa 582 Email: jeff.tantsura@ericsson.com