idnits 2.17.1 draft-kebler-pim-mrt-protection-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.atlas-rtwg-mrt-mc-arch-00]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 650: '... Hello Option, then it MUST be capable...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 15, 2013) is 4089 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-rtgwg-mrt-frr-architecture' is defined on line 790, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-karan-mofrr (ref. 'I-D.karan-mofrr') ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) -- No information found for draft-atlas-rtwg-mrt-mc-arch-00 - is the name correct? == Outdated reference: A later version (-10) exists of draft-ietf-rtgwg-mrt-frr-architecture-01 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Protocol Independent Multicast Working R. Kebler, Ed. 2 Group A. Atlas 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track N. Shen 5 Expires: August 19, 2013 Cisco Systems, Inc. 6 Y. Cai 7 Microsoft 8 February 15, 2013 10 PIM Extensions for Protection Using Maximally Redundant Trees 11 draft-kebler-pim-mrt-protection-00 13 Abstract 15 This document specifies Protocol Independent Multicast (PIM) 16 procedures for Failure Protection, as specified in the MRT Multicast 17 architecture [I-D.atlas-rtwg-mrt-mc-arch-00]. This can be 18 accomplished with Global Repair (aka Live-Live) or with Local Repair 19 (aka Fast Re-route). Maximally Redundant Trees (MRTs) provide the 20 capability to PIM to provide alternate paths around any given 21 failure. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 19, 2013. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Global Protection (Live-Live) . . . . . . . . . . . . . . . . 4 60 3.1. Egress Router Behavior . . . . . . . . . . . . . . . . . . 5 61 3.2. Limitation when a LAN is a cut-link . . . . . . . . . . . 5 62 3.3. Using Different Groups to identify MRTs . . . . . . . . . 5 63 4. Local Protection . . . . . . . . . . . . . . . . . . . . . . . 5 64 4.1. PLR Replication . . . . . . . . . . . . . . . . . . . . . 6 65 4.1.1. PLR Behavior . . . . . . . . . . . . . . . . . . . . . 6 66 4.1.2. Unicast convergence during PLR Replication . . . . . . 7 67 4.1.3. MP Behavior . . . . . . . . . . . . . . . . . . . . . 7 68 4.1.4. Downstream Routers from the MP . . . . . . . . . . . . 8 69 4.1.5. Protected Node Behavior . . . . . . . . . . . . . . . 8 70 4.2. MP-Initiated Alternate Trees . . . . . . . . . . . . . . . 8 71 4.2.1. Building the Backup Trees . . . . . . . . . . . . . . 9 72 4.2.2. PLR behavior . . . . . . . . . . . . . . . . . . . . . 10 73 4.2.3. MP behavior . . . . . . . . . . . . . . . . . . . . . 10 74 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 11 75 5.1. Hello Options . . . . . . . . . . . . . . . . . . . . . . 11 76 5.1.1. MRT Protection Capabilities . . . . . . . . . . . . . 11 77 5.1.2. MP ID For PLR Replication . . . . . . . . . . . . . . 12 78 5.2. Join Attributes . . . . . . . . . . . . . . . . . . . . . 12 79 5.2.1. Merge Point Attribute . . . . . . . . . . . . . . . . 12 80 5.2.2. MRT Backup Attribute . . . . . . . . . . . . . . . . . 13 81 5.2.3. Upstream Address Join Attribute . . . . . . . . . . . 15 82 5.3. Encoded-Source Address Changes . . . . . . . . . . . . . . 16 83 5.4. New PIM Message Types . . . . . . . . . . . . . . . . . . 17 84 5.4.1. Join Response . . . . . . . . . . . . . . . . . . . . 17 85 5.4.2. PIM Backup JoinPrunes . . . . . . . . . . . . . . . . 17 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 89 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 90 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 93 1. Introduction 95 This document specifies how to reduce traffic loss after network 96 failures by using Maximally Redundant Trees (MRTs). This can be 97 accomplished with Global Repair (aka Live-Live) or with Local Repair 98 (aka Fast Re-route). The tradeoffs and applicability for each method 99 of protection are discussed in the MRT Multicast architecture 100 [I-D.atlas-rtwg-mrt-mc-arch-00]. 102 With Global Repair, a multicast egress will send PIM Joins for the 103 same stream on multiple MRT topologies. The Global Repair specified 104 in this document is similar to [I-D.karan-mofrr]. This document 105 specifies how this can be accomplished using MRTs, however, providing 106 100% coverage without requiring any particular network topology. 108 Local Repair for Link or Node protection can also be used to protect 109 Multicast traffic. A Point of Local Repair (PLR) can replicate the 110 traffic to all Merge Points (MPs). In order to accomplish this, the 111 PLR must know the unicast destination of all MPs. Upon the failure, 112 the PLR will send the traffic to all MPs. 114 An alternative to PLR replication is for the MPs to join an alternate 115 tree to be used upon a network failure. For Node Protection, 116 additional signaling is required for the MPs to learn of the PLR. 117 Extensions are also needed to distinguish a backup Join and to signal 118 the additional information required to specify the particular 119 alternate tree. Upon a failure to the primary RPF interface, the MP 120 will forward traffic from the alternate tree. 122 2. Terminology 124 2-connected: A graph that has no cut-vertices. This is a graph 125 that requires two nodes to be removed before the network is 126 partitioned. 128 cut-link: A link whose removal partitions the network. A cut-link 129 by definition must be connected between two cut-vertices. If 130 there are multiple parallel links, then they are referred to as 131 cut-links in this document if removing the set of parallel links 132 would partition the network. 134 cut-vertex: A vertex whose removal partitions the network. 136 Maximally Redundant Trees (MRT): A pair of trees where the path 137 from any node X to the root R along the first tree and the path 138 from the same node X to the root along the second tree share the 139 minimum number of nodes and the minimum number of links. Each 140 such shared node is a cut-vertex. Any shared links are cut-links. 141 Any RT is an MRT but many MRTs are not RTs. 143 Maximally Redundant Multicast Trees (MRMT): A pair of multicast 144 trees built of the sub-set of MRTs that is needed to reach all 145 interested receivers. 147 network graph: A graph that reflects the network topology where all 148 links connect exactly two nodes and broadcast links have been 149 transformed into the standard pseudo-node representation. 151 Redundant Trees (RT): A pair of trees where the path from any node 152 X to the root R along the first tree is node-disjoint with the 153 path from the same node X to the root along the second tree. 154 These can be computed in 2-connected graphs. 156 Merge Point (MP): For local repair, a router at which the alternate 157 traffic rejoins the primary multicast tree. For global 158 protection, a router which receives traffic on multiple trees and 159 must decide which stream to forward on. 161 Point of Local Repair (PLR): The router that detects a local 162 failure and decides whether and when to forward traffic on 163 appropriate alternates. 165 MT-ID: Multi-topology identifier 167 Stream Selection: The process by which a router determines which of 168 the multiple primary multicast streams to accept and forward. The 169 router can decide on a packet-by-packet basis or simply per- 170 stream. This is done for global protection as described in 171 [I-D.karan-mofrr]. 173 MultiCast Egress (MCE): Multicast Egress, a node where the 174 multicast stream exists the current PIM domain. This is usually a 175 receiving router that may forward the multicast traffic towards 176 receivers based upon IGMP or other technology. 178 3. Global Protection (Live-Live) 180 In order to achieve Global Protection, traffic will flow through the 181 network through disjoint paths. A multicast egress (MCE) router will 182 trigger this traffic flow by sending PIM joins on two different 183 interfaces. The MRT algorithm will ensure that these joins travel 184 through maximally disjoint paths to the source. The egress router 185 must then forward a single stream along to its downstream members. 186 Any failure in the network to either stream can be repaired by this 187 egress router, since it is receiving the redundant stream. 189 Any router that is capable of supporting Global Repair with MRTs must 190 advertise the T bit in the MRT Protection Hello Option. 192 3.1. Egress Router Behavior 194 A multicast egress (MCE) router will join a multicast stream on both 195 the Blue and Red MRT. The MT-ID [RFC6420] of the MRT will be 196 included in the Join as a Join Attribute [RFC5384]. Traffic will 197 flow down both MRTs to the egress router to achieve redundancy. The 198 egress router will forward a single stream along to its downstream 199 interfaces. The techniques for this stream selection are described 200 in MoFRR [I-D.karan-mofrr]. 202 3.2. Limitation when a LAN is a cut-link 204 There is a limitation in end-to-end protection when, for a given S,G, 205 the MRTs converge on a single LAN with different upstream neighbors. 206 In this case, both upstream neighbors will be sending on the LAN, and 207 there is no distinguishing the data traffic for the different MRTs if 208 it is carried with the same S,G. The PIM Assert procedures will 209 select a single forwarding router on the LAN and the other router 210 will stop sending. This could cause the Assert Loser to prune back 211 the S,G. Therefore, traffic will flow on only one MRT between the 212 source and the downstream router on the LAN. 214 3.3. Using Different Groups to identify MRTs 216 There may be cases when different sources or groups are used to send 217 the same stream, as decribed in the MRT Multicast architecture 218 [I-D.atlas-rtwg-mrt-mc-arch-00]. In this case the egress router may 219 not need to perform the stream selection. However, it would be 220 desirable for the egress router to join the sources or groups on 221 different MRTS. The mechanism to perform group to MRT mapping is 222 outside the scope of this document. Once the egress router knows the 223 group to MRT mapping, then it will join for the S,G on the particular 224 tree by including the MT-ID for the MRT in the Join message. In this 225 case, the streams can travel across the same LAN without the issues 226 described above. 228 4. Local Protection 230 Local Protection can protect either a link or node, and this will be 231 determined on a per flow basis. Two extra bits will be used from the 232 Encoded-Source Address in the Join-Prune messages to indicate whether 233 the source in the Join/Prune should have link or node protection. 235 Each router will advertise in its MRT Protection Hello Options 236 whether it is capable of performing Link or Node protection. 238 Two methods of Local Protection are discussed in this document. The 239 first method is when the PLR sends the traffic to be protected to all 240 Merge Points. Also, there is a second method to reduce the 241 replication burden on the PLR. With this method, alternate multicast 242 trees are built from the MPs to the PLR. These methods are described 243 in subsequent sections. 245 4.1. PLR Replication 247 At a PLR, each S,G flow will have a set of downstream interfaces and 248 a set of MPs for each downstream interface. There will be MPLS label 249 information learned for each MP. Upon a failure to the protected 250 link, the PLR will encapsulate and send the protected multicast 251 traffic to all MPs for that particlar (S,G,intf). The MP will, 252 therefore, receive the encapsulated data upon the failure and traffic 253 will resume to all of its downstream receivers. Once the PLR has 254 given the downstream routers sufficient time to recover from the 255 failure, it can stop sending the protected traffic, and prune 256 upstream, if required. 258 For the PLR to send the protected traffic upon a failure, it requires 259 the unicast address and an MPLS label (which may be Implicit Null) 260 for all the Merge Points. Each MP will advertise this information in 261 a new MP ID Hello Option. If link protection is used, this is 262 sufficient to reach the PLR. For node protection, the information 263 for all MPs will be sent to the PLR in a Join Attribute from the 264 upstream node of the MP (i.e., the Protected Node). 266 All routers that support this functionality will advertise the Link 267 or Node capability bits in the MRT Protection Hello Option. Any Node 268 that is capable of acting as a PLR will advertise the PLR-Replication 269 capable bit in the MRT Protection Hello Option. 271 4.1.1. PLR Behavior 273 The PLR will learn the location of all the MPs in the its Join 274 Messages (for node protection) and Hello Messages (for link 275 protection) that it receives from downstream routers. The Merge 276 Points will be kept per (S,G, downstream-interface). Upon a failure 277 to the protected interface, the PLR will encapsulate and forward the 278 multicast data to all the MPs for that downstream interface, and it 279 will start the Alternate-Tree-Protection-Timer. The Alternate-Tree- 280 Protection-Timer should be a configurable timer with a default of 10 281 seconds. The PLR will suppress the PIM Prunes from being sent while 282 the Protection-Timer is running. Once this timer expires, it will 283 stop sending the traffic to MPs, and it can send a Prune upstream if 284 required. 286 For a PLR to learn of all MPs, then Join Suppression must be disabled 287 on the interfaces between the MP and the PLR. In addition, the PLR 288 must accept all MP-ID Join Attributes that it receives from 289 downstream neighbors. 291 4.1.2. Unicast convergence during PLR Replication 293 Since it is likely for unicast routes to converge before PIM fully 294 converges, the PLR must still be able to route the traffic to all MPs 295 while unicast recovers from the original failure. The PLR must not 296 use stale forwarding information to reach the MPs for the protected 297 multicast traffic if unicast has already updated it forwarding 298 entries after the network event. An implementation should use the 299 same forwarding information that would be used to forward unicast 300 traffic to that destination. In this way, the PLR will be able to 301 forward traffic to the MPs. 303 4.1.3. MP Behavior 305 As is done today, the MP will forward traffic received on its normal 306 incoming interface. While the normal RPF interface is up, 307 encapulated alternate traffic will not be forwarded. If the RPF 308 interface fails, the MP will forward the encapulated alternate 309 traffic (if it is received with the correct encapsulation). This 310 procedure assumes that there is a method for the routers on both 311 sides of the protected link to determine if the link has gone down. 312 Such methods are outside the scope of this document. 314 After the incoming interface changes the MP will start the Alternate- 315 Tree-Protection-Timer. Once traffic arrives on the new incoming 316 interface or the Alternate-Tree-Protection-Timer expires, the Merge 317 Point will advertise the label for the new RPF interface, and it will 318 stop accepting the encapsulated alternate traffic. 320 The MP needs to know when it can release the label that it has 321 advertised and potentially re-use that label for another purpose. If 322 the interface goes down or the adjacency goes down on an interface 323 that the MP was advertising a label, it should wait (Protection- 324 Timeout + PLR_Propagation_Delay) seconds before re-using that label 325 for any other purpose. If the MP wants to change the label that is 326 was advertising on a particular interface, it should wait 327 (2*Hello_timer + 2*JoinPrune_Timer) before re-using the old label. 329 4.1.4. Downstream Routers from the MP 331 Some make-before-break techniques must be used on routers downstream 332 from the failure to ensure that traffic is not discarded once these 333 routers learn of the unicast change. For example, if a downstream 334 router, upon a unicast route change, prunes itself off its old RPF 335 interface and discards traffic until the new tree is formed back to 336 the source, then there will be end-to-end loss. The work that the 337 upstream routers did to repair the local failure will be wasted since 338 the downstream router is going to discard flowing traffic. The make- 339 before-breaks procedures needed on the downstream router is outside 340 the scope of this document. 342 4.1.5. Protected Node Behavior 344 For Node Protection, the MP will be one hop away from the Protected 345 Node and two hops away from the PLR. In this case, there may be 346 multiple next-next-hops to advertise as Merge Points in the Join 347 Attribute. The Protected Node will learn the downstream members and 348 it will gather the MP information from each downstream neighbor's 349 Merge Point Hello Options. For each Merge Point in the downstream 350 list, the Protected Node will include a Merge Point Join Attribute in 351 the Join that is sent upstream to the PLR. The Merge Point 352 information may change for a route entry before the JoinPrune would 353 normally be updated or refreshed to the PLR. Upon a change to the 354 next-next hop list, the router can send a triggered JoinPrune with 355 the updated Join Attribute, or it can wait for the next periodic 356 refresh. It would be a tradeoff of increased control messages 357 against a window of being unprotected. For a PLR to learn of all 358 MPs, then Join Suppression must be disabled on the interfaces between 359 the MP and the PLR. 361 4.2. MP-Initiated Alternate Trees 363 In order to reduce the load of replication to all Merge Points on the 364 PLR, alternate trees can be signaled from the MP to the PLR. The MP 365 needs to learn the address of the PLR and then signal the Join 366 towards the PLR, avoiding the node or link that is to be protected. 367 An alternate multicast tree is formed from the MP to the PLR, 368 avoiding the Protected Node/Link. Upon the failure, the PLR will use 369 this alternate tree to forward the data to all MPs. The MP can prune 370 itself off the alternate tree once it reconverges after the failure, 371 and no longer needs the alternate tree to the given PLR. 373 Any node that is capable of supporting MP-initiated Backup Trees must 374 set the Backup-Join capable bit, the Join-Response Capable bit, and 375 at least one of the node protection or link protection capable bits 376 in the MRT Protection Hello Option. The PLR needs to advertise an 377 Interface Identifier in the Interface Identifier Hello Option as 378 specified in [RFC6395]. The Router Identifier of this message may be 379 set to 0. 381 4.2.1. Building the Backup Trees 383 The MP will send the Join to it upstream neighbor and indicate in the 384 Join that it wants to do Node Protection or Link Protection. If Link 385 Protection is used then the MP has the address and interface id (from 386 the Interface Identifier Hello Option) of the PLR . If node 387 Protection is used, then the upstream node of the MP is the Protected 388 Node. If the MP supports Join Responses, as advertised in the MRT 389 Protection Hello Option, then the Protected Node must send a Join 390 Response to the MP. This Join Response has the same format as the 391 JoinPrune. For each source that requires node protection, the 392 Protected Node will include an Upstream Address Join Attribute with 393 the address of the PLR and the interface id advertised in the 394 Interface Identifier Hello Option of the RPF interface towards the 395 PLR. 397 PIM will consult the MRIB to obtain the the alternate upstream 398 neighbor towards the PLR, given the node or link that it is trying to 399 avoid. The MP will send a Backup Join to to this alternate upstream 400 neighbor and it will include a MRT Backup Join Attribute. The Backup 401 MRT Join attribute contains the PLR, the Protected-Node, the 402 Protected-Link, and the MPLS label. There will be a unique MPLS 403 label per backup tree. Additionally, the MP will include a MT-ID 404 Join Attribute [RFC6420] in the Backup Join indicating the MRT that 405 it expects to use to reach the PLR, avoiding the Protected-Node. 407 The Backup Join state must be maintained per (S,G,PLR,Protected- 408 Node,Protected Interface). If there is at least one downstream 409 receiver for a given per (S,G,PLR,Protected-Node,Protected 410 Interface), and the Join state is for the same MRT that this router 411 would use to reach the PLR, avoiding the Protected-Node, then this 412 router should propagate its Join upstream. The MRT of the downstream 413 receivers should match this router's MRT to reach the PLR, except 414 during transition events. If the MRTs are different, then the router 415 will wait until it converges or waits until it receives a new Backup 416 Join, indicating the correct MRT. 418 Once the last downstream receiver prunes from the (S,G,PLR,Protected- 419 Node,Protected Interface), then the router should Prune upstream. 420 Each router will propagate the same PLR, protected-node, and protect- 421 link info in the Backup MRT Join Attribute that it sends upstream. 422 Each router will also advertise a label in the Backup MRT Join 423 Attribute. The router will do a PLR, Protected-Node, Protected-link 424 lookup to label lookup to determine the label that it should use. 426 How this mapping is performed is outside the scope of this document. 428 Join Suppression is only allowed if a downstream router detects 429 another Backup Join for the same (S,G,PLR,Protected-Node,Protected- 430 Interface,label). Otherwise the downstream router must not suppress 431 its own Backup Join. 433 The S,G in the Backup Join can be wildcard sources and groups. For 434 example, if a MP wants to protect all multicast groups, then it will 435 set the Source to 0/0 and the Group to 224/4. The MP can also 436 specify more specific S,G's in the Backup Join. For each S,G that 437 needs to be protected in upon a failure, the PLR will match the S,G 438 to the most specific backup Join entry when determining the MPs. 439 Thus, The MPs must all be in agreement if a more specific backup Join 440 is going to be signaled for a particular S,G. This would be 441 accomplished, most likely, with consistent configuration on each of 442 the MPs. 444 4.2.2. PLR behavior 446 Upon a failure to the downstream interface, the PLR will send traffic 447 on the Alternate Tree that is protecting this interface, and it will 448 start the Alternate-Tree-Protection-Timer for the S,G. The PLR will 449 not Prune back on its upstream, even if this is the last interface in 450 the outgoing list, while the Alternate-Tree-Protection-Timer is 451 running. If all the downstream members of the Protection Tree Prune 452 themselves, then the PLR can expire the Alternate-Tree-Protection- 453 Timer. Once this timer expires, then the PLR will stop sending 454 traffic on the Alternate Tree, and the PLR can Prune upstream, if 455 appropriate. 457 4.2.3. MP behavior 459 As is done today, the MP will forward traffic received on its normal 460 incoming interface. While the normal RPF interface is up, traffic 461 from the alternate tree will not be forwarded. If the RPF interface 462 fails, the MP will forward the encapsulated alternate traffic (if it 463 is received with the correct label). For a given interface, there 464 may be multiple backup trees that are using that interface. The 465 traffic for each of these backup trees must be programmed for 466 forwarding upon the link failure. 468 After the incoming interface changes the MP will start the Alternate- 469 Tree-Protection-Timer. Once traffic arrives on the new incoming 470 interface or the Alternate-Tree-Protection-Timer expires, the Merge 471 Point will advertise the label for the new RPF interface, and it will 472 stop accepting the encapsulated alternate traffic. The MP can then 473 prune the old alternate Tree for the previous PLR, Protected-Node, 474 and protected Link. The MP will learn the new PLR, Protection Node, 475 and Protected Link from its upstream node and send a Backup Join to 476 the appropriate upstream neighbor. 478 5. Packet Formats 480 5.1. Hello Options 482 5.1.1. MRT Protection Capabilities 484 0 1 2 3 485 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 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Type = TBD | Length = 4 | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Reserved |P|T|R|B|L|N| 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 MRT Protection Hello Option Format 494 Type: TBD. 496 Length: 4 498 Value: 500 Reserved: Sent with 0, ignored on receipt 502 P: PLR Replication capable. This bit is set if a router is 503 capable of acting as a PLR-replicating router, as described in 504 this document. This router must also be capable of receiving a 505 Merge Point Join Attribute. 507 T: MRT Topology Capable. This bit is set if the router is 508 capable of understanding MRT topology IDs sent in the MT-ID 509 Join Attribute [RFC5384], as defined in this document. 511 R: Join Response Capable. This bit is set if the Router is 512 capable of sending and receiving Join Responses and Upstream 513 Address Join Attributes, as defined in this document. 515 B: Backup-Join Capable. This bit is set if the router is 516 capable of sending Backup Joins and MRT Backup Join Attribute, 517 as defined in this document. 519 L: Link Protection Capable. This bit is set if the router is 520 capable of performing Link Protection, as defined in this 521 document. 523 N: Node Protection. This bit is set if the router is capable 524 of performing Node Protection, as defined in this document. 526 5.1.2. MP ID For PLR Replication 528 The following Hello option is used for a Merge Point to advertise its 529 address label. 531 0 1 2 3 532 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 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Type = TBD | Length | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | MP ID | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Reserved | Label | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 MP ID Hello Option Format 543 Type: TBD. 545 Length: variable 547 MP ID: The Encoded-Unicast Address for the Merge Point 549 Reserved: 12 bits of reserved sent with 0. Ignored on receipt. 551 Label: 20 bit Label to be used for traffic that is being protected 553 5.2. Join Attributes 555 5.2.1. Merge Point Attribute 557 The following Join attribute is used for node protection, when the 558 Protected-Node needs to signal the Merge Point information to the 559 PLR. There will be a separate Merge Point Attribute for each Merge 560 Point being advertised for the source. This attribute should only be 561 sent to routers that are PLR-Replication capable, as advertised in 562 the MRT Protection Hello Option. 564 0 1 2 3 565 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 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 |F|E| Type | Length | Reserved | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Reserved | label | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | MP | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 Merge Point Join Attribute 576 F-bit: This bit will be clear as this is a non-transitive 577 attribute. 579 E-bit: As defined in [RFC5384] 581 Type: TBD 583 Length field: variable 585 Value: 587 Reserved: Sent with zero, ignored on receipt 589 label: the MPLS label associated with this MP 591 MP: The encoded-Unicast addresses of the Merge Point 593 5.2.2. MRT Backup Attribute 595 The Join attribute is included with each source in the Backup Join 596 message 597 0 1 2 3 598 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 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 |F|E| Type | Length | Reserved | # labels | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | PLR | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Protected Node | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Interface ID | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | reserved | label1 | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | . | 611 | . | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | reserved | labeln | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 MRT Backup Join Attribute Format 618 F-bit: This bit will be clear as this is a non-transitive 619 attribute. 621 E-bit: As defined in [RFC5384] 623 Type: TBD 625 Length field: the length of the value field. 627 Value: 629 Reserved: Sent with 0, ignored on receipt 631 # labels: number of labels included in this message 633 PLR: Encoded-Unicast Address of PLR. 635 Protected Node: Encoded-Unicast Address of the node which is 636 being protected. For Link Protection, this is the address of 637 the MP 639 Interface ID: a 32-bit identifier of the interface that 640 connects the PLR to the Protected Node. 642 Labels: MPLS labels to be used when sending traffic on the 643 backup 645 5.2.3. Upstream Address Join Attribute 647 This Join attribute is used with MP-initiated node protection to 648 signal the PLR address from the Protected Node to the MP. If a 649 router advertises itself capable of capable of handling Join 650 Responses in the MRT Protection Hello Option, then it MUST be capable 651 of receiving this Join Attribute 653 0 1 2 3 654 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 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 |F|E| Type | Length | Reserved | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | Upstream Address | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | Upstream Interface Id | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 Upstream Address Join Attribute Format 665 F-bit: This bit will be clear as this is a non-transitive 666 attribute. 668 E-bit: End of Attributes. If this bit is set, then this is the 669 last Join Attribute appearing in this Encoded-Source Address 670 field. 672 Type: TBD 674 Length field: the length of the value 676 Value: 678 Reserved: set to all 0's when sent. Ignored on receipt 680 Upstream Address: Encoded-Unicast Address of Upstream Address 681 of the Router sending this Join Attribute. 683 Upstream Link Id: The Interface Id of the PLR 685 5.3. Encoded-Source Address Changes 687 To indicate for a particular flow advertised in the JoinPrune message 688 should have node or link protection, a bit in the Encoded-Source 689 Address will be used. These bits are taken from the available 690 Reserved field of the Encoded-Source Address. These bits should only 691 be set to an upstream router that advertises the link or node 692 capability in the MRT Protection Hello Option. 694 0 1 2 3 695 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 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | Addr Family | Encoding Type |Rsvd |L|N|S|W|R| Mask Len | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | Source Address 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 702 Encoded-Source Address 704 Addr Family: As specified in [RFC4601] 706 Encoding Type: As specified in [RFC4601] 708 Rsvd: Transmitted as zero, ignored on receipt. 710 L Link protection requested for this source 712 N Node protection requested for this source 714 S As specified in [RFC4601] 716 W As specified in [RFC4601] 718 R As specified in [RFC4601] 720 Mask Len: As specified in [RFC4601] 722 Source Address: As specified in [RFC4601] 724 5.4. New PIM Message Types 726 5.4.1. Join Response 728 The Join Response message is identical to the JoinPrune message 729 except the type field is TBD. The Join Response may contain 730 additional Join Attributes. A router must not send a Join Response 731 to an neighbor unless it has advertised this capability in the MRT 732 Local Protection Hello Option. 734 5.4.2. PIM Backup JoinPrunes 736 The Backup JoinPrune Response message is identical to the JoinPrune 737 message except a new PIM type will be allocated. A router must not 738 send a Backup JoinPrune to an upstream neighbor unless it has 739 advertised this capability in the MRT Local Protection Hello Option. 741 6. IANA Considerations 743 A new PIM Hello Option type is requested to assign to the MRT 744 Protection Hello Option and the MP ID Hello Option 746 A new PIM type is requested for the Join Response and Backup Join/ 747 Prune messages. 749 A new PIM Join Attribute Types is requested for the Merge Point Join 750 Attribute, Upstream Address Join Attribute, and MRT Backup Join 751 Attribute 753 7. Security Considerations 755 There are no security considerations for this design other than what 756 is already in the main PIM specification [RFC4601] . 758 8. References 760 8.1. Normative References 762 [I-D.karan-mofrr] 763 Karan, A., Filsfils, C., Farinacci, D., Decraene, B., 764 Leymann, N., and W. Henderickx, "Multicast only Fast Re- 765 Route", draft-karan-mofrr-02 (work in progress), 766 March 2012. 768 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 769 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 770 Protocol Specification (Revised)", RFC 4601, August 2006. 772 [RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol 773 Independent Multicast (PIM) Join Attribute Format", 774 RFC 5384, November 2008. 776 [RFC6395] Gulrajani, S. and S. Venaas, "An Interface Identifier (ID) 777 Hello Option for PIM", RFC 6395, October 2011. 779 [RFC6420] Cai, Y. and H. Ou, "PIM Multi-Topology ID (MT-ID) Join 780 Attribute", RFC 6420, November 2011. 782 8.2. Informative References 784 [I-D.atlas-rtwg-mrt-mc-arch-00] 785 Atlas, A., Kebler, R., Wijnands, IJ., and G. Enyedi, "An 786 Architecture for Multicast Protection Using Maximally 787 Redundant Trees", atlas-rtwg-mrt-mc-arch-00 (work in 788 progress), March 2012. 790 [I-D.ietf-rtgwg-mrt-frr-architecture] 791 Atlas, A., Kebler, R., Envedi, G., Csaszar, A., 792 Konstantynowicz, M., White, R., and M. Shand, "An 793 Architecture for IP/LDP Fast-Reroute Using Maximally 794 Redundant Trees", draft-ietf-rtgwg-mrt-frr-architecture-01 795 (work in progress), March 2012. 797 Authors' Addresses 799 Robert Kebler (editor) 800 Juniper Networks 801 10 Technology Park Drive 802 Westford, MA 01886 803 USA 805 Email: rkebler@juniper.net 807 Alia Atlas 808 Juniper Networks 809 10 Technology Park Drive 810 Westford, MA 01886 811 USA 813 Email: akatlas@juniper.net 814 Naiming Shen 815 Cisco Systems, Inc. 816 170 W. Tasman Drive 817 San Jose, CA 95134 818 USA 820 Email: naiming@cisco.com 822 Yiqun Cai 823 Microsoft 824 La Avenida 825 Mountain View, CA 94043 826 USA 828 Email: yiqunc@microsoft.com