idnits 2.17.1 draft-jjb-ccamp-rsvp-te-hsmp-lsp-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 an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 17, 2011) is 4815 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: 'PE1' is mentioned on line 434, but not defined == Missing Reference: 'P1' is mentioned on line 434, but not defined == Missing Reference: 'P3' is mentioned on line 413, but not defined == Missing Reference: 'PE3' is mentioned on line 413, but not defined == Missing Reference: 'PE2' is mentioned on line 434, but not defined == Outdated reference: A later version (-03) exists of draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-01 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE' == Outdated reference: A later version (-08) exists of draft-ietf-l2vpn-ldp-vpls-broadcast-exten-00 == Outdated reference: A later version (-16) exists of draft-ietf-l2vpn-vpls-mcast-08 == Outdated reference: A later version (-05) exists of draft-ietf-l2vpn-vpms-frmwk-requirements-03 == Outdated reference: A later version (-04) exists of draft-ietf-pwe3-p2mp-pw-01 Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group L. Jin 3 Internet-Draft ZTE Corporation 4 Intended status: Standards Track F. Jounay 5 Expires: August 21, 2011 France Telecom 6 M. Bhatia 7 Alcatel-Lucent 8 February 17, 2011 10 Extensions to Resource Reservation Protocol - Traffic Engineering 11 (RSVP-TE) for Hub and Spoke Multipoint Label Switched Paths (LSPs) 12 draft-jjb-ccamp-rsvp-te-hsmp-lsp-00 14 Abstract 16 In Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) 17 environment, the RSVP-TE based Point-to-Multipoint (P2MP) LSP allows 18 traffic to transmit from root to leaf node, but there is no co-routed 19 reverse path for traffic from leaf to root node. This draft 20 introduces a Hub and Spoke Multipoint (HSMP) LSP, which allows 21 traffic from both the root to the leaves through a P2MP LSP and also 22 the leaves to the root along a co-routed reverse path. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 21, 2011. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Application . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 1.1. Time Synchronization . . . . . . . . . . . . . . . . . . . 5 60 1.2. P2MP Pseudowire based L2VPNs (VPMS and VPLS) . . . . . . . 6 62 2. Comparing Hub-Spoke MP LSP with P2MP and Unidirectional 63 Reverse LSP . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 2.1. Number of Path and Resv State Blocks . . . . . . . . . . . 7 65 2.2. Hardware Programming and Label Utilization . . . . . . . . 8 66 2.3. RSVP Control Traffic . . . . . . . . . . . . . . . . . . . 8 68 3. Setting up a Hub and Spoke Multipoint LSP with RSVP-TE . . . . 9 69 3.1. Hub and Spoke Multipoint LSP and Path Messages . . . . . . 9 70 3.2. Procedures for Hub and Spoke Multipoint LSP . . . . . . . 9 71 3.3. Bandwidth Allocation . . . . . . . . . . . . . . . . . . . 10 73 4. Setting up the Hub Spoke Multipoint LSP . . . . . . . . . . . 11 75 5. Grafting . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 6. Pruning . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 7. Refresh Reduction . . . . . . . . . . . . . . . . . . . . . . 15 81 8. Fast Reroute . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 85 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 87 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 90 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 91 12.2. Informative References . . . . . . . . . . . . . . . . . . 20 93 Appendix 1. Appendix: Alternate Mechanism to set up a reverse 94 LSP . . . . . . . . . . . . . . . . . . . . . . . . . 22 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC2119 [RFC2119]. 101 When used in lower case, these words convey their typical use in 102 common language, and are not to be interpreted as described in 103 RFC2119 [RFC2119]. 105 1. Application 107 The proposed technique targets one-to-many applications that require 108 reverse one-to-one traffic flow (thus many one-to-one in the reverse 109 direction). 111 There are a few applications that could use such kind of Resource 112 Reservation Protocol - Traffic Engineering (RSVP-TE) based Hub and 113 Spoke Multipoint LSPs. 115 1.1. Time Synchronization 117 The delivery of time synchronization to end equipments, such as base 118 stations, can be achieved using a time protocol as [IEEE] (also known 119 as PTP). This protocol defines Transparent Clock (TC) function, 120 which can be used in transport nodes to improve the accuracy of time 121 synchronization. Two types of TCs exist in [IEEE]: End-to-end 122 Transparent Clock (E2E TC) and Peer-to-peer Transparent Clock (P2P 123 TC). P2P TCs assume that the link delays between the different nodes 124 are calculated 126 Assuming that a chain of P2P TCs is used between a PTP master and a 127 PTP slave, time synchronization can be delivered to the PTP slave by 128 sending timestamps only in the direction master to slave (one way 129 mode), via PTP Sync messages. This is possible because of the link 130 delay calculation performed locally by each node, which enables it to 131 calculate the propagation delay over the path. This scenario permits 132 that the same PTP Sync messages would be sent by the PTP master to 133 all the PTP slaves. 135 In this scenario (chain of P2P TCs), the PTP slave might have to send 136 also messages (not carrying timestamps) back to the PTP master in 137 some cases. For instance, PTP Signaling messages could be sent back 138 to the PTP master. These PTP Signaling messages are not intended to 139 be received by the other PTP slaves. 141 By using Point-to-Multipoint (P2MP) technology to transmit PTP Sync 142 messages will greatly improve the bandwidth usage for above 143 applications. This will also be useful for monitoring performance 144 metrics for two-way delay and related metrics such as delay variation 145 and loopback measurement. Current RSVP-TE based Point-to-Multipoint 146 LSP mechanism only provides unidirectional path from the root to the 147 leaf nodes, which cannot fulfill the above new requirement (i.e. need 148 for a reverse path for the PTP Signaling messages). 150 This draft attempts to solve this problem. RSVP-TE based Hub and 151 Spoke P2MP LSP described in this draft provides a co-routed reverse 152 path from the leaf to the root based on current unidirectional Point- 153 to-Multipoint LSP. 155 1.2. P2MP Pseudowire based L2VPNs (VPMS and VPLS) 157 Point-to-Multipoint (P2MP) Pseudowires (PW) described in 158 [I-D.ietf-pwe3-p2mp-pw] requires an additional reverse LSP to be set 159 up from the leaf node (referred as egress PE) to root node (referred 160 as ingress PE). Instead, if HSMP LSP is used to multiplex P2MP PW, 161 the reverse path can also be multiplexed to HSMP upstream path to 162 avoid setting up an independent reverse path. In that case, the 163 operational cost will be reduced for maintaining only one HSMP LSP, 164 instead of P2MP LSP and n (number of leaf nodes) P2P reverse LSPs 166 The VPMS defined in [I-D.ietf-l2vpn-vpms-frmwk-requirements] requires 167 reverse path from the leaf to the root node. The P2MP PW multiplexed 168 to HSMP LSP can provide VPMS with reverse path, without introducing 169 independent reverse paths from each leaf to the root. 171 The P2MP PW multiplexed to HSMP LSP can also be used for VPLS 172 [RFC4672], which will reduce the overall broadcast/multicast 173 utilization for VPLS. In current VPLS implementations with a full 174 mesh of P2P LSPs between PEs, broadcast, unknown and multicast (BUM) 175 traffic is efficiently distributed over the physical links between 176 Provider (P) and Provider Edge (PE) routers. 177 [I-D.ietf-l2vpn-vpls-mcast] and 178 [I-D.ietf-l2vpn-ldp-vpls-broadcast-exten] leverages this constraint 179 by introducing the usage of P2MP PW and/or P2MP LSP. But a specific 180 P2P PW over P2P LSP is still needed for unicast traffic between the 181 PEs. 183 In the VPLS implementation scenario with P2MP PW multiplexed to HSMP 184 LSPs, each PE signals a P2MP PW with itself as a root to all other 185 PEs in the VPLS. Thereafter, all BUM traffic from this PE will use 186 this P2MP PW. Unicast (learnt) traffic from a particular PE (e.g. 187 PE1) to another PE (e.g. PE2) will be sent from leaf to root using 188 the reverse path of P2MP PW where PE2 is the root. 190 This simplifies the VPLS implementation by reducing (a) link 191 utilization for the BUM traffic and (b) the total number of LSPs 192 maintained by each PE (i.e. instead of requiring a full mesh of LSPs, 193 PEs now only require one HSMP LSP). It also helps in avoiding the 194 unnecessary MAC learning that happens on the hub PE routers in case 195 of H-VPLS. 197 2. Comparing Hub-Spoke MP LSP with P2MP and Unidirectional Reverse LSP 199 An HSMP LSP provides a Point-to-Multipoint reachability from the root 200 node to the leaf nodes and a unicast reachability from all the leaf 201 nodes back to the root node. An obvious question that comes up is 202 that how is this better than setting up a P2MP LSP from a root node 203 and Unidirectional reverse LSPs back from the leaves to the root 204 node. This section compares the two mechanisms and demonstrates how 205 establishing one HSMP LSP is better than establishing a P2MP LSP with 206 reverse LSPs from the leaves back to the root. 208 Consider the topology as shown in Figure 1. Router A wants to 209 establish a Point-to-Multipoint connectivity to Routers E, F, G and H 210 and also wants a Unicast path back from these routers to itself. 211 There are two ways to accomplish this. In the first, we set up a 212 HSMP LSP between A, E, F, G and H. In the second, we set up a P2MP 213 LSP between A, E, F, G and H and establish regular LSPs back from 214 these routers to A. 216 A 217 | 218 B 219 / \ 220 C D 221 / \ / \ 222 E F G H 224 Figure 1 226 2.1. Number of Path and Resv State Blocks 228 When an RSVP-capable router receives an initial Path message, it 229 creates a path state block (PSB) for that particular session. Each 230 PSB consists of parameters derived from the received Path message 231 such as SESSION, SENDER_TEMPLATE, SENDER_TSPEC, RSVP_HOP objects, and 232 the outgoing interface provided by the IGP routing. Similarly, as a 233 Resv message travels upstream toward the sender, it creates a 234 reservation state block (RSB) in each RSVP-capable node along the way 235 which stores information derived from the objects in the received 236 Resv message, such as SESSION, RSVP_HOP, FLOWSPEC, FILTERSPEC, STYLE, 237 etc objects. The PSB and the RSB need to be periodically refreshed 238 by the Path and the Resv messages. 240 In case of HSMP LSP, the number of PSBs and the RSBs is the same as 241 that for establishing a single P2MP LSP and is a function of how the 242 P2MP LSP is signaled. It is equal to the number of S2L sub-LSPs of 243 the P2MP LSP if each S2L sub-lsp is signaled independently. It is 244 one, if an aggregated mode is used where multiple sub-lsps of the 245 P2MP LSP are signaled togethar. 247 In the second case routers need to maintain this state for the P2MP 248 LSP and all the Unidirectional LSPs that go via it. 250 Lets look at the state that branch node B needs to maintain. In case 251 of HSMP LSP it is the same as a P2MP LSP. In the other approach it 252 needs to maintain state for the following LSPs: 254 1. P2MP LSP from A and E, F, G and H 256 2. Reverse LSP ECBA 258 3. Reverse LSP FCBA 260 4. Reverse LSP GDBA 262 5. Reverse LSP HDBA 264 We can thus clearly see that the amount of state that routers need to 265 maintain in the second approach is much more than the HSMP LSP. It 266 becomes all the more pronounced when the P2MP LSP is signalled using 267 the aggregated approach described in [RFC4875] where a single Path 268 and Resv message is used to signal the entire P2MP LSP. In such 269 cases the amount of state that such branch nodes need to maintain 270 increase linearly with the leaf nodes that get added to the P2MP LSP. 272 2.2. Hardware Programming and Label Utilization 274 In the HSMP LSP the LSR B advertises the same (upstream) label to C 275 and D, thus consumes only one label and needs to only program one 276 entry in the ILM table. 278 In the second approach, LSR B needs to advertise two different labels 279 to LSRs C and D and will thus consume 2 ILM entries in HW. 281 We can clearly see that the number of labels consumed in the second 282 approach will increase linearly with the amount of branching that 283 happens on that LSR. It will further aggravate as the number of P2MP 284 LSPs increase. 286 2.3. RSVP Control Traffic 288 In the second approach, LSR B will have RSVP control traffic for the 289 P2MP LSP and all the Unidirectional reverse LSPs that pass through 290 it. In case of HSMP LSR B will only have the RSVP traffic for the 291 P2MP LSP. 293 3. Setting up a Hub and Spoke Multipoint LSP with RSVP-TE 295 The Hub and Spoke Multipoint LSP comprises of one downstream 296 unidirectional P2MP LSP from ingress LSR to each of egress LSR, and a 297 co-routed upstream path from each of egress LSR to ingress LSR. 299 [RFC3473] describes a point-to-point bidirectional LSP mechanism for 300 the GMPLS architecture, where a bidirectional LSP setup is indicated 301 by the presence of an Upstream_Label object in the Path message. The 302 Upstream_Label object has the same format as the generalized label, 303 and uses Class-Number 35 (of form 0bbbbbbb) and the C-Type of the 304 label being used. Hub and Spoke Multipoint LSP describe in this 305 draft will use similar mechanism, and reuse the Upstream_Label object 306 defined in [RFC3473]. Note: the downstream label assignment is still 307 applied, and upstream direction is based on the h&s topology (hub = 308 upstream, spoke= downstream), rather on forwarding direction. 310 3.1. Hub and Spoke Multipoint LSP and Path Messages 312 [RFC4875] allows a P2MP LSP to be signaled using one or more Path 313 messages . Each Path message may signal one or more source to leaf 314 (S2L) sub-LSPs. This document assumes that a unique Path message is 315 being used to signal each individual sub-LSP of the HSMP LSP. Later 316 versions of this document can describe mechanisms to use a single 317 Path message to describe each component sub LSP of the HSMP LSP. 319 3.2. Procedures for Hub and Spoke Multipoint LSP 321 The process of establishing a Hub and Spoke Multipoint LSP follows 322 the establishment of a unidirectional P2MP LSP define in [RFC4875] 323 with some additions. To support Hub and Spoke Multipoint LSPs an 324 Upstream_Label object is added to the Path message. The 325 Upstream_Label object MUST indicate a label that is valid for 326 forwarding at the time the Path message is sent. When a Path message 327 containing an Upstream_Label object is received, the receiver first 328 verifies that the upstream label is acceptable. If the label is not 329 acceptable, the receiver MUST issue a PathErr message with a "Routing 330 problem/Unacceptable label value" indication. 332 The generated PathErr message MAY include an Acceptable Label Set 333 defined in [RFC3473] section 4.1. 335 The transit node must also allocate one label for the co-routed 336 upstream path before propagating the Path message to all downstream 337 nodes. If a transit node is unable to allocate a label or internal 338 resources, then it MUST issue a PathErr message with a "Routing 339 problem/MPLS label allocation failure" indication. With regards to 340 the co-routed return path from the leafs to the root, the forwarding 341 table on transit node will have one incoming labels allocated for all 342 of the outgoing interfaces, and one outgoing label received from 343 Upstream_Label object in Path message sent by upstream node. That 344 means the traffic from different egress LSRs will be merged at each 345 transit node, and will be sent together to upstream node, see section 346 3.3 for more detail of bandwidth guarantee in this case. 348 The Path messages sending downstream with same [P2MP ID, Tunnel ID, 349 Extended Tunnel ID] tuple as part of the SESSION object and the 350 [Tunnel Sender Address, LSP ID] tuple as part of the SENDER_TEMPLATE 351 object, but may different [Sub-Group Originator ID, Sub-Group ID] 352 MUST use same allocated label value for Upstream_Label object. 354 Leaf nodes process Path messages as usual, with the exception that 355 the upstream label should be used to transport data traffic 356 associated with the Hub and Spoke Multipoint LSP upstream towards the 357 root node. 359 When a Hub and Spoke Multipoint LSP is removed, both upstream and 360 downstream labels are invalidated and it is no longer valid to send 361 data using the associated labels. 363 3.3. Bandwidth Allocation 365 The bandwidth allocation for upstream path from leaf to root could be 366 same as the downstream path from root to leaf node [RFC3473], and the 367 bandwidth will be guarantee only when there is no traffic merging 368 happened on transit node. If there are cases where leaf nodes send 369 traffic to root node at the same time which may cause traffic to be 370 merged on one physical link at transit node, then traffic overload 371 may happen on these links. There are several ways to avoid this kind 372 of traffic overload. One way is to let the application to do some 373 delay at each leaf node to avoid traffic merging on some links of 374 transit node. 376 Some applications may not require bandwidth guarantee for the 377 upstream path from leaf to root, then it is not necessary to allocate 378 bandwidth for the upstream path. The mechanism described in 379 [I-D.ietf-ccamp-asymm-bw-bidir-lsps-bis] can be used to allocate zero 380 bandwidth for the upstream path. 382 The mechanism of providing asymmetric bandwidth allocation (non-zero 383 bandwidth of upstream path) for HSMP LSP is out of the draft scope. 385 4. Setting up the Hub Spoke Multipoint LSP 387 The Following is an example of establishing a HSMP LSP using the 388 procedures described in the previous sections. 390 +-- Receiver 391 | 392 PE2 PE3 --- Receiver 393 | | 394 P1 -- P3 395 / 396 Source --- PE1 397 \ 398 P2 -- PE5 --- Receiver 399 | 400 PE4 --- Receiver 402 Figure 2 404 The mechanism is explained using Figure 1. PE1 is a root LER (head 405 end) node. PE2, PE3, PE4 and PE5 are the leaf LER nodes. P1 and P2 406 are branch LSR nodes and P3 is a plain LSR node. 408 1. PE1 learns that PE2, PE3, PE4 and PE5 are interested in joining a 409 HSMP tree with a P2MP ID of P2MP ID1. We assume that PE1 learns 410 of the egress LERs at different points in time. 412 2. PE1 computes the P2P path to reach PE3 and sends a Path message 413 with ERO [PE1, P1, P3, PE3]. It also provides an Upstream Label 414 UL1 in the Upstream_Label object that P1 should use when 415 forwarding packets to PE1. 417 3. The Path message traverses hop-by-hop and finally reaches PE3. 418 Assume that the Path message from P1 to P3 uses upstream label of 419 UL3, in which case P1 must program the ILM to swap UL3 with UL1. 420 The Path message from P3 to PE3 uses upstream label UL4, and thus 421 P3 programs the ILM to swap UL4 with UL3. 423 4. PE3 responds with a Resv message that contains label L4, that P3 424 should use when forwarding packets to PE3. Similarly, the Resv 425 from P3 to P1 contains label L3, that P1 should use when 426 forwarding packets to P3. 428 5. Similarly when setting up the component sub-LSP from PE1 to PE2, 429 PE1 will use the same Upstream label UL1 as it knows that this 430 sub-LSP belongs to the same HSMP LSP because of the same P2MP 431 session object that both sub-LSPs carry. 433 6. The Path message, thus for this component sub-LSP goes with ERO 434 [PE1, P1, PE2] along with the Upstream label UL1 that P1 should 435 use when forwarding packets to PE1. 437 7. P1 forwards the Path message with a new Upstream label UL2. 438 Finally, PE2 sends a Resv message containing label L2, that P1 439 should use when forwarding packets to PE2. P1 also understands 440 that the Resv messages from PE2 and PE3 refer to the same HSMP 441 LSP, because of the P2MP Session Object carried in each. [ 443 8. P1 sends a separate Resv message to PE1 corresponding to each of 444 the sub-LSPs, but uses the same label L1 since the two sub LSPs 445 belong to the same HSMP LSP. 447 9. The other component sub LSPs are set up in a similar way as 448 described above. 450 5. Grafting 452 The operation of adding leaf LER(s) to an existing HSMP LSP is termed 453 grafting. This operation allows leaf nodes to join a HSMP LSP at 454 different points in time. 456 The leaf LER(s) can be added by signaling only the impacted component 457 sub- LSPs in a new Path message. Hence, the existing component sub- 458 LSPs do not have to be re-signaled. 460 +-- Receiver 461 | 462 PE2 PE3 --- Receiver 463 | | 464 P1 -- P3 -- P6 -- PE6 --- Receiver 465 / 466 Source --- PE1 467 \ 468 P2 -- PE5 --- Receiver 469 | 470 PE4 --- Receiver 472 Figure 3 474 Assume PE1 needs to set up another sub-LSP from PE1 to PE6. Being a 475 part of the same HSMP LSP, PE1 MUST advertise the same Upstream Label 476 to P1 in its Path message. P1 advertises the same Upstream Label to 477 P3. P3 when sending the Path message to P6 would advertise a fresh 478 Upstream label and similarly P6 would use a new upstream label when 479 forwarding the Path message to PE6. 481 PE6 sends a Resv message with a label back to P6. P6, would send a 482 new label back to P3. P3 because of this new component sub-LSP (PE1- 483 PE6) is now a branch LSR node that performs MPLS multicast 484 replication. 486 6. Pruning 488 The operation of removing egress LER nodes from an existing HSMP LSP 489 is termed as pruning. This operation allows leaf nodes to be removed 490 from a HSMP LSP at different points in time. This section describes 491 the mechanisms to perform pruning. 493 Assume that the LER PE6 wants to be removed from the HSMP LSP. Since 494 we used a unique Path message for each component sub LSP, the 495 teardown will rely on generating a PathTear message for the 496 corresponding Path message. PE6 will send a Path Tear message with 497 the SESSION and SENDER_TEMPLATE objects corresponding to the HSMP LSP 498 and the [Sub-Group Originator ID, Sub-Group ID] tuple corresponding 499 to the Path message. P3 upon receiving the PathTear message would 500 prune the MPLS multicast replication list and will become a normal 501 RSVP LSR node. 503 In the P2MP and HSMP context the PathTear is used for a specific 504 component sub LSP teardown. This does not necessarily mean the whole 505 path's breakdown from upstream; hence the LSRs MUST retain the 506 Upstream label until all the component sub LSPs of the HSMP LSP are 507 torn down. 509 When a HSMP LSP is removed by the root, a PathTear message MUST be 510 generated for each Path message used to signal the HS Multipoint LSP. 512 7. Refresh Reduction 514 The refresh reduction procedures described in [RFC2961] are equally 515 applicable to HS Multipoint LSPs described in this document. Refresh 516 reduction applies to individual messages and the state they install/ 517 maintain, and that continues to be the case for HS Multipoint LSPs. 519 8. Fast Reroute 521 [RFC4090] extensions can be used to perform fast reroute for the 522 mechanism described in this document when applied within packet 523 networks. 525 This is still TBD. 527 9. Acknowledgements 529 We would like to thank Dimitri Papadimitriou, Yuji Kamite, Sebastien 530 Jobert for their comments and feedback on the document. 532 10. Security Considerations 534 The same security considerations apply as for the RSVP-TE P2MP LSP 535 specification, as described in [RFC4875]. 537 11. IANA Considerations 539 No requests for IANA at this point of time. 541 12. References 543 12.1. Normative References 545 [I-D.ietf-ccamp-asymm-bw-bidir-lsps-bis] 546 Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. 547 Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label 548 Switched Paths (LSPs)", 549 draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-01 (work in 550 progress), January 2011. 552 [IEEE] "IEEE Standard for a Precision Clock Synchronization 553 Protocol for Networked Measurement and Control Systems", 554 2008. 556 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 557 Requirement Levels", BCP 14, RFC 2119, March 1997. 559 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 560 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 561 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 563 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 564 "Extensions to Resource Reservation Protocol - Traffic 565 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 566 Switched Paths (LSPs)", RFC 4875, May 2007. 568 12.2. Informative References 570 [I-D.ietf-l2vpn-ldp-vpls-broadcast-exten] 571 Delord, S., Key, R., Kamite, Y., Liu, Z., Paul, M., Kunze, 572 R., Chen, M., and L. Jin, "Extension to LDP-VPLS for 573 Ethernet Broadcast and Multicast", 574 draft-ietf-l2vpn-ldp-vpls-broadcast-exten-00 (work in 575 progress), February 2011. 577 [I-D.ietf-l2vpn-vpls-mcast] 578 Aggarwal, R., Kamite, Y., Fang, L., and Y. Rekhter, 579 "Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-08 (work 580 in progress), October 2010. 582 [I-D.ietf-l2vpn-vpms-frmwk-requirements] 583 Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard, D., 584 and L. Jin, "Framework and Requirements for Virtual 585 Private Multicast Service (VPMS)", 586 draft-ietf-l2vpn-vpms-frmwk-requirements-03 (work in 587 progress), July 2010. 589 [I-D.ietf-pwe3-p2mp-pw] 590 Martini, L., Boutros, S., Sivabalan, S., Konstantynowicz, 591 M., Vecchio, G., Nadeau, T., JOUNAY, F., Niger, P., 592 Kamite, Y., Jin, L., Vigoureux, M., Ciavaglia, L., and S. 593 Delord, "Signaling Root-Initiated Point-to-Multipoint 594 Pseudowires using LDP", draft-ietf-pwe3-p2mp-pw-01 (work 595 in progress), February 2011. 597 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 598 and S. Molendini, "RSVP Refresh Overhead Reduction 599 Extensions", RFC 2961, April 2001. 601 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 602 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 603 May 2005. 605 [RFC4672] De Cnodder, S., Jonnala, N., and M. Chiba, "RADIUS Dynamic 606 Authorization Client MIB", RFC 4672, September 2006. 608 1. Appendix: Alternate Mechanism to set up a reverse LSP 610 We had considered another approach where the leaves could set up a 611 unidirectional LSP by reversing the RRO that they recieve in the S2L 612 sub-LSP Path message and use that as the ERO in their Path message. 613 This approach was rejected because this would have entailed setting 614 up another reverse LSP which leads to more state being maintained on 615 all the intermediate routers. The reader is suggested to go through 616 Section 2 which discusses this in detail. 618 Authors' Addresses 620 Lizhong Jin 621 ZTE Corporation 622 Bibo Road, Shanghai 201203 623 China 625 Email: lizhong.jin@zte.com.cn 627 Frederic Jounay 628 France Telecom 629 Lannion Cedex 95134 630 France 632 Email: frederic.jounay@orange-ftgroup.com 634 Manav Bhatia 635 Alcatel-Lucent 636 Bangalore, 637 India 639 Email: manav.bhatia@alcatel-lucent.com