idnits 2.17.00 (12 Aug 2021) /tmp/idnits47048/draft-wijnands-rtgwg-mcast-frr-tn-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 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 206: '...lure of its primary UMH MUST originate...' RFC 2119 keyword, line 215: '...on time, the DTNP SHOULD be originated...' RFC 2119 keyword, line 223: '...eived from an UMH, the node MUST check...' RFC 2119 keyword, line 236: '... MUST not be forwarded, but the node...' RFC 2119 keyword, line 240: '...t the Repair Node and MUST forward the...' (41 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: Whenever a node receives a DTNP from its primary UMH and the node has a secondary UMH for which no DTNP had been received beforehand, this node could be a Repair Node, so unblocks its secondary UMH. The DTNP MUST not be forwarded, but the node has to store the fact that a DTNP has been received for the primary UMH for this multicast tree. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 15, 2012) is 3505 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: 'NTP' is mentioned on line 527, but not defined == Missing Reference: 'RFC4379' is mentioned on line 615, but not defined ** Obsolete undefined reference: RFC 4379 (Obsoleted by RFC 8029) == Unused Reference: 'I-D.ietf-rtgwg-mrt-frr-architecture' is defined on line 739, but no explicit reference was found in the text == Outdated reference: draft-ietf-mpls-mldp-hsmp has been published as RFC 7140 == Outdated reference: draft-ietf-rtgwg-mrt-frr-architecture has been published as RFC 7812 ** 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-00 Summary: 3 errors (**), 0 flaws (~~), 9 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 Cisco 4 Intended status: Standards Track A. Csaszar, Ed. 5 Expires: April 18, 2013 J. Tantsura 6 Ericsson 7 October 15, 2012 9 Tree Notification to Improve Multicast Fast Reroute 10 draft-wijnands-rtgwg-mcast-frr-tn-00 12 Abstract 14 This draft proposes using dataplane triggered notifications in order 15 to support multicast fast reroute methods in various ways. Sending 16 such notifications down the tree can be used to trigger fail-over in 17 nodes not adjacent to the failure. Sending such dataplane 18 notification up the tree can help to activate pre-built standby 19 backup tree segments. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 18, 2013. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 68 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Improving non-local failures . . . . . . . . . . . . . . . . . 5 70 3.1. Downstream Tree Notifications . . . . . . . . . . . . . . 6 71 3.2. DTNP processing/forwarding . . . . . . . . . . . . . . . . 6 72 4. Reduce the bandwidth consumption in failure-free network . . . 8 73 4.1. Upstream Tree Notifications . . . . . . . . . . . . . . . 8 74 4.2. Joining a tree in dedicated backup status . . . . . . . . 9 75 4.2.1. Single topology environment . . . . . . . . . . . . . 9 76 4.2.2. Multi-Topology Environment . . . . . . . . . . . . . . 10 77 4.3. Activation . . . . . . . . . . . . . . . . . . . . . . . . 10 78 4.4. MRT/MCI-Only Mode . . . . . . . . . . . . . . . . . . . . 10 79 5. The TN Packet . . . . . . . . . . . . . . . . . . . . . . . . 11 80 5.1. TN Packet Format . . . . . . . . . . . . . . . . . . . . . 11 81 5.1.1. TN TimeStamp TLV Format . . . . . . . . . . . . . . . 12 82 5.2. Origination of TN Packets . . . . . . . . . . . . . . . . 13 83 6. IP/PIM Specific TN Components . . . . . . . . . . . . . . . . 13 84 6.1. IP/PIM Downstream Tree Notifications . . . . . . . . . . . 13 85 6.2. IP/PIM Upstream Tree Notifications . . . . . . . . . . . . 13 86 6.3. Incremental deployment . . . . . . . . . . . . . . . . . . 14 87 7. mLDP Specific TN Components . . . . . . . . . . . . . . . . . 14 88 7.1. mLDP Downstream Tree Notification . . . . . . . . . . . . 15 89 7.1.1. Originating a DTNP . . . . . . . . . . . . . . . . . . 15 90 7.1.2. Receiving a DTNP . . . . . . . . . . . . . . . . . . . 15 91 7.1.3. Forwarding a DTNP . . . . . . . . . . . . . . . . . . 15 92 7.2. mLDP Upstream Tree Notification . . . . . . . . . . . . . 15 93 7.2.1. Originating a UTNP . . . . . . . . . . . . . . . . . . 15 94 7.2.2. Receiving a UTNP . . . . . . . . . . . . . . . . . . . 16 95 7.2.3. Forwarding a UTNP . . . . . . . . . . . . . . . . . . 16 96 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 97 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 98 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 99 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 100 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 101 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 104 1. Terminology and Definitions 106 MoFRR : Multicast only Fast Re-Route. 108 LFA : Loop Free Alternate. 110 mLDP : Multi-point Label Distribution Protocol. 112 PIM : Protocol Independent Multicast. 114 UMH : Upstream Multicast Hop, a candidate next-hop that can be used 115 to reach the root of the tree. 117 tree : Either a PIM (S,G)/(*,G) tree or a mLDP P2MP or MP2MP LSP. 119 OIF : Outgoing InterFace, an interface used to forward multicast 120 packets down the tree towards the receivers. Either a PIM 121 (S,G)/(*,G) tree or a mLDP P2MP or MP2MP LSP. 123 IIF : Incoming InterFace, an interface where multicast traffic is 124 received by a router. 126 MCE : MultiCast Egress, the last node where the multicast stream 127 exits the current transport technology (MPLS-mLDP or IP-PIM) 128 domain or administrative domain. This maybe the router attached 129 to a multicast receiver. 131 MCI : MultiCast Ingress, the node where the multicast stream enters 132 the current transport technology (MPLS-mLDP or IP-PIM) domain. 133 This maybe the router attached to the multicast source. 135 DTNP : Downstream Tree Notification Packet. 137 UTNP : Upstream Tree Notification Packet. 139 TNP : Tree Notification Packet, Upstream or Downstream 141 JM : Join Message, the message used to join to a multicast tree, 142 i.e. to build up the tree. In PIM, this is a JOIN message, while 143 in mLDP this corresponds to a LabelMap message. 145 MRT : Maximally Redundant Trees. 147 Repair Node : The node performing a dual-join to the tree through 148 two different UMHs. Sometimes also called as dual-joining node or 149 merging node (it merges the secondary and primary tree). 151 Branching Node : A node, (i) which is considered as being on the 152 primary tree by its immediate UMH and (ii) which has at least one 153 secondary type of OIF installed for a multicast tree. 155 2. Introduction 157 Both [I-D.karan-mofrr] and [I-D.atlas-rtgwg-mrt-mc-arch] describe 158 "live-live" multicast protection, where a node joins a tree via 159 different candidate upstream multicast hops (UMH). With MoFRR the 160 list of candidate UMHs can come from either ECMP or Loop Free 161 Alternate (LFA) paths towards the MultiCast Ingress node (MCI). With 162 MRT, the candidate UMHs are determined by looking up the MCI in two 163 different (Red and Blue) topologies. In either case, the multicast 164 traffic is simultaneously received over different paths/topologies 165 for the same tree. The node 'dual-joining' the tree needs a 166 mechanism to prevent duplicate packets being forwarding to the end 167 user. For that reason a node 'dual-joining' the tree only accepts 168 packets from one of the UMHs at the time. Which UMH is preferred is 169 a local decision that can be based on IGP reachability, link status, 170 BFD, traffic flow monitoring, etc... 172 Should the node detect a local failure on the primary UMH, the node 173 has an instantly available secondary UMH that is can switch to, 174 simply by unblocking the secondary UMH. The dual-joining node is 175 also called Repair Node in the following. 177 This draft attempts to improve these solutions by: 179 o Improving fail-over time and the reliability of failure detection 180 for non-local failures; and 182 o Reducing the bandwidth consumption in a failure-free network. 184 3. Improving non-local failures 186 If a failure is not local and happens further upstream, the dual- 187 joining node needs a fast and reliable mechanism (i) to detect the 188 upstream failure and (ii) to learn that other upstream nodes cannot 189 circumvent the failure. Existing methods based on traffic monitoring 190 are limited in scope and work best with a steady state packet flow. 191 Therefore, we propose a method which can trigger the unblocking 192 independently of the packet flow. 194 Figure 1 shows an example. Consider that, e.g., node A goes down. 195 Nodes C, D and E cannot detect that locally, so they need to resort 196 to other means. After detecting the failure, node C should not 197 change to its secondary UMH (node J) as it won't help for the failure 198 of A. Node D, on the other hand, will have to unblock its secondary 199 UMH (node I). Yet again, with MoFRR, node E should not unblock its 200 secondary UMH (node K): (i) this won't help in resolving the failure 201 of node A, and (ii) one of its upstream nodes (node D in this case) 202 will be able to restore the stream with a fail-over action. 204 3.1. Downstream Tree Notifications 206 The node detecting a local failure of its primary UMH MUST originate 207 a Downstream Tree Notification Packet (DTNP) to all downstream 208 branches of the tree. Each router that receives the DTNP determines 209 if it is a Repair Node for that tree. If it is not a Repair Node, 210 the DTNP is forwarded further down the tree. If the node is the 211 Repair Node, the secondary UMH is unblocked and the DTNP is 212 discarded. The DTNP allows a downstream router to unambigously 213 identify the multicast tree impacted by the failure. 215 In order to decrease reaction time, the DTNP SHOULD be originated 216 from the data plane when a local failure is detected, as well as 217 processed in the data plane when the DTNP is received. All the 218 information necessary to send and receive a DTNP has to be available 219 in the data plane in advance. 221 3.2. DTNP processing/forwarding 223 When a DTNP is received from an UMH, the node MUST check 225 o whether it has a secondary UMH, and if yes, 227 o whether this particular DTNP was received on the primary or 228 secondary UMH, and 230 o whether another DTNP had been received beforehand from the other 231 UMH. 233 Whenever a node receives a DTNP from its primary UMH and the node has 234 a secondary UMH for which no DTNP had been received beforehand, this 235 node could be a Repair Node, so unblocks its secondary UMH. The DTNP 236 MUST not be forwarded, but the node has to store the fact that a DTNP 237 has been received for the primary UMH for this multicast tree. 239 If a node receives a DTNP from its primary UMH but does not have a 240 secondary UMH, this node is not the Repair Node and MUST forward the 241 DTNP. 243 If a node receives two DTNPs, one from the primary UMH and another 244 one from the secondary UMH, then this node is not the Repair Node and 245 it MUST forward the last received DTNP to all branches of the tree. 246 (Secondary UMH does not need to be unblocked since it cannot remedy 247 the failure.) 249 A DTNP received only from the secondary UMH MUST NOT be forwarded, 250 but the node has to store the fact that a DTNP has been received for 251 the secondary UMH for this multicast tree. 253 Whenever a decision has been taken to originate or forward a DTNP, it 254 will be automatically replicated to all downstream legs, given that 255 it is a multicast packet. DTNP MUST be replicated also to downstream 256 stand-by legs if such legs exist. 258 It would raise security issues if DTNPs propagated outside the 259 operator network, so MCEs MUST prevent that DTNP packets propagate to 260 receivers or to other domains. Rephrased, nodes MUST NOT forward 261 DTNPs to legs that lead to receivers or to external autonomous 262 systems. 264 +-+ +-+ +-+ +-+ 265 |F|---|G|---|H|---|I| 266 +-+ +-+ +-+ +-+ 267 / \ 268 / \ 269 +---+ +-+ +-+ +-+ +-+ +-+ 270 |MCI|~~~~~~|A|---|B|---|C|---|D|---|E| 271 +---+ +-+ +-+ +-+ +-+ +-+ 272 \ / \ / 273 \ / \ / 274 +-+ +-+ 275 |J| |K| 276 +-+ +-+ 278 Figure 1: Remote failure example 280 As an example, consider Figure 1. If node A fails, B detects the 281 failure locally and triggers a DTNP (towards C). Node C is not the 282 Repair Node because it will receive the DTNP from both the primary 283 UMH (from B) and the secondary UMH (from J). Because node C is not 284 the Repair node it will forward the DTNP towards K and D (observing 285 rule 3.). K does not have a secondary UMH for this tree, so it will 286 send the DTNP downstream towards E (rule 2.). Node D has a secondary 287 UMH, so it applies rule 1. Node E applies rule 4. As a result, 288 subscribers sitting at or below nodes D and E will continue receiving 289 the multicast traffic. 291 4. Reduce the bandwidth consumption in failure-free network 293 In some of networks, such as aggregation networks, bandwidth is more 294 sparse than, e.g., in core networks. Live-live multicast protection 295 results in traffic duplication in the failure-free network as it 296 continuously uses bandwidth for both trees or segments. In such 297 networks it is relevant if the capacity serving backup purposes can 298 be used in the failure-free network, i.e., most of the time, by best- 299 effort or even by lower-than-best-effort traffic. 301 +---+ +-+ +-+ 302 |MCI|~~~~~~|A|---|B| 303 +---+ +-+ +-+ 304 \\ // 305 \\ // 306 +-+ 307 |C| 308 +-+ 310 Nodes A and B have receivers. Double lines show bandwidth 311 consumption that is superfluous when there is no failure in the 312 network. 314 Figure 2: Example for secondary segments occupying bandwidth in MoFRR 316 In live-standby mode the aim is that the secondary tree or secondary 317 tree segments are not loaded with multicast traffic as long as there 318 is no failure. A "live-standby" type of multicast protection method, 319 however, requires two principal components: 321 o Blocking OIFs at branching points in the secondary tree to avoid 322 sending secondary packets in the first place; and 324 o Simple and fast-enough procedures to be able to activate the 325 standby tree or standby tree-segment. 327 4.1. Upstream Tree Notifications 329 The UTN mechanism requires that the secondary tree or tree segment 330 was built with dedicated backup status. In MoFRR or MRT live-live 331 mode the secondary tree and tree segments are active, only the merge 332 point, i.e. the Repair Node, keeps the secondary incoming interface 333 blocked. Dedicated backup status means that the OIFs corresponding 334 to the secondary tree are installed into the data plane but they are 335 installed with a flag denoting they are blocked. Packets are not 336 forwarded to these interfaces unless an Upstream Tree Notification 337 Packet (UTNP) activates them. 339 Sending notifications upstream helps facilitating live-standby mode 340 instead of live-live. Whenever a node detects a failure on the 341 primary tree (the failure being upstream from the node's location), a 342 UTNP SHOULD be sent upstream towards the source on the secondary tree 343 segment. It is to be noted that the reception of a DTNP MAY be used 344 as an upstream failure indication, so it MAY trigger sending a UTNP. 345 The UTNP activates the secondary tree segments at branching nodes, 346 i.e., unblocks the secondary OIFs. 348 Both the secondary JM and the UTNP go up the tree until a branching 349 node is reached. The branching node is 351 o in a single topology environment: a node that is part of the 352 primary tree and that also has a secondary leg; or 354 o the MCI. 356 4.2. Joining a tree in dedicated backup status 358 The secondary join process is almost identical to what the MRT and 359 MoFRR drafts describe, i.e., a repair node simply sends a secondary 360 JM through another UMH (on another topology, in case of MRT). 362 For UTN, the secondary JM, however, has to explicitly indicate the 363 intended dedicated backup status. The backup indication MUST be an 364 opaque and transitive indication, so that legacy nodes transparently 365 keep the indication when sending the backup JM further up. In the 366 following, such a JM will be called as "backup JM". How a JM may 367 indicate its secondary status is protocol specific and will be 368 discussed in the appropriate chapter below. 370 4.2.1. Single topology environment 372 In a single topology environment (MoFRR), the repair node sends the 373 secondary backup JM through a second UMH of its choice. From that 374 UMH on, the backup JM is routed towards the source as if it was a 375 regular JM. In every node, the backup JM MUST be processed 376 identically to a regular JM (including adding a new entry to the OIF 377 list), but, in addition, the added OIF MUST be marked with "blocked" 378 flag. Traffic MUST NOT be forwarded through this interface for this 379 multicast tree while in blocked status. 381 If a node receives a primary JM after receiving a secondary JM from 382 the same neighbor, the node MUST reset the corresponding OIF entry to 383 "unblocked" state. Furthermore, the primary JM MUST be sent further 384 upwards if the node had no other "unblocked" OIFs, i.e., if the node 385 has not received a primary JM from any other neighbor for the given 386 multicast tree. 388 4.2.2. Multi-Topology Environment 390 In a multi-topology environment (MRT), the secondary tree is built 391 completely independent of the primary tree, on a second topology. 392 This topology ID is attached to the backup JM. Not only the repair 393 node, but each following node receiving the backup JM will route the 394 backup JM towards the source on the second topology. The dedicated 395 backup indication MUST be separated from the topology ID, i.e. a 396 legacy node could send JMs on the secondary topology but will not set 397 the dedicated backup flag. 399 4.3. Activation 401 UTNP SHOULD be originated when an upstream failure has been detected 402 on the primary multicast tree and the node has a secondary UMH 403 installed with stand-by status. Note that the upstream failure may 404 mean not only the (directly connected) UMH, but any failure up to the 405 MCI. Such an upstream failure may be detected in several ways (out 406 of scope). We note, however, that the reception of a DTNP from the 407 primary UMH MAY be used as such a trigger. 409 The UTNP activates the blocked OIF on which it was received. The 410 UTNP is forwarded up until a branching node is reached, which 411 discards the UTNP and starts forwarding multicast traffic on the leg 412 from where the UTNP was received (e.g., after unblocking the 413 respective OIF). If the branching node does not consider itself a 414 reliable forwarder of the multicast traffic of the indicated tree 415 (e.g., it received a failure indication in the form of a DTNP), it 416 also sent a UTNP after receiving that indication to its secondary 417 UMH, given it had one. 419 4.4. MRT/MCI-Only Mode 421 If each node in the network supports UTN and also all nodes support 422 MRT, the nodes may work in "MRT/MCI-only" mode. 424 In MRT/MCI-only mode, there is one single branching point for all 425 failures, the MCI. Other nodes MUST NOT consider themselves as 426 branching nodes. MRT ensures the necessary maximally disjoint 427 secondary tree up to the MCI, on a second topology. Only the MCI 428 MUST keep its OIFs corresponding to the secondary tree blocked. 429 Similarly, only MCEs MUST keep their secondary backup IIFs blocked. 430 Any other nodes MUST NOT block their (secondary) IIFs or OIFs. 432 In MRT/MCI-only mode, UTNP MUST be forwarded directly to the MCI. 433 The mode enables that a node detecting a downstream failure of the 434 primary tree MAY send a UTNP upstream towards the source/MCI on the 435 primary tree. 437 If an UTNP is received by the MCI on the secondary topology in "MRT/ 438 MCI-only" mode, the MCI MUST unblock the OIF where the UTNP was 439 received. This activates a whole sub-tree of the secondary tree. 441 If an UTNP is received by the MCI on the primary topology in "MRT/ 442 MCI-only" mode, the MCI gets no information on which leg to activate 443 on the secondary tree, so it MUST activate (unblock) all secondary 444 legs. 446 5. The TN Packet 448 5.1. TN Packet Format 450 A Tree Notification is a IPv4 or IPv6 UDP packet with the following 451 format. 453 0 1 2 3 454 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 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Version Number | Message Type | Flags | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Originator ID | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Sequence Number | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | TLVs ... | 463 . . 464 . . 465 . . 466 | | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 Version number: This is a 2 octet field encoding the version 470 number, currently 0. 472 Message type: This is a 1 octet field encoding the message type, 473 currently two are defined; 475 Type 0: Downstream Tree Notification. 477 Type 1: Upstream Tree Notification. 479 Flags: A 1 octet field encoding the flags, currently no flags are 480 defined, set to zero on send, ignored when received. 482 Originator ID: IPv4 address owned by the of the TN originator. 484 Sequence Number: Number starting at 0, and increased by 1 each time 485 a new TN is originated. 487 TLVs: TLVs (Type-Length-Value tuples). 489 The TLV's have the following format. 491 0 1 2 3 492 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 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Type | Length | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Value | 497 . . 498 . . 499 . . 500 | | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 Type: This is a 2 octet field encoding the type number of the TLV. 505 Length: This is a 2 octet field encoding the length of the Value in 506 octets. 508 Value: String of Length octets, to be interpreted as specified by 509 the Type field. 511 5.1.1. TN TimeStamp TLV Format 513 The TimeStamp is an optional TLV that MAY be included when the TN was 514 originated, it has the following format. 516 0 1 2 3 517 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 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Type = 0 | Length = 8 | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | TimeStamp Sent (seconds) | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | TimeStamp Sent (microseconds) | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 TimeStamp: The TimeStamp is the time-of-day (in seconds and 527 microseconds, according to the sender's clock) in NTP format [NTP] 528 when the Tree Notification is sent. 530 5.2. Origination of TN Packets 532 TN packets SHOULD be pre-loaded to the data plane cards, e.g. to a 533 buffer, so that the packet only needs to be flushed when needed. 534 This minimizes the incurred delay. 536 One TN packet MUST be sent per affected multicast tree. This does 537 not lead to a scalability problem in practical network deployments, 538 where it is not expected that a node has to send more than a few 539 1000s of TN packets. 541 6. IP/PIM Specific TN Components 543 The TN UDP datagram is encapsulated in an IP packet with (S,G) set as 544 source and destination in the IP header. Such a TN packet is 545 originated for each affected (S,G) multicast tree. The UDP 546 portnumber is set to an IANA assigned number for PIM TN. 548 6.1. IP/PIM Downstream Tree Notifications 550 As explained before, DTNP is multicasted on each tree on each 551 outgoing interface (including potential "standby" OIFs). If a node 552 is a potential repair node for a multicast tree, the IP forwarding 553 engine MUST be programmed so that it monitors DTNP packets, which are 554 to be recognized among the (S,G) normal data packets based on their 555 UDP port number. If a DTNP is recognized, the affected tree can be 556 identified from the IP header's source and destination address 557 fields. 559 As noted in Section 3.2, nodes MUST NOT forward DTNP outside the 560 operator domain. I.e., nodes egressing the domain MUST filter and 561 discard DTNP packets on their egress interfaces. 563 The DTN mechanism does not require any update of PIM related 564 specifications. 566 6.2. IP/PIM Upstream Tree Notifications 568 An originated UTNP is to be sent upstream to the secondary UMH, i.e., 569 upstream through the secondary incoming interface. The forwarding 570 engine MUST be programmed so that despite the UTNP packet having 571 (S,G) in the IP header, it MUST forward the UTNP packet upstream. 572 (U)TN(P) packets are to be recognized based on their UDP port number. 574 Only nodes that have installed some OIFs in blocked (backup) status 575 need to keep monitoring for UTNP packets. 577 The UTN mechanism requires that, when a node performs a secondary 578 join, the PIM JOIN message indicates its dedicated "standby" status. 579 Such an indication is required so that the recipient of a standby PIM 580 JOIN can recognise that it can install its interface, through which 581 the standby PIM JOIN was received, into the OIF list in blocked 582 state. (A received UTNP could be one trigger to unblock such a 583 backup OIF.) An extension of PIM JOIN messages and mechanisms is the 584 responsibility of the PIM WG. It is to be noted that a secondary 585 status indication has already been proposed to the IETF in 586 [I-D.liu-pim-single-stream-multicast-frr]. 588 6.3. Incremental deployment 590 The DTNP can be forwarded by legacy nodes as a data packet. So DTN 591 can be deployed incrementally if the failure detecting node and 592 repair nodes support it. 594 In case of UTN, the (S,G) addressed (U)TN(P) packet MUST be forwarded 595 towards to source, upstream. This is in contrast to the normal 596 forwarding procedures for (S,G) packets. This means that legacy 597 nodes cannot forward such packets. It remains to be studied if the 598 UTNP packet can be a unicast packet sent towards the source or MCI, 599 or if the UTNP packet can be tunneled through legacy nodes. In the 600 current version of the spec, legacy nodes cannot handle UTNP. As a 601 consequence, a node supporting this spec MUST NOT send dedicated 602 backup JOIN messages to a legacy node. 604 Detecting the capability of supporting Tree Notifications can be done 605 via capability advertisement. This should be specified by the PIM 606 WG. As an indication, it is likely that a "TN-Capable" PIM-Hello 607 option needs to be standardized. 609 7. mLDP Specific TN Components 611 Since MPLS is used as transport technology, the UTN and DTN are 612 forwarded up and down the LSP using MPLS encapsulation. The MPLS 613 label pushed onto the TN is the label associated with the MP LSP 614 impacted by the failure. This follows more of less the same 615 mechanism as described in [RFC4379]. Its important that a TN packet 616 is never IP forwarded when the tail of the MP LSP is reached. In 617 order to prevent IP forwarding, the destination address MUST be set 618 to an address from the 127/8 range for IPv4 and that same range 619 embedded in as IPv4-mapped IPv6 address. The source address in the 620 IP header MUST be set to an address local to the router. The UDP 621 port number is set to an IANA assigned number for mLDP TN. 623 7.1. mLDP Downstream Tree Notification 625 7.1.1. Originating a DTNP 627 As documented in section Section 3.1, a Downstream Tree Notification 628 is sent by a router that detects a failure of an upstream link or 629 node. The DTN packet is then sent to each LDP neighbor in the 630 Outgoing Interface List for each MP LSP impact by the failure using 631 the MPLS Label that this neighbor has assigned for that MP LSP. 633 7.1.2. Receiving a DTNP 635 A Downstream Tree Notification Packet is received inline with the 636 data on a particular LSP. If the receiving router is a Repair Node, 637 the MPLS forwarding logic will monitor the MPLS packets in order to 638 detect the DTN packet based on the UDP port number assigned for mLDP 639 TN. When a DTNP is detected, the outer MPLS label identifies the 640 LSP. No additional mechanism or lookups are needed here. The MPLS 641 forwarding code can immediately activate the standby upstream path 642 and disable the old primary path following the procedures described 643 in Section 3.2 645 7.1.3. Forwarding a DTNP 647 If a router is not a Repair Node for a particular LSP it does not 648 need to monitor the incoming traffic for that LSP in order to detect 649 the DFN packet. Such a router will just forward the DTN packet down 650 the LSP as normal data. Also, routers that don't support DTN 651 processing will always just forward a DTN packet as normal data. For 652 the network to benefit from this feature, not all routers need to be 653 DTN capable. 655 7.2. mLDP Upstream Tree Notification 657 7.2.1. Originating a UTNP 659 Following the procedures as described in Section 4.1, an UTNP MAY 660 need to be originated and sent to an upstream LDP neighbor. A P2MP 661 LSP has no upstream labeled path to reach the root because a P2MP LSP 662 is unidirectional. In order to create an upstream path that follows 663 the P2MP LSP all the way up towards the root we apply the procedures 664 are documented in [I-D.ietf-mpls-mldp-hsmp]. A MP2MP LSP already has 665 an upstream path to the root of the tree, however, these packets are 666 also forwarded down the tree by other LSRs. There are two possible 667 approuches, an LSRs that received a DTNP on an upstream interface may 668 just choose to ignore these packets, or an LSR may filter out DTNP 669 packets from ever being forwarded down the tree. More details will 670 be added in later revisions of the draft. 672 7.2.2. Receiving a UTNP 674 An Upstream Tree Notification is received on the upstream path 675 associated with the MP LSP by node U. If router U has a downsteam 676 interface in that MP LSPs OIF list that was joined in standby, it 677 will move that interface to forwarding. The outer label in the MPLS 678 header will identify the MP LSP that is targeted. However, that does 679 not necessarily identify the downstream LDP neighbor and interface 680 that needs to be put in forwarding state. Following the procedures 681 in [I-D.ietf-mpls-mldp-hsmp] node U MAY assign all the downstream LDP 682 neighbors the same label for the upstream path. For the purpose of 683 UTN, node U MUST assign a unique label for each downstream LDP 684 neighbor. If that Label is unique, the UTNP will identify the MP LSP 685 and the downstream LDP neighbor. Since node U has selected the 686 downstream interface, it knows which interface to put in forwarding 687 mode. 689 7.2.3. Forwarding a UTNP 691 A UTNP has to be forward upstream towards the root of the MP LSP 692 following the procedures as defined in Section 4.3 694 8. Acknowledgements 696 The authors would like express their thanks for Gabor Enyedi for 697 initial discussions. The authors would also like to thank Stefan 698 Olofsson and Javed Asghar for commenting on the draft. 700 9. IANA Considerations 702 IANA is requested to allocate UDP port numbers to TN messages. One 703 port number for TN in IP/PIM context, and another one for MPLS/mLDP 704 context. The separation of UDP port numbers between IP and MPLS is 705 requested to prevent problems when a PIM multicast tree is 706 transported partly through an mLDP multicast tree. 708 10. Security Considerations 710 Two types of security problems can be foreseen by the authors: 712 o Handling illegally injected TN packets 713 o Handling replay attacks (re-injecting previous TN messages) 715 o TN messages propagating outside an operator's domain 717 Illegal TN packets can be handled with authentication checks. 718 Providing authentication for TN messages will be considered in later 719 revisions of this spec. 721 Prevention of replay attacks needs authentication in combination with 722 sequence numbering. 724 Preventing TN messages that travel inline with data packets MUST be 725 solved by nodes egressing the operator's domain. Solutions for IP 726 and MPLS are described in sections Section 6 and Section 7, 727 respectively. 729 11. References 731 11.1. Normative References 733 [I-D.ietf-mpls-mldp-hsmp] 734 Jin, L., JOUNAY, F., Wijnands, I., and N. Leymann, "LDP 735 Extensions for Hub & Spoke Multipoint Label Switched 736 Path", draft-ietf-mpls-mldp-hsmp-00 (work in progress), 737 September 2012. 739 [I-D.ietf-rtgwg-mrt-frr-architecture] 740 Atlas, A., Kebler, R., Envedi, G., Csaszar, A., 741 Konstantynowicz, M., White, R., and M. Shand, "An 742 Architecture for IP/LDP Fast-Reroute Using Maximally 743 Redundant Trees", draft-ietf-rtgwg-mrt-frr-architecture-01 744 (work in progress), March 2012. 746 [I-D.karan-mofrr] 747 Karan, A., Filsfils, C., Farinacci, D., Decraene, B., 748 Leymann, N., and W. Henderickx, "Multicast only Fast Re- 749 Route", draft-karan-mofrr-02 (work in progress), 750 March 2012. 752 11.2. Informative References 754 [I-D.atlas-rtgwg-mrt-mc-arch] 755 Atlas, A., Kebler, R., Wijnands, I., Csaszar, A., and G. 756 Envedi, "An Architecture for Multicast Protection Using 757 Maximally Redundant Trees", 758 draft-atlas-rtgwg-mrt-mc-arch-00 (work in progress), 759 March 2012. 761 [I-D.liu-pim-single-stream-multicast-frr] 762 Liu, H., Zheng, L., Bai, T., and Y. Yu, "Single Stream 763 Multicast Fast ReRoute (SMFRR) Method", 764 draft-liu-pim-single-stream-multicast-frr-01 (work in 765 progress), October 2010. 767 Authors' Addresses 769 IJsbrand Wijnands (editor) 770 Cisco 771 De kleetlaan 6a 772 Diegem, 1831 773 Belgium 775 Phone: 776 Email: ice@cisco.com 778 Andras Csaszar (editor) 779 Ericsson 780 Konyves Kalman Krt 11/B 781 Budapest, 1097 782 Hungary 784 Phone: 785 Email: Andras.Csaszar@ericsson.com 787 Jeff Tantsura 788 Ericsson 789 300 Holger Way 790 San Jose, California 95134 791 USA 793 Email: Jeff.Tantsura@ericsson.com