idnits 2.17.1 draft-ietf-pim-mtid-10.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 (September 27, 2011) is 4592 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) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PIM WG Yiqun Cai 3 Internet Draft Heidi Ou 4 Intended Status: Proposed Standard 5 Expires: March 27, 2012 Cisco Systems, Inc. 7 September 27, 2011 9 PIM Multi-Topology ID (MT-ID) Join Attribute 11 draft-ietf-pim-mtid-10.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 27, 2012. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Abstract 53 This document introduces a new type of PIM Join Attribute that 54 extends PIM signaling to identify a topology that should be used when 55 constructing a particular multicast distribution tree. 57 Table of Contents 59 1 Terminologies ...................................... 3 60 2 Introduction ....................................... 3 61 3 Functional Overview ................................ 4 62 3.1 PIM RPF Topology ................................... 5 63 3.2 PIM MT-ID .......................................... 6 64 3.3 Applicability ...................................... 7 65 4 Protocol Specification of PIM MT-ID ................ 7 66 4.1 PIM MT-ID Hello Option ............................. 7 67 4.2 PIM MT-ID Join Attribute ........................... 8 68 4.2.1 Sending PIM MT-ID Join Attribute ................... 8 69 4.2.2 Receiving PIM MT-ID Join Attribute ................. 8 70 4.2.3 Validating PIM MT-ID Join Attribute ................ 9 71 4.2.4 Conflict Resolution ................................ 10 72 4.2.4.1 Conflict Resolution Rules For Upstream Routers ..... 10 73 4.2.4.2 Conflict Resolution Rules For Downstream Routers ... 11 74 5 Packet Format ...................................... 11 75 5.1 PIM MT-ID Hello Option ............................. 11 76 5.2 PIM MT-ID Join Attribute TLV Format ................ 12 77 6 IANA Considerations ................................ 12 78 6.1 PIM MT-ID Hello Option ............................. 12 79 6.2 PIM MT-ID Join Attribute Type ...................... 13 80 7 Security Considerations ............................ 13 81 8 Acknowledgments .................................... 13 82 9 Authors' Addresses ................................. 13 83 10 Normative References ............................... 14 84 11 Informative References ............................. 14 86 1. Terminologies 88 The following acronyms are frequently used in the document. 90 - RPF: RPF stands for "Reverse Path Forwarding". A PIM router 91 performs RPF for two purposes. When building a forwarding tree, 92 a PIM router identifies an interface (the RPF interface) and an 93 upstream PIM neighbor (the RPF neighbor) to which to send PIM 94 Joins. Upon receiving a data packet, a PIM router verifies if 95 the packet arrives from the expected incoming interface (aka RPF 96 check) before deciding whether or not to replicate the packets. 98 - RPF Topology: An RPF topology is a collection of routes that a 99 PIM router uses for RPF. One or more RPF topologies may be 100 created on a PIM router. 102 - MT: MT stands for "Multi-Topology" in this document. Sometimes 103 it is also referred to as multi-topology routing. In the context 104 of PIM, MT refers to the capability of building and maintaining 105 multiple RPF topologies. 107 - PIM MT-ID: An MT-ID is a numerical identifier associated with an 108 RPF topology. 110 - PIM MT-ID Join Attribute: This is a new type of Join Attribute 111 that is introduced by this document in order to specify RPF 112 topology in the PIM Join messages. 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 116 "OPTIONAL" in this document are to be interpreted as described in 117 [RFC2119]. 119 2. Introduction 121 Some unicast protocols, such as OSPF and IS-IS, allow a single 122 network to be viewed as multiple topologies [RFC4915], [RFC5120]. 123 Deploying multi-topology (MT) routing allows different paths through 124 the network to be selected to support different traffic, or to offer 125 protection paths in the event of failures. 127 PIM [RFC4601] employs a technique known as Reverse Path Forwarding 128 (RPF) to construct forwarding trees between multicast sources and 129 receivers. The procedure of RPF uses topology information provided 130 by routing protocols, such as OSPF and IS-IS. Using the PIM MT-ID 131 Join Attribute specified in this document enables PIM to access the 132 multiple topologies created by the routing protocols and construct 133 multicast forwarding trees using separate network paths even when the 134 roots of the trees are the same. 136 This capability would allow for an improvement to the resilience of 137 multicast applications. For instance, a multicast stream can be 138 duplicated and transported using two source trees, (S1, G1) and (S1, 139 G2), simultaneously. By using MT capable unicast routing protocols 140 and procedures described in this document, it is possible to 141 construct two source trees for (S1, G1) and (S1, G2) in such a way 142 that they do not share any transit network segment. As a result, a 143 single network failure will not cause any loss to the stream. 145 This document introduces a new type of PIM Join Attribute [RFC5384], 146 named MT-ID Join Attribute. It is used to encode the numerical 147 identity of the topology PIM uses when performing RPF for the 148 forwarding tree that is being joined. This document also specifies 149 procedures and rules to process the attribute and resolve conflicts 150 arising from mismatches in capabilities to support the attribute or 151 the value of the attribute. 153 This document does not introduce any change to the RPF check 154 procedure used to verify the incoming interface when a packet is 155 forwarded as defined in [RFC4601]. For example, to use the 156 capability described by this document, an application can choose to 157 use group addresses, and/or source addresses, to identify a unique 158 multicast stream. It might further need to perform the functions of 159 splitting and merging. But the detailed processing is beyond the 160 scope of the document. 162 In the rest of the document, the MT-ID Join Attribute will be 163 referred to as "MT-ID". 165 3. Functional Overview 167 PIM relies on routes learned from routing protocols for the purpose 168 of RPF. These routes form one or more topologies. This section 169 describes the function of multi-topology routing for PIM and its 170 applicability. 172 3.1. PIM RPF Topology 174 PIM RPF topology is a collection of routes used by PIM to perform RPF 175 operation when building shared or source trees. The routes in the 176 topology may be contributed by different protocols. In the rest of 177 the document, PIM RPF topology may be simply referred to as 178 "topology" when there is no ambiguity. 180 In a multi-topology environment, multiple RPF topologies can be 181 created in the same network. A particular source may be reachable in 182 only one of the topologies, or in several of them via different 183 paths. 185 To help explain the relationship between MT capable unicast routing 186 protocol and MT capable RPF topologies, consider the following 187 example described by Figure 1. 189 +++ A +++ B +++ 190 + + 191 S -- R1 R2 -- receivers 192 * * 193 *** C *** D *** 195 Figure 1. A simple topology for multicast 197 - The traffic source is S. S is announced by R1 using MBGP to 198 every router. This route is installed in every topology. 200 - Two topologies are created in the unicast IGP, let us call them 201 OSPF 1000 and OSPF 2000. OSPF 1000 includes A, B and interfaces 202 in R1 and R2 that are configured to be part of OSPF 1000. OSPF 203 2000 includes C, D and interfaces on R1 and R2 that are 204 configured to be part of OSPF 2000. 206 - Two PIM RPF topologies are created, let us call them PIM 500 and 207 PIM 600. 209 PIM 500 comprises the following routes: S announced by MBGP and 210 those learned via OSPF 1000. 212 PIM 600 comprises the following routes: S announced by MBGP and 213 those learned via OSPF 2000 215 The above example illustrates that the naming spaces of MT-ID are not 216 required to be the same between PIM and IGPs. Furthermore, a unicast 217 IGP topology and the PIM RPF topology to which the IGP topology 218 contributes routes are not required to have the same set of routes. 219 In the above example, the prefix covering S does not exist in either 220 OSPF 1000 or OSPF 2000. But since it exists in PIM 500 and PIM 600, 221 R2 is able to join to it via either path. 223 There are two methods to select the RPF topology for a particular 224 multicast distribution tree, via configuration or via PIM. 226 When it is done via configuration, a network administrator configures 227 a policy that maps a group range to a topology, and/or maps a source 228 prefix range to a topology. Using the same example, the policy can 229 say that to build a forwarding tree for G1 only routes in PIM 500 are 230 to be used, and to build a forward tree for G2 only routes in PIM 600 231 are used. The result is that packets for (S, G1) will follow the 232 path of S-R1-A-B-R2 and packets for (S, G2) will follow the path of 233 S-R1-C-D-R2. 235 An alternative to static configuration is to include the RPF topology 236 information as a new PIM Join Attribute in the PIM Join packets sent 237 by downstream routers. 239 Both methods can be used at the same time. The details of the first 240 method are implementation specific and are not discussed in this 241 document. The specification to support the second method is included 242 in this document. 244 3.2. PIM MT-ID 246 For each PIM RPF topology created, a unique numerical ID is assigned 247 per PIM domain. This ID is called the PIM MT-ID. The PIM MT-ID has 248 the following properties, 250 - It is the path identifier that is used by PIM control plane, but 251 does not function in the forwarding state for a specific 252 topology. The differentiation for topologies on forwarding plane 253 is made by different group addresses, and/or source addresses 254 instead. 256 - As shown earlier, this value is not required to be the same as 257 the MT-ID used by the unicast routing protocols that contribute 258 routes to the topology. In practice, when only one unicast 259 routing protocol (such as OSPF or IS-IS) is used, the PIM MT-ID 260 is RECOMMENDED to be assigned using the same value as the IGP 261 topology identifier. Using the same example presented earlier, if 262 every route in PIM 500 is contributed by OSPF 1000, it is 263 RECOMMENDED to name this RPF topology as PIM 1000 instead of PIM 264 500. This is for the purpose of reducing management overhead and 265 simplifying troubleshooting. 267 - This value MUST be unique and consistent within the network for 268 the same topology. For example, PIM 500 MUST refer to the same 269 topology on routers R1, C, D and R2. For actual deployment, one 270 should have a means to detect inconsistency of the PIM MT-ID 271 configuration, but the detail of such mechanism is beyond the 272 scope of this document. 274 - 0 is reserved as the default, and MUST NOT be included in the 275 Join Attribute encoding. 277 - How to assign a PIM MT-ID to a topology is decided by the network 278 administrator and is outside the scope of this document 280 3.3. Applicability 282 The PIM MT-ID Join Attribute described in this document applies to 283 PIM Join/Assert packets used by PIM SM/SSM/Bidir. It is not used in 284 any other PIM packets. As such, it can only be used to build shared 285 or source trees for PIM SM/SSM and PIM-bidir downstream. 287 When this attribute is used in combination with RPF vectors defined 288 in [RFC5496] and [ID.ietf-l3vpn-2547bis-mcast], the vectors are 289 processed against the topology identified by the PIM MT-ID attribute. 291 4. Protocol Specification of PIM MT-ID 293 The change to the PIM protocol includes two pieces, PIM MT-ID Hello 294 Option and PIM MT-ID Join Attribute. 296 4.1. PIM MT-ID Hello Option 298 PIM MT-ID Hello Option is used by a router to indicate if it supports 299 the functionality described by this document. If it does, it MUST 300 include the PIM Hello Option in its PIM Hello packets and MUST 301 include both the Join Attribute Option [RFC5384] and the new PIM MT- 302 ID Option (see Section 5.1 of this document for packet format). 304 4.2. PIM MT-ID Join Attribute 306 4.2.1. Sending PIM MT-ID Join Attribute 308 When a PIM router originates a PIM Join/Assert packet, it may choose 309 to encode PIM MT-ID of the topology in which RPF lookup is to take 310 place for the corresponding (*,G) or (S,G) entry. The PIM MT-ID 311 identifies the topology chosen by local policy/configuration or is 312 the value received from downstream routers after MT-ID conflict 313 resolution procedures have been applied (See Section 4.2.4 for 314 further detail). 316 The following are the exceptions, 318 - A router SHOULD NOT include the attribute if PIM MT-ID is 0. The 319 value of 0 is ignored on reception. 321 - A router SHOULD NOT include PIM MT-ID in its Join/Assert packets 322 if the upstream router, or any of the routers on the LAN does not 323 include "PIM Join Attribute" or "PIM MT-ID" Option in its Hello 324 packets. 326 - A router SHOULD NOT attach PIM MT-ID for pruned sources. PIM 327 MT-ID MUST be ignored for a pruned source by a router processing 328 the Prune message. 330 4.2.2. Receiving PIM MT-ID Join Attribute 332 When a PIM router receives a PIM MT-ID Join Attribute in a 333 Join/Assert packet, it MUST perform the following, 335 - Validate the attribute encoding. The detail is described in the 336 next section. 338 - If the Join Attribute is valid, use the rules described in the 339 section "Conflict Resolution" to determine a PIM MT-ID to use. 341 - Use the topology identified by the selected PIM MT-ID to perform 342 RPF lookup for the (*,G)/(S,G) entry unless a different topology 343 is specified by a local configuration. The local configuration 344 always takes precedence. 346 While it is an exception case, it is worthwhile to describe what will 347 happen if a router receives PIM MT-ID Join Attribute but doesn't 348 support functionality described in [RFC5384] or this document. 350 If the router supports [RFC5384] but not this document, it is able to 351 skip PIM MT-ID Join Attribute and move on to the next Join Attribute 352 if one is present. The RPF decision will not be altered because the 353 router doesn't understand the meaning of PIM MT-ID Join Attribute. 354 The router will use the procedures described by [RFC5384] to perform 355 conflict resolution. 357 If a router doesn't support [RFC5384], it will ignore the Join/Assert 358 message because it is not able to parse the encoded sources. 360 If a router does support both [RFC5384] and this document, but 361 chooses not to send either PIM MT-ID or PIM Join Attribute Option in 362 its Hello packets (likely due to administrative reason), when it 363 receives a PIM Join/Assert packets with PIM MT-ID Join Attribute, it 364 SHOULD ignore the Join/Assert message. 366 4.2.3. Validating PIM MT-ID Join Attribute 368 An upstream router MUST be known to support this document in order 369 for a downstream router to include the PIM MT-ID attribute in its 370 Join packets. But an upstream router doesn't need to know if a 371 downstream router supports this document or not when deciding whether 372 to accept the attribute. Hence, if the Join packet sender doesn't 373 include "PIM Join Attribute" or "PIM MT-ID" options in its Hello 374 packets, the PIM MT-ID attribute in the Join may still be considered 375 valid. This is also in accordance with the "Robustness Principle" 376 outlined in [RFC793]. 378 The following text specifies the detail of the validity check. 380 - There is at most 1 PIM MT-ID attribute encoded. If there are 381 multiple PIM MT-ID Join Attributes included (possibly due to an 382 error in the implementation), only the last one is accepted for 383 this particular source. Processing of the rest of the Join 384 message continues. 386 - The length field must be 2. If the length field is not 2, the 387 rest of the Join message, including the current (S,G) or (*,G) 388 entry, MUST be ignored. The group, source and the RP in the Join 389 message that have already been processed SHOULD still be 390 considered valid. 392 - The value MUST NOT be 0. If it is 0, the PIM MT-ID attribute is 393 ignored. Processing of the rest of the Join message, including 394 the current (S,G) or (*,G) entry, continues as if the particular 395 PIM MT-ID attribute weren't present in the packet. 397 4.2.4. Conflict Resolution 399 The definition of "PIM MT-ID conflict" varies depending on whether it 400 is on an upstream or a downstream router. 402 PIM MT-ID conflicts arises on an upstream router when the router 403 doesn't have a local topology selection policy and receives Join 404 packets from downstream routers and/or Assert packets from other 405 forwarding routers on the LAN and those packets contain different PIM 406 MT-IDs. 408 However, if an upstream router has a local configuration that 409 specifies PIM MT-IDs to identify RPF topologies, and those MT-IDs do 410 not match the MT-ID on a received Join or Assert packet, this is not 411 considered to be a conflict and the resolution procedures are not 412 applied. This includes the case where there are local PIM MT-IDs, 413 but there is no PIM MT-ID encoded in the incoming packet. 415 On the other hand, when a downstream router sees a different PIM MT- 416 ID attribute from other routers on the LAN it applies rules to 417 resolve the conflicts regardless of whether the router has local 418 topology selection policy or not. 420 When two PIM MT-IDs are compared, only the 12-bit Value field (see 421 Section 5.2) is compared. Other fields of the PIM MT-ID Join 422 Attribute TLV Format (including the four reserved bits) MUST NOT be 423 used in the comparison. 425 4.2.4.1. Conflict Resolution Rules For Upstream Routers 427 - If an upstream router receives different PIM MT-ID attributes 428 from PIM Join packets, it MUST follow the rules specified in 429 [RFC5384] to select one. The PIM MT-ID chosen will be the one 430 encoded for its upstream neighbor. 432 In order to minimize the chances of potential transient 433 forwarding loops, an upstream router MAY choose to ignore the 434 incoming PIM Join packets altogether if it sees a conflict in PIM 435 MT-ID attributes. This action may also be taken by an upstream 436 router which has locally configured topology selection policy, as 437 an exception to the rules described above. 439 - If an upstream router receives a different PIM MT-ID attribute in 440 an ASSERT packet, it MUST use the tie-breaker rules as specified 441 in [RFC4601] to determine an ASSERT winner. PIM MT-ID is not 442 considered in deciding a winner from Assert process. 444 4.2.4.2. Conflict Resolution Rules For Downstream Routers 446 - If a downstream router sees different PIM MT-ID attributes from 447 PIM Join packets, it MUST follow the specification of [RFC4601] 448 as if the attribute did not exist. For example, the router 449 suppresses its own Join packet if a Join for the same (S,G) is 450 seen. 452 The router MUST NOT use the rules specified in [RFC5384] to 453 select a PIM MT-ID from Join packets sent by other downstream 454 routers. 456 - If a downstream router sees its preferred upstream router loses 457 in the ASSERT process, and the ASSERT winner uses a different PIM 458 MT-ID, the downstream router SHOULD still choose the ASSERT 459 winner as the RPF neighbour but it MUST NOT encode PIM MT-ID when 460 sending Join packets to it. 462 5. Packet Format 464 This section describes the format of new PIM messages introduced by 465 this document. The messages follow the same transmission order as the 466 messages defined in [RFC4601]. 468 5.1. PIM MT-ID Hello Option 470 0 1 2 3 471 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | OptionType = 30 | OptionLength = 0 | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 - OptionType: 30. 478 - OptionLength: 0. 480 5.2. PIM MT-ID Join Attribute TLV Format 482 0 1 2 3 483 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 |F|E| Attr Type | Length |R R R R| Value | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 - F bit: 0 Non-transitive Attribute. 490 - E bit: As specified by [RFC5384]. 492 - Attr Type: To be assigned by IANA. 494 - Length: 2. 496 - R: Reserved bits, 4 in total. Set to zero on transmission. 497 Ignored upon receipt. 499 - Value: PIM MT-ID, 1 to 4095. 501 6. IANA Considerations 503 6.1. PIM MT-ID Hello Option 505 IANA maintains a registry of "Protocol Independent Multicast (PIM) 506 Parameters" with a sub-registry called "PIM-Hello Options" 508 The IANA assigned the PIM Hello Option type value 30 for the PIM MT- 509 ID Hello Option according to the First Come First Served allocation 510 policy. 512 The IANA is requested to make that allocation permanent with 513 reference to this document. 515 Note that the option defined in Section 5.1 of this document has 516 length 0. The IANA is requested to update the length value recorded 517 in the registry. 519 6.2. PIM MT-ID Join Attribute Type 521 The IANA maintains a registry of "Protocol Independent Multicast 522 (PIM) Parameters" with a sub-registry called "PIM Join Attribute 523 Types". 525 The IANA is requested to assign the next available value for the PIM 526 MT-ID Join Attribute defined in Section 5.2 of this document. 528 7. Security Considerations 530 As described in [RFC5384], the security of the Join Attribute is only 531 guaranteed by the security of the PIM packet that carries it. 532 Similarly, the security of the Hello Options is only guaranteed by 533 securing the whole Hello Packet. 535 In view of the fact that malicious alteration of the PIM MT-ID Hello 536 Option or the PIM MT-ID carried in a packet might cause the PIM 537 resiliency goals to be violated, the security considerations of 538 [RFC4601] apply to the extensions described in this document. 540 As a type of PIM Join Attribute, the security considerations 541 described in [RFC5384] apply here. Specifically, malicious alteration 542 of PIM MT-ID may cause the resiliency goals to be violated. 544 8. Acknowledgments 546 The authors would like to thank Eric Rosen, Ice Wijnands, Dino 547 Farinacci, Colby Barth, Les Ginsberg, Dimitri Papadimitriou, Thomas 548 Morin and Hui Liu for their input. 550 And the authors would also like to thank Adrian Farrel for his 551 detailed and constructive comments during the AD review. 553 9. Authors' Addresses 555 Yiqun Cai 556 Cisco Systems, Inc 557 170 West Tasman Drive 558 San Jose, CA 95134 560 E-mail: ycai@cisco.com 561 Heidi Ou 562 Cisco Systems, Inc 563 170 West Tasman Drive 564 San Jose, CA 95134 566 E-mail: hou@cisco.com 568 10. Normative References 570 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 571 Requirement Levels", RFC 2119, March 1997. 573 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 574 "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol 575 Specification (Revised)", RFC 4601, August 2006. 577 [RFC5384] A. Boers, I. Wijnands, E. Rosen, "The Protocol Independent 578 Multicast (PIM) Join Attribute Format", RFC 5384, November 2008 580 11. Informative References 582 [RFC793] ISI, "Transmission Control Protocol", RFC 793, September 583 1981. 585 [RFC4915] P. Psenak, S. Mirtorabi, A. Roy, L. Nguyen, P. Pillay- 586 Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, June 2007. 588 [RFC5120] T. Przygienda, N. Shen, N. Sheth, "M-ISIS: Multi Topology 589 (MT) Routing in Intermediate System to Intermediate Systems (IS- 590 ISs)", RFC 5120, February 2008. 592 [RFC5496] I. Wijnands, A. Boers, E. Rosen, "The Reverse Path 593 Forwarding (RPF) Vector TLV", RFC 5496, March 2009. 595 [ID.ietf-l3vpn-2547bis-mcast] E. Rosen,R Aggarwal, "Multicast in 596 MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-10, January 2010