idnits 2.17.00 (12 Aug 2021) /tmp/idnits47212/draft-wijnands-rtgwg-mcast-frr-tn-01.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** 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 201: '...cal failure of its primary UMH it MUST...' RFC 2119 keyword, line 227: '...lain interaction SHOULD be avoided to ...' RFC 2119 keyword, line 239: '...he secondary UMH MUST become the new p...' RFC 2119 keyword, line 240: '... old primary MUST become the secon...' RFC 2119 keyword, line 246: '...e tree, a new DTN notification MUST be...' (21 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The JM sent to the secondary UMH includes an identifier to indicate the upstream node MUST not forward packets down this branch of the tree. The identifier is TBD. The mechanism to join a secondary path is identical to what the MRT and MoFRR drafts describe, i.e. a Repair Node simply sends a secondary JM through another UMH (on another topology, in case of MRT). If a node receives a JM without a blocking identifier for an OIF that previously was in blocking mode, the blocking mode is reset and the node stats forwarding out of this interface. If this node joined the tree in blocking mode further upstream, a new JM MUST be originated to reset the blocking state further upstream. -- The document date (July 8, 2013) is 3239 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) == Missing Reference: 'RFC3232' is mentioned on line 518, but not defined == Missing Reference: 'NTP' is mentioned on line 588, but not defined ** Downref: Normative reference to an Informational draft: draft-karan-mofrr (ref. 'I-D.karan-mofrr') == Outdated reference: A later version (-02) exists of draft-atlas-rtgwg-mrt-mc-arch-01 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing Working Group IJ. Wijnands, Ed. 3 Internet-Draft L. De Ghein 4 Intended status: Standards Track Cisco 5 Expires: January 9, 2014 G. Enyedi, Ed. 6 A. Csaszar 7 J. Tantsura 8 Ericsson 9 July 8, 2013 11 Tree Notification to Improve Multicast Fast Reroute 12 draft-wijnands-rtgwg-mcast-frr-tn-01 14 Abstract 16 This draft proposes dataplane triggered Tree Notifications to support 17 multicast fast reroute for PIM and mLDP. These Tree Notifications 18 are initiated by a node detecting the failure to a Repair Node 19 downstream. A Repair Node is a node that has a pre-built backup path 20 that can circumvent the failure. Using this mechanism, a Repair Node 21 has the ability to learn about non-local failures quickly without 22 having to wait for the IGP to convergence. This draft also covers an 23 optional method to avoid bandwidth usage on the pre-built backup 24 path. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 9, 2014. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Terminology and Definitions . . . . . . . . . . . . . . . . . 3 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Improving non-local failures . . . . . . . . . . . . . . . . . 4 63 3.1. Downstream Tree Notifications . . . . . . . . . . . . . . 5 64 3.2. DTN processing logic . . . . . . . . . . . . . . . . . . . 6 65 3.3. Repair Node discovery . . . . . . . . . . . . . . . . . . 8 66 3.3.1. Repair Node Information item . . . . . . . . . . . . . 8 67 3.4. Reduce the bandwidth consumption in networks with fast 68 failover response times . . . . . . . . . . . . . . . . . 8 69 3.4.1. Joining a secondary tree in blocking mode . . . . . . 9 70 3.4.2. Upstream Tree Notifications . . . . . . . . . . . . . 10 71 3.5. MRT/MCI-Only Mode . . . . . . . . . . . . . . . . . . . . 10 72 3.6. TN Authentication . . . . . . . . . . . . . . . . . . . . 11 73 3.7. The TN Packet . . . . . . . . . . . . . . . . . . . . . . 11 74 3.7.1. TN Packet Format . . . . . . . . . . . . . . . . . . . 11 75 3.7.1.1. TN TimeStamp TLV Format . . . . . . . . . . . . . 13 76 3.7.1.2. TN Signature TLV Format . . . . . . . . . . . . . 14 77 4. PIM Specific TN Components . . . . . . . . . . . . . . . . . . 15 78 4.1. RNI item in PIM Join Message . . . . . . . . . . . . . . . 15 79 4.2. Tree Information Item . . . . . . . . . . . . . . . . . . 16 80 4.3. Incremental deployment . . . . . . . . . . . . . . . . . . 18 81 5. mLDP Specific TN Components . . . . . . . . . . . . . . . . . 18 82 5.1. RNI item in mLDP Label Mapping . . . . . . . . . . . . . . 18 83 5.2. Tree Information Item . . . . . . . . . . . . . . . . . . 20 84 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 88 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 89 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 92 1. Terminology and Definitions 94 MoFRR : Multicast only Fast Re-Route. 96 LFA : Loop Free Alternate. 98 mLDP : Multi-point Label Distribution Protocol. 100 PIM : Protocol Independent Multicast. 102 UMH : Upstream Multicast Hop, a candidate next-hop that can be used 103 to reach the root of the tree. 105 tree : Either a PIM (S,G)/(*,G) tree or a mLDP P2MP or MP2MP LSP. 107 OIF : Outgoing InterFace, an interface used to forward multicast 108 packets down the tree towards the receivers. Either a PIM 109 (S,G)/(*,G) tree or a mLDP P2MP or MP2MP LSP. 111 IIF : Incoming InterFace, an interface where multicast traffic is 112 received by a router. 114 MCE : MultiCast Egress, the last node where the multicast stream 115 exits the current transport technology (MPLS-mLDP or IP-PIM) 116 domain or administrative domain. This maybe the router attached 117 to a multicast receiver. 119 MCI : MultiCast Ingress, the node where the multicast stream enters 120 the current transport technology (MPLS-mLDP or IP-PIM) domain. 121 This maybe the router attached to the multicast source. 123 DTN : Downstream Tree Notification. 125 UTN : Upstream Tree Notification. 127 TN : Tree Notification, Upstream or Downstream 129 Repair Node : A node that can circumvent the failure. 131 JM : Join Message, the message used to join to a multicast tree, 132 i.e. to build up the tree. In PIM, this is a JOIN message, while 133 in mLDP this corresponds to a Label Mapping message. 135 MRT : Maximally Redundant Trees. 137 Repair Node : The node performing a dual-join to the tree through 138 two different UMHs. Sometimes also called as dual-joining node or 139 merging node (it merges the secondary and primary tree). 141 RNI : The Repair Node Information is an item included in the TN 142 which holds the nessesary repair information when the TN is send 143 to the Repair Node. 145 Branching Node : A node, (i) which is considered as being on the 146 primary tree by its immediate UMH and (ii) which has at least one 147 OIF on the secondary tree installed for a multicast tree. 149 2. Introduction 151 Both [I-D.karan-mofrr] and [I-D.atlas-rtgwg-mrt-mc-arch] describe 152 "live-live" multicast protection, where a node joins a tree via 153 different candidate upstream multicast hops (UMH). With MoFRR the 154 list of candidate UMHs can come from either ECMP or Loop Free 155 Alternate (LFA) paths towards the MultiCast Ingress node (MCI). With 156 MRT, the candidate UMHs are determined by looking up the MCI in two 157 different (Red and Blue) topologies. In either case, the multicast 158 traffic is simultaneously received over different paths/topologies 159 for the same tree. The node 'dual-joining' the tree needs a 160 mechanism to prevent duplicate packets being forwarding to the end 161 user. For that reason a node 'dual-joining' the tree only accepts 162 packets from one of the UMHs at the time. Which UMH is preferred is 163 a local decision that can be based on IGP reachability, link status, 164 BFD, traffic flow monitoring, etc... 166 Should the node detect a local failure on the primary UMH, the node 167 has an instantly available secondary UMH that it can switch to, 168 simply by unblocking the secondary UMH. The dual-joining node is 169 also called Repair Node in the following. 171 This draft attempts to improve these solutions by: 173 o Improving fail-over time and the reliability of failure detection 174 for non-local failures; and 176 o Reducing the bandwidth consumption in a network with fast failover 177 response times. 179 3. Improving non-local failures 181 If a failure is not local and happens further upstream, the dual- 182 joining node needs a fast mechanism (i) to detect the upstream 183 failure and (ii) to learn that other upstream nodes cannot circumvent 184 the failure. Existing methods based on traffic monitoring are 185 limited in scope and work best with a steady state packet flow. 186 Therefore, we propose a method which can trigger the unblocking the 187 secondary UMH independently of the packet flow. 189 Figure 1 shows an example. Consider that, e.g., node A goes down. 190 Nodes C, D and E cannot detect that locally, so they need to resort 191 to other means. After detecting the failure, node C should not 192 change to its secondary UMH (node J) as it won't help for the failure 193 of A. Node D, on the other hand, will have to unblock its secondary 194 UMH (node I). Yet again, with MoFRR, node E should not unblock its 195 secondary UMH (node K): (i) this won't help in resolving the failure 196 of node A, and (ii) one of its upstream nodes (node D in this case) 197 will be able to restore the stream with a fail-over action. 199 3.1. Downstream Tree Notifications 201 When a node detects a local failure of its primary UMH it MUST 202 originate a Downstream Tree Notification (DTN) to all the Repair 203 Nodes directly below it in the multicast tree. The method of 204 discovering such nodes is described in Section 3.3. When a Repair 205 Node receives a DTN containing the primary UMH of the node, it must 206 switch to the secondary UMH. 208 DTN packets are sent via unicast to the Repair Node. The packet may 209 be forwarded using any transport that is available (MPLS or IP) to 210 reach the destination. The IP precedence in the IP header should 211 have a value of 6 (Internetwork Control). The EXP field (Traffic 212 Class field) in the MPLS header should have a value of 6. The DTN 213 packets are identified by a well known port number (to be allocated). 214 Using a well-known port number it is easy for the Repair Node to 215 identify the DTN packet and invoke the procedures as described in 216 this draft. We are proposing to allocate different port numbers for 217 PIM and MDLP since it will be easier to dispatch the packet to the 218 right process dealing with this request. 220 When a router detects a local failure, it should sent out the DTN 221 packet to the Repair Node as fast as possible. The sooner the Repair 222 Node gets the packet, the sooner the traffic can be restored. It is 223 recommended that the DTN packet is pre-created and originated from 224 the data-plain. The same is true for receiving the DTN packet on the 225 Repair Node, the faster it can be processed, the faster the traffic 226 is restored. For both forwarding and processing the DTN, control- 227 plain interaction SHOULD be avoided to get the best failover results. 229 3.2. DTN processing logic 231 When a DTN packet is received on the Repair Node it must determine 232 which tree and UMH the notification is for. The information encoded 233 in the DTN is specific for the type of tree being used, i.e. PIM vs 234 mLDP. For details on the specific encoding see Section 4 and 235 Section 5 for the details. Once the Repair node has determined the 236 tree and the UMH, the following rules are use for processing the DTN. 238 1. If the UMH encoded in the DTN packet is the primary UMH in the 239 tree, the secondary UMH MUST become the new primary UMH and the 240 old primary MUST become the secondary. 242 2. If the UMH encoded in the DTN packet is the secondary UMH in the 243 tree, no action needs to be taken. 245 3. If a DTN notification has been received on both the primary and 246 secondary UMH in the tree, a new DTN notification MUST be 247 originated to the Repair Node(s) downstream from this node. 249 In order for the Repair Node to determine that a DTN notification was 250 received for both the primary and secondary UMH, it must store the 251 fact a DTN was received for a particular UMH. 253 Consider the example in Figure 1 below. MCI is the root of a tree 254 that includes the nodes as follows (based on the primary UMH). 256 ->F->G->H->I 257 MCI 258 ->A->B->C->D->E 260 Node C, D and E are candidate Repair Nodes. 262 -- Primary UMH 263 ++ Secondary UMH 265 +-+ +-+ +-+ +-+ 266 |F|+++|G|+++|H|+++|I| 267 +-+ +-+ +-+ +-+ 268 + + 269 + + 270 +---+ +-+ +-+ +-+ +-+ +-+ 271 Source ---|MCI|------|A|---|B|---|C|---|D|---|E|--- Receiver 272 +---+ +-+ +-+ +-+ +-+ +-+ 273 + + + + 274 + + + + 275 +-+ +-+ 276 |J| |K| 277 +-+ +-+ 279 Figure 1: Remote failure example 281 Suppose that the link between node A and B failed, B is directly 282 connected and will detect the failure locally. In this case, node B 283 is the only node that detects the failure and will originate a DTN to 284 its downstream repair node C. Node C will receive the DTN for the UMH 285 that is the primary UMH. Following rule 1 (Section 3.2), node C will 286 make the backup UHM the new primary. No further action is needed 287 because C has repaired the tree via node J. Note, J would not have 288 sent a DTN to node C because J is not directly connected to the 289 failing link. 291 Suppose that node A fails, B and J are directly connected and detect 292 the failure locally. A DTN packet is triggered to first downstream 293 repair node of A, which is node C. Node C is an unusable Repair Node 294 because it will receive DTN for both the primary UMH (from B) and the 295 secondary UMH (from J). Following rule 3 (Section 3.2), C can't 296 repair the tree and must sent a new DTN packet towards the Repair 297 Nodes of C, which are D, on the primary path, and E, on the secondary 298 path. 300 Suppose that the link between A and the MCI failed. Node A is 301 directly connected to the failure and will trigger a DTN packet to 302 its downstream repair node(s). In this case, node A has learned 303 about the downstream repair node C twice, the primary UMH (via node 304 B) and secondary UMH (via node J). Node C will therefore sent a DTN 305 packet including both the primary and secondary UMH to node C (see 306 Section 3.7 for details on the encoding). Following rule 3 307 (Section 3.2), C can't repair the tree and must sent a new DTN packet 308 towards the Repair Nodes of C, which are D, on the primary path, and 309 E, on the secondary path. 311 The DTN packet that D received from C will match against the primary 312 UMH. Following rule 1, D will activate the backup path to I. The DTN 313 packet that E received from C will match against the backup UMH, 314 following rule 2, no action is taken. In the example one can see 315 that we recovered from the failure because node D started accepting 316 the data packets from node I and is forwarding them to node E. 318 3.3. Repair Node discovery 320 In example Figure 1 we wrote that nodes C, D and E are the repair 321 nodes. How does a node determine that it is a Repair Node? The rule 322 is straightforward, a node that is enabled to join two UMH's, one in 323 active the other in backup ([I-D.karan-mofrr]), is a repair node on 324 the tree. A Repair node has the ability to repair the tree for the 325 nodes upstream from this node. In order for the Repair Node to get 326 notified of upstream failures (ie DTN), the nodes upstream from the 327 Repair Node need to learn about it. 329 3.3.1. Repair Node Information item 331 A Repair Node MUST advertise its own address (either a router ID or 332 any directly connected address) and an UMH identifier to the nodes 333 upstream on the tree. This address and UMH are part of the RNI 334 (Repair Node Information) item that is included in the JM. The RNI 335 is carried hop by hop in the JM upstream. If a node along the path 336 is not a Repair Node, it will save the RNI and forward if further 337 upstream. If the node is Repair Node, it will save the RNI and 338 include its own RNI in the JM sent further upstream. If a Repair 339 Node changes one if its UMH's, it needs to trigger a new RNI to its 340 upstream node(s) to notify them of the changed UMH. If a RNI is 341 received and it does not match the saved RNI, the new RNI overrides 342 the old RNI and triggers a JM with the new RNI to its upstream 343 node(s). A RNI includes protocol specific information on how to 344 identify the tree and UMH, for that reason it is documented in the 345 protocol specific sections Section 4 and Section 5. 347 The Repair Node MAY include additional information in the RNI for 348 reasons of security and robustness, please see Section 3.6 and 349 Section 3.7.1. 351 3.4. Reduce the bandwidth consumption in networks with fast failover 352 response times 354 In some of networks, such as aggregation networks, bandwidth is more 355 sparse than, e.g., in core networks. Live-live multicast protection 356 results in more bandwidth consumption in the network as it 357 continuously pulls traffic on both trees. In such networks it is 358 relevant if the capacity serving backup purposes can be used, most of 359 the time, by best-effort or even by lower-than-best-effort traffic. 361 +---+ +-+ +-+ 362 |MCI|~~~~~~|A|---|B| 363 +---+ +-+ +-+ 364 \\ // 365 \\ // 366 +-+ 367 |C| 368 +-+ 370 Nodes A and B have receivers. Double lines show bandwidth 371 consumption that is superfluous when there is no failure in the 372 network. 374 Figure 2: Example for secondary segments occupying bandwidth in MoFRR 376 In live-standby mode the aim is that the secondary tree is not 377 forwarding multicast traffic as long as there is no failure. In 378 order to achive such a "live-standby" multicast protection the 379 following requirements must be met: 381 o Upsteam nodes block their OIF when they are part of a standby 382 tree. 384 o If all of the OIF's of the node are marked as blocking, the node 385 joins the tree in blocking mode further upstream. 387 o A procedure so that the upstream node can quickly unblock its OIF 388 and starts to forward. 390 3.4.1. Joining a secondary tree in blocking mode 392 The JM sent to the secondary UMH includes an identifier to indicate 393 the upstream node MUST not forward packets down this branch of the 394 tree. The identifier is TBD. The mechanism to join a secondary path 395 is identical to what the MRT and MoFRR drafts describe, i.e. a Repair 396 Node simply sends a secondary JM through another UMH (on another 397 topology, in case of MRT). If a node receives a JM without a 398 blocking identifier for an OIF that previously was in blocking mode, 399 the blocking mode is reset and the node stats forwarding out of this 400 interface. If this node joined the tree in blocking mode further 401 upstream, a new JM MUST be originated to reset the blocking state 402 further upstream. 404 3.4.2. Upstream Tree Notifications 406 In order to make an upstream node start forwarding on the backup path 407 quickly after a failure was detected on the primary UMH, we sent a 408 Upstream Tree Notification (UTN) to the upstream node on the backup 409 UMH. The failure on the primary UMH may be local or detected using a 410 DTN. The UTN received by the upstream node should be processed in 411 the data-plane and reset the blocking state of the OIF. If this node 412 also joined the tree in blocking mode upstream, a UTN has to be 413 forwarded further upstream. This procedure is repeated until we find 414 a node that is not in blocking mode or we reached the MCI. 416 When the upstream node resets the blocking mode in the data-plane, 417 the control plane will still have the blocking mode set. In order 418 for the control plane to get in sync with the data-plane, the node 419 that originated the UTN MUST also trigger a JM without blocking mode. 421 The upstream node receiving the UTN must be able to identify the tree 422 which the notification is sent for, as well as the downstream 423 interface it applies to. The information is encoded in a same RNI 424 item that is used for DTN packets. For details please see the 425 protocol specific sections Section 4 and Section 5. 427 Like DTN packets, UTN packets are sent via unicast to the upstream 428 node. 430 3.5. MRT/MCI-Only Mode 432 If each node in the network supports UTN and also all nodes support 433 MRT, the nodes may work in "MRT/MCI-only" mode. 435 In MRT/MCI-only mode, there is one single Repair Node for all 436 failures, the MCI. Other nodes MUST NOT consider themselves as 437 Repair Nodes. MRT ensures the necessary maximally disjoint secondary 438 tree up to the MCI, on a second topology. Only the MCI MUST keep its 439 OIFs corresponding to the secondary tree blocked. Similarly, only 440 MCEs MUST keep their secondary backup IIFs blocked. Any other nodes 441 MUST NOT block their (secondary) IIFs or OIFs. 443 In MRT/MCI-only mode, the UTNP MUST be forwarded directly to the MCI. 444 This mode enables that a node detecting a downstream failure of the 445 primary tree MAY send a UTNP upstream towards the source/MCI on the 446 primary tree. 448 If an UTNP is received by the MCI on the secondary topology in "MRT/ 449 MCI-only" mode, the MCI MUST unblock the OIF where the UTNP was 450 received. This activates a whole sub-tree of the secondary tree. 452 If an UTNP is received by the MCI on the primary topology in "MRT/ 453 MCI-only" mode, the MCI gets no information on which leg to activate 454 on the secondary tree, so it MUST activate (unblock) all secondary 455 legs. 457 3.6. TN Authentication 459 If a malicious attacker can reproduce the TN packet format, unwanted 460 reconvergence can be triggered. In order to avoid such attack, a TN 461 packet MAY contain a digital signature. Having authentication is 462 optional, it can be enabled or disabled in the network. If however 463 security is enabled, all the nodes must share the same secret key, 464 which they get either by configuration or from the multicast routing 465 protocol. Moreover, for protection against reply attacks, each TN 466 packet must contain a sequence number. 468 The sequence numbers in the network are not necessarily synchronised, 469 instead, each node can have its own. Sequence numbers can be 470 generated arbitrarily, it can be even some random value; the only 471 requirement is to create a new sequence number each time a 472 reconvergence was triggered due to a TN (i.e. the sequence number was 473 used). 475 The originator of the DTN packet MUST use the sequence number of the 476 Repair Node to create a TN signature TLV (see Section 3.7.1.2). For 477 UTN packet the sender MUST use its own sequence number, what it sent 478 previously to its UMH. The destination in this case must check 479 validity based on the sequence number of the sender. 481 A sequence number is learned from JM and part of the RNI. It is the 482 responsibility of multicast routing protocol to protect JM against 483 malicious change. 485 3.7. The TN Packet 487 3.7.1. TN Packet Format 489 A Tree Notification is an IPv4 or IPv6 UDP packet with the following 490 format. 492 0 1 2 3 493 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 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Version Nr | Address Family | Type | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Originator ID | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Sequence Number | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | TreeInfo Count | TreeInfo size | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | TreeInfo item - 1 | 504 ~ . ~ 505 | TreeInfo item - n | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | TN option TLVs ... | 508 . . 509 . . 510 . . 511 | | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 Version number: This is a 1 octet field encoding the version 515 number, currently 0. 517 Address Family: This is a 2 octet field encoding a value from 518 ADDRESS FAMILY NUMBERS in [RFC3232] that encodes the address 519 family for the Root Address of the tree. 521 Type: This is a 1 octet field encoding the message type, currently 522 two are defined; 524 Type 0: Downstream Tree Notification. 526 Type 1: Upstream Tree Notification. 528 Originator ID: 4 bytes long unique ID of the originator. That can 529 be some loopback IPv4 address if there is such, or can be set by 530 the operator. 532 Sequence Number: Number unique for each failure case. It is 533 recommend to start at 0, and to be increased by 1 each time a new 534 TN is originated. The Sequence number may differ at each node, 535 thus the sender and the receiver must know the same sequence 536 number. 538 TreeInfo count: 2 octet field encoding the number of TreeInfo items 539 includes. 541 TreeInfo size: 2 octet field encoding the number of octets use to 542 encode the TreeInfo's following. 544 TreeInfo item: The encoding of this field is protocol specific, see 545 Section 4 and Section 5. 547 TN option TLVs: TLVs (Type-Length-Value tuples) describing 548 additional options for TN packets. 550 The TLV's have the following format. 552 0 1 2 3 553 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 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Type | Length | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Value | 558 . . 559 . . 560 . . 561 | | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 Type: This is a 2 octet field encoding the type number of the TLV. 566 Length: This is a 2 octet field encoding the length of the Value in 567 octets. 569 Value: String of Length octets, to be interpreted as specified by 570 the Type field. 572 3.7.1.1. TN TimeStamp TLV Format 574 The TimeStamp is an optional TLV that MAY be included when the TN was 575 originated, it has the following format. 577 0 1 2 3 578 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 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Type = 0 | Length = 8 | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | TimeStamp Sent (seconds) | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | TimeStamp Sent (microseconds) | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 TimeStamp: The TimeStamp is the time-of-day (in seconds and 588 microseconds, according to the sender's clock) in NTP format [NTP] 589 when the Tree Notification is sent. 591 3.7.1.2. TN Signature TLV Format 593 TN Signature is an optional TLV, which protects the whole TNP 594 (including other TLVs) against attacks thus it must be the last TLV 595 if present. The signature is SHA-512 hash value. The input of the 596 hash function is as follows: 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Complete packet content without signature TLV | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Secret key | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 Signature input: The input of the hash function is the packet 605 extended with TN security key 607 The build up of the TLV is as follows: 609 0 1 2 3 610 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 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Type = 1 | Length = 64 | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Hash function result | 615 . . 616 . . 617 . . 618 | | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 Signature: SHA-512 signature protecting TN packets. 622 4. PIM Specific TN Components 624 In this section we are documenting the PIM specific data-structures 625 and procedures (if they are different from the generic procedures are 626 defined in this document). As described in this document, TN packets 627 are UDP/IP packets sent via unicast to its destination. The UDP port 628 number for PIM is set to the (to be) assigned IANA port number for 629 PIM-TN. 631 4.1. RNI item in PIM Join Message 633 As described previously, PIM must insert the RNI when sending a PIM 634 join to its UMH. The RNI includes its router ID, sequence number and 635 UMH Identifier. The UMH-ID can be locally unique identifier since 636 its has only local significance on the Repair Node. A good ID to use 637 would be the IP address of the interface associated with the UMH the 638 PIM join is sent to. The RNI is carried in the PIM Join as a new PIM 639 Attribute following [RFC5384]. The PIM RNI attribute has the 640 following format for IPv4. 642 0 1 2 3 643 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 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 |F|E| Type | Length | Sequence number | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Repair Node address | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | UMH-ID | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 F Forward if not understood. 654 E End of Attributes, following [RFC5384]. 656 Type: This 6 bit field should be assigned by IANA for TN specific 657 JOIN messages. 659 Length: Length = 10 octets. 661 Sequence number: 2 octets long field, describing the sequence 662 number of the sending Repair Node. 664 Repair Node address: The router ID of the Repair Node, in IPv4 665 address format. 667 UMH-ID: This is a 4 octet field encoding UMH identifier. This is 668 the IPv4 address of the interface associated with the UMH the PIM 669 join is sent to. 671 Figure 3: PIM IPv4 RNI attribute TLV 673 The PIM RNI attribute has the following format for IPv6. 675 0 1 2 3 676 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 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 |F|E| Type | Length | Sequence number | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | Repair Node address | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 ~ UMH-ID ~ 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 F Forward if not understood. 687 E End of Attributes, following [RFC5384]. 689 Type: This 6 bit field should be assigned by IANA for TN specific 690 JOIN messages. 692 Length: Length = 16 octets. 694 Sequence number: 2 octets long field, describing the sequence 695 number of the sending Repair Node. 697 Repair Node address: The router ID of the Repair Node, in IPv4 698 address format. 700 UMH-ID: This is a 16 octet field encoding UMH identifier. This is 701 the IPv6 address of the interface associated with the UMH the PIM 702 join is sent to. 704 Figure 4: PIM IPv6 RNI attribute TLV 706 4.2. Tree Information Item 708 A TN packet contains one or more TreeInfo items that allows a Merge 709 Node to idenfy which tree(s) and interface(s) are effected by the TN. 710 The same encoding is used for DTN and UTN packets. The PIM TreeInfo 711 items are defined for IPv4 and IPv6. Which version is to be included 712 in the TN packet depends on Address Family in the TN packet. The 713 UMH-ID included in the DTN MUST be taken from the RNI that was 714 signalled for that tree. The UMH-ID for UTN packets is the PIM 715 neighbor address for that tree. The TreeInfo item has the following 716 format: 718 0 1 2 3 719 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 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | IPv4 Source address | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | IPv4 group address | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | UMH-ID | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 Source Address: This is a 4 octet field encoding the IPv4 source 729 address of the tree. A source address of 0.0.0.0 means that this 730 TN relates to a (*,G) tree. 732 Group Address: This is a 4 octet field encoding the IPv4 group 733 address of the tree. 735 UMH-ID: This is a 4 octet field encoding UMH identifier. 737 Figure 5: PIM IPv4 TreeInfo item 739 0 1 2 3 740 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 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 ~ IPv6 Source address ~ 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 ~ IPv6 group address ~ 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 ~ UMH-ID ~ 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 Source Address: This is a 16 octet field encoding the IPv6 source 750 address of the tree. A source address of 0:0:0:0:0:0:0:0 means 751 that this TN relates to a (*,G) tree. 753 Group Address: This is a 16 octet field encoding the IPv6 group 754 address of the tree. 756 UMH-ID: This is a 16 octet field encoding UMH identifier. 758 Figure 6: PIM IPv6 TreeInfo item 760 4.3. Incremental deployment 762 Joins with a RNI can be forwarded through legacy nodes if the 763 Transitive Attribute (see [RFC5384]) has the F bit set to 1. It is 764 up to the network operator to determine this. The DTN functionality 765 can be deployed incrementally as long as the node detecting the 766 failure and Repair Nodes support it. 768 5. mLDP Specific TN Components 770 In this section we are documenting the mLDP specific data-structures 771 and procedures (if they are different from the generic procedures are 772 defined in this document). As described in this document, TN packets 773 are UDP/IP packets sent via unicast to its destination. The UDP port 774 number for mLDP is set to the (to be) assigned IANA port number for 775 mLDP-TN. 777 5.1. RNI item in mLDP Label Mapping 779 The RNI item for mLDP is encoded in a LDP MP Status TLV as documented 780 in [RFC6388] section 5. A new LDP MP Status Value Element is created 781 for this purpose and called the RNI Status. The RNI Status includes 782 the router ID, sequence number and UMH Identifier. The UMH-ID can be 783 locally unique identifier since its has only local significance on 784 the Repair node. For mLDP the value that MUST be used is the Local 785 Label associated with the UMH the mLDP Label Mapping is sent to. The 786 RNI status is carried in Label Mapping messages and has the following 787 format. 789 0 1 2 3 790 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 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | RNI | Length | Seq. Number . 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 . | IPv4 Repair Node address . 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 . | UMH-ID reserved | UMH-ID Label . 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 . | 799 +-+-+-+-+-+-+-+-+ 801 RNI Type: This 1 octet field assigned by IANA for RNI Status Value 802 Element Types. 804 Length: This is a 2 octet field, describing the length of the 805 Value, Length = 10 octets. 807 Sequence number: 2 octets long field, describing the sequence 808 number of the sending Repair Node. 810 IPv4 Repair Node address: The IPv4 address of the Repair Node. 812 UMH-ID reserved: 12 bit field, reserved. 814 UMH-ID Label: This is a 20 bit field encoding a Label as UMH 815 identifier. 817 Figure 7: mLDP RNI Status Value Element 819 0 1 2 3 820 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 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | RNI | Length | Status code | 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 MBB Type: Type 1 (to be assigned by IANA) 827 Length: 1 828 Status code: 1 = MBB request 830 2 = MBB ack 832 5.2. Tree Information Item 834 A TN packet contains one or more TreeInfo items that allows a Merge 835 Node to identify which tree(s) and interface(s) are effected by the 836 TN. The same encoding is used for DTN and UTN packets. Following 837 [RFC6388], mLDP will assign a unique Label to each upstream node per 838 MP-LSP. This label identifies the UMH AND the LSP. Since we are 839 using a label to identify the UMH and LSP, there is no need to define 840 a IPv4 and IPv6 specific encoding. The Label included in the DTN 841 MUST be taken from the RNI that was signalled for that tree. The 842 Label for UTN packets is the Local Label that was allocated for that 843 tree. The TreeInfo item has the following format: 845 0 1 2 3 846 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 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | Reserved | UMH-Label | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 Reserved: This is a 12 bits filed, set to zero on sending, ignored 852 when received. 854 UMH-Label: This is a 20 bit field encoding MPLS Label of the UMH. 856 Figure 8: mLDP TreeInfo item 858 6. Acknowledgements 860 The authors would like to thank Stefan Olofsson, Javed Asghar and 861 Greg Sheperd for their comments on the draft. 863 7. IANA Considerations 865 IANA is requested to allocate UDP port numbers to TN messages. One 866 port number for TN in IP/PIM context, and another one for MPLS/mLDP 867 context. The separation of UDP port numbers between IP and MPLS is 868 requested to prevent problems when a PIM multicast tree is 869 transported partly through an mLDP multicast tree. 871 IANA is requested to allocate a value from "PIM Join Attribute" to 872 make routers capable to advertisement their Tree Notification 873 capability. 875 IANA is requested to allocate a value from "PIM Join Attribute Types" 876 for TN's join command extra information. 878 A new IANA registry is needed for "TN option TLVs". This describes 879 the types of TLVs containing extra options for TN messages. 881 8. Security Considerations 883 Two types of security problems can be foreseen by the authors: 885 o Handling illegally injected TN packets 887 o Handling replay attacks (re-injecting previous TN messages) 889 o TN messages propagating outside an operator's domain 891 Illegal TN packets can be detected with authentication check. 892 Providing authentication for TN messages is described in Section 3.6. 893 Prevention of replay attacks needs authentication in combination with 894 sequence numbering, which is also described at the same section. 896 Preventing TN messages that travel inline with data packets MUST be 897 solved by nodes egressing the operator's domain. Solutions for IP 898 and MPLS are described in sections Section 4 and Section 5, 899 respectively. 901 9. References 903 9.1. Normative References 905 [I-D.karan-mofrr] 906 Karan, A., Filsfils, C., Farinacci, D., Decraene, B., 907 Leymann, N., and W. Henderickx, "Multicast only Fast Re- 908 Route", draft-karan-mofrr-02 (work in progress), 909 March 2012. 911 [RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol 912 Independent Multicast (PIM) Join Attribute Format", 913 RFC 5384, November 2008. 915 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 916 "Label Distribution Protocol Extensions for Point-to- 917 Multipoint and Multipoint-to-Multipoint Label Switched 918 Paths", RFC 6388, November 2011. 920 9.2. Informative References 922 [I-D.atlas-rtgwg-mrt-mc-arch] 923 Atlas, A., Kebler, R., Wijnands, I., Csaszar, A., and G. 924 Envedi, "An Architecture for Multicast Protection Using 925 Maximally Redundant Trees", 926 draft-atlas-rtgwg-mrt-mc-arch-01 (work in progress), 927 February 2013. 929 Authors' Addresses 931 IJsbrand Wijnands (editor) 932 Cisco 933 De kleetlaan 6a 934 Diegem, 1831 935 Belgium 937 Phone: 938 Email: ice@cisco.com 940 Luc De Ghein 941 Cisco 942 De kleetlaan 6a 943 Diegem, 1831 944 Belgium 946 Phone: 947 Email: ldeghein@cisco.com 949 Gabor Sandor Enyedi (editor) 950 Ericsson 951 Konyves Kalman Krt 11/B 952 Budapest, 1097 953 Hungary 955 Phone: 956 Email: Gabor.Sandor.Enyedi@ericsson.com 957 Andras Csaszar 958 Ericsson 959 Konyves Kalman Krt 11/B 960 Budapest, 1097 961 Hungary 963 Phone: 964 Email: Andras.Csaszar@ericsson.com 966 Jeff Tantsura 967 Ericsson 968 300 Holger Way 969 San Jose, California 95134 970 USA 972 Email: Jeff.Tantsura@ericsson.com