idnits 2.17.1 draft-ietf-mpls-mldp-hsmp-04.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 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 26, 2013) is 3797 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) == Unused Reference: 'I-D.ietf-l2vpn-vpms-frmwk-requirements' is defined on line 626, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pwe3-p2mp-pw' is defined on line 633, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tictoc-1588overmpls' is defined on line 638, but no explicit reference was found in the text == Unused Reference: 'IEEE1588' is defined on line 644, but no explicit reference was found in the text == Unused Reference: 'RFC3376' is defined on line 649, but no explicit reference was found in the text == Unused Reference: 'RFC6826' is defined on line 660, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-tictoc-1588overmpls-05 -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Jin 3 Internet-Draft 4 Intended status: Standards Track F. Jounay 5 Expires: May 30, 2014 France Telecom 6 I. Wijnands 7 Cisco Systems, Inc 8 N. Leymann 9 Deutsche Telekom AG 10 November 26, 2013 12 LDP Extensions for Hub & Spoke Multipoint Label Switched Path 13 draft-ietf-mpls-mldp-hsmp-04.txt 15 Abstract 17 This draft introduces a hub & spoke multipoint (HSMP) Label Switched 18 Path (LSP), which allows traffic both from root to leaf through 19 point-to-multipoint (P2MP) LSP and also leaf to root along the 20 reverse path. That means traffic entering the HSMP LSP from 21 application/customer at the root node travels downstream to each leaf 22 node, exactly as if it is travelling downstream along a P2MP LSP to 23 each leaf node. Upstream traffic entering the HSMP LSP at any leaf 24 node travels upstream along the tree to the root, as if it is unicast 25 to the root. The communication among the leaf nodes are not allowed. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC2119 [RFC2119]. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 30, 2014. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Setting up HSMP LSP with LDP . . . . . . . . . . . . . . . . . 4 70 3.1. Support for HSMP LSP Setup with LDP . . . . . . . . . . . 4 71 3.2. HSMP FEC Elements . . . . . . . . . . . . . . . . . . . . 5 72 3.3. Using the HSMP FEC Elements . . . . . . . . . . . . . . . 5 73 3.4. HSMP LSP Label Map . . . . . . . . . . . . . . . . . . . . 6 74 3.4.1. HSMP LSP Leaf Node Operation . . . . . . . . . . . . . 7 75 3.4.2. HSMP LSP Transit Node Operation . . . . . . . . . . . 7 76 3.4.3. HSMP LSP Root Node Operation . . . . . . . . . . . . . 8 77 3.5. HSMP LSP Label Withdraw . . . . . . . . . . . . . . . . . 9 78 3.5.1. HSMP Leaf Operation . . . . . . . . . . . . . . . . . 9 79 3.5.2. HSMP Transit Node Operation . . . . . . . . . . . . . 9 80 3.5.3. HSMP Root Node Operation . . . . . . . . . . . . . . . 9 81 3.6. HSMP LSP Upstream LSR Change . . . . . . . . . . . . . . . 10 82 3.7. Determining Forwarding Interface . . . . . . . . . . . . . 10 83 4. HSMP LSP on a LAN . . . . . . . . . . . . . . . . . . . . . . 10 84 5. Redundancy Considerations . . . . . . . . . . . . . . . . . . 11 85 6. Failure Detection of HSMP LSP . . . . . . . . . . . . . . . . 11 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 88 8.1. New LDP FEC Element types . . . . . . . . . . . . . . . . 12 89 8.2. HSMP LSP capability TLV . . . . . . . . . . . . . . . . . 12 90 8.3. New sub-TLVs for the Target Stack TLV . . . . . . . . . . 13 91 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 93 10.1. Normative references . . . . . . . . . . . . . . . . . . . 13 94 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 97 1. Introduction 99 The point-to-multipoint (P2MP) Label Switched Path (LSP) defined in 100 [RFC6388] allows traffic to transmit from root to several leaf nodes, 101 and multipoint-to-multipoint (MP2MP) LSP allows traffic from every 102 node to transmit to every other node. This draft introduces a hub & 103 spoke multipoint (HSMP) LSP, which has one root node and one or more 104 leaf nodes. HSMP LSP allows traffic both from root to leaf through 105 downstream LSP and also leaf to root along the upstream LSP. That 106 means traffic entering the HSMP LSP at the root node travels along 107 downstream LSP, exactly as if it is travelling along a P2MP LSP, and 108 traffic entering the HSMP LSP at any other leaf nodes travels along 109 upstream LSP toward only the root node. The upstream LSP should be 110 thought of unicast LSP to the root node, except that it follows the 111 node of reverse downstream path of the tree, rather than routing 112 protocol based unicast path. The combination of upstream LSPs 113 initiated from all leaf nodes forms a multipoint-to-point LSP. 115 2. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 This document uses some terms and acronyms as follows: 123 mLDP: Multipoint extensions for Label Distribution Protocol (LDP) 124 defined in [RFC6388]. 126 P2MP LSP: point-to-multipoint Label Switched Path. An LSP that 127 has one Ingress Label Switching Router (LSR) and one or more 128 Egress LSRs. 130 MP2MP LSP: multipoint-to-multipoint Label Switched Path. An LSP 131 that connects a set of nodes, such that traffic sent by any node 132 in the LSP is delivered to all others. 134 HSMP LSP: hub & spoke multipoint Label Switched Path. An LSP that 135 has one root node and one or more leaf nodes, allows traffic from 136 root to all leaf nodes along downstream P2MP LSP and also leaf to 137 root node along the upstream unicast LSP. 139 PTP: precise time protocol. The timing and synchronization 140 protocol defined by IEEE1588. 142 3. Setting up HSMP LSP with LDP 144 HSMP LSP is similar to MP2MP LSP described in [RFC6388], with the 145 difference that, when the leaf LSRs send traffic on the LSP, the 146 traffic is first delivered only to the root node and follows the 147 upstream path from the leaf node to the root node. The root node 148 then distributes the traffic on the P2MP tree to all of the leaf 149 nodes. 151 HSMP LSP consists of a downstream path and upstream path. The 152 downstream path is same as P2MP LSP, while the upstream path is only 153 from leaf to root node, without communication between leaf and leaf 154 nodes. The transmission of packets from the root node of an HSMP LSP 155 to the receivers (the leaf nodes) is identical to that of a P2MP LSP. 156 Traffic from a leaf node to the root follows the upstream path that 157 is the reverse of the path from the root to the leaf. Unlike an 158 MP2MP LSP, traffic from a leaf node does not branch toward other leaf 159 nodes, but is sent direct to the root where it is placed on the P2MP 160 path and distributed to all leaf nodes including the original sender. 162 To set up the upstream path of an HSMP LSP, ordered mode MUST be 163 used. Ordered mode can guarantee a leaf to start sending packets to 164 root immediately after the upstream path is installed, without being 165 dropped due to an incomplete LSP. 167 3.1. Support for HSMP LSP Setup with LDP 169 HSMP LSP requires the LDP capabilities [RFC5561] for nodes to 170 indicate that they support setup of HSMP LSPs. An implementation 171 supporting the HSMP LSP procedures specified in this document MUST 172 implement the procedures for Capability Parameters in Initialization 173 Messages. Advertisement of the HSMP LSP Capability indicates support 174 of the procedures for HSMP LSP setup. 176 A new Capability Parameter TLV is defined, the HSMP LSP Capability 177 Parameter. Following is the format of the HSMP LSP Capability 178 Parameter. 180 0 1 2 3 181 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 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 |U|F| HSMP LSP Cap(TBD IANA) | Length | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 |S| Reserved | 186 +-+-+-+-+-+-+-+-+ 187 Figure 1. HSMP LSP Capability Parameter encoding 189 U-bit: Unknown TLV bit, as described in [RFC5036]. The value MUST be 190 1. The unknown TLV MUST be silently ignored and the rest of the 191 message processed as if the unknown TLV did not exist. 193 F-bit: Forward unknown TLV bit, as described in [RFC5036]. The value 194 of this bit MUST be 0 since a Capability Parameter TLV is sent only 195 in Initialization and Capability messages, which are not forwarded. 197 The length SHOULD be 1, and the S bit and reserved bits are defined 198 in [RFC5561] section 3. 200 The HSMP LSP Capability Parameter type is to be assigned by IANA. 202 If the peer has not advertised the corresponding capability, then 203 label messages using the HSMP FEC Element SHOULD NOT be sent to the 204 peer. Since ordered mode is applied for HSMP LSP signalling, the 205 label message break would ensure that the initiating leaf node is 206 unable to establish the upstream path to root node. 208 3.2. HSMP FEC Elements 210 Similar as MP2MP LSP, we define two new protocol entities, the HSMP 211 Downstream FEC Element and Upstream FEC Element. If a FEC TLV 212 contains one of the HSMP FEC Elements, the HSMP FEC Element MUST be 213 the only FEC Element in the FEC TLV. The structure, encoding and 214 error handling for the HSMP Downstream FEC Element and Upstream FEC 215 Element are the same as for the P2MP FEC Element described in 216 [RFC6388] Section 2.2. The difference is that two additional new FEC 217 types are defined: HSMP Downstream FEC (to be assigned by IANA) and 218 HSMP Upstream FEC (to be assigned by IANA). 220 3.3. Using the HSMP FEC Elements 222 In order to describe the message processing clearly, the entries in 223 the list below define the processing of the HSMP FEC Elements. 224 Additionally, the entries defined in [RFC6388] section 3.3 are also 225 reused in the following sections. 227 1. HSMP downstream LSP (or simply downstream ): an HSMP 228 LSP downstream path with root node address X and opaque value Y. 230 2. HSMP upstream LSP (or simply upstream ): an HSMP LSP 231 upstream path for root node address X and opaque value Y which will 232 be used by any of downstream node to send traffic upstream to root 233 node. 235 3. HSMP downstream FEC Element : a FEC Element with root node 236 address X and opaque value Y used for a downstream HSMP LSP. 238 4. HSMP upstream FEC Element : a FEC Element with root node 239 address X and opaque value Y used for an upstream HSMP LSP. 241 5. HSMP-D Label Mapping : A Label Mapping message with a 242 single HSMP downstream FEC Element and label TLV with label L. 243 Label L MUST be allocated from the per-platform label space of the 244 LSR sending the Label Mapping Message. 246 6. HSMP-U Label Mapping : A Label Mapping message with a 247 single HSMP upstream FEC Element and label TLV with label Lu. 248 Label Lu MUST be allocated from the per-platform label space of the 249 LSR sending the Label Mapping Message. 251 7. HSMP-D Label Withdraw : a Label Withdraw message with a 252 FEC TLV with a single HSMP downstream FEC Element and label 253 TLV with label L. 255 8. HSMP-U Label Withdraw : a Label Withdraw message with a 256 FEC TLV with a single HSMP upstream FEC Element and label TLV 257 with label Lu. 259 9. HSMP-D Label Release : a Label Release message with a 260 FEC TLV with a single HSMP downstream FEC Element and Label 261 TLV with label L. 263 10. HSMP-U Label Release : a Label Release message with a 264 FEC TLV with a single HSMP upstream FEC Element and label TLV 265 with label Lu. 267 3.4. HSMP LSP Label Map 269 This section specifies the procedures for originating HSMP Label 270 Mapping messages and processing received HSMP Label Mapping messages 271 for a particular HSMP LSP. The procedure of downstream HSMP LSP is 272 similar as that of downstream MP2MP LSP described in [RFC6388]. When 273 LDP operates in Ordered Label Distribution Control mode [RFC5036], 274 the upstream LSP will be set up by sending HSMP LSP LDP Label Mapping 275 message with a label which is allocated by upstream LSR to its 276 downstream LSR hop by hop from root to leaf node, installing the 277 upstream forwarding table by every node along the LSP. The detail 278 procedure of setting up upstream HSMP LSP is different with that of 279 upstream MP2MP LSP, and is specified in below section. 281 All labels discussed here are downstream-assigned [RFC5332] except 282 those which are assigned using the procedures described in Section 4. 284 Determining the upstream LSR for the HSMP LSP follows the 285 procedure for a P2MP LSP described in [RFC6388] Section 2.4.1.1. 287 That is, a node Z that wants to join an HSMP LSP determines 288 the LDP peer U that is Z's next-hop on the best path from Z to the 289 root node X. If there are multiple upstream LSRs, local algorithm 290 should be applied to ensure that there is a single upstream LSRs for 291 a particular LSP. 293 To determining one's HSMP downstream LSR, an upstream LDP peer which 294 receives a Label Mapping with HSMP downstream FEC Element from an LDP 295 peer D will treat D as HSMP downstream LDP peer. 297 3.4.1. HSMP LSP Leaf Node Operation 299 The leaf node operation is much the same as the operation of MP2MP 300 LSP defined in [RFC6388] Section 3.3.1.4. The only difference is the 301 FEC elements as specified below. 303 A leaf node Z of an HSMP LSP determines its upstream LSR U for 304 as per Section 3.3, allocates a label L, and sends an HSMP-D 305 Label Mapping to U. Leaf node Z expects an HSMP-U Label 306 Mapping from node U and checks whether it already has 307 forwarding state for upstream . If not, Z creates forwarding 308 state to push label Lu onto the traffic that Z wants to forward over 309 the HSMP LSP. How it determines what traffic to forward on this HSMP 310 LSP is outside the scope of this document. 312 3.4.2. HSMP LSP Transit Node Operation 314 The procedure of HSMP-D Label Mapping message is much the same as 315 processing MP2MP-D Label Mapping message defined in [RFC6388] Section 316 3.3.1.5. The processing of HSMP-U Label Mapping message is different 317 with that of MP2MP-U Label Mapping message as specified below. 319 Suppose node Z receives an HSMP-D Label Mapping from LSR D. 320 Z checks whether it has forwarding state for downstream . If 321 not, Z determines its upstream LSR U for as per Section 3.3. 322 Using this Label Mapping to update the label forwarding table MUST 323 NOT be done as long as LSR D is equal to LSR U. If LSR U is different 324 from LSR D, Z will allocate a label L' and install downstream 325 forwarding state to swap label L' with label L over interface I 326 associated with LSR D and send an HSMP-D Label Mapping to 327 U. Interface I is determined via the procedures in Section 3.7. 329 If Z already has forwarding state for downstream , all that Z 330 needs to do in this case is check that LSR D is not equal to the 331 upstream LSR of and update its forwarding state. Assuming its 332 old forwarding state was L'-> { ..., }, its 333 new forwarding state becomes L'-> { ..., , 334 }. If the LSR D is equal to the installed upstream LSR, the 335 Label Mapping from LSR D MUST be retained and MUST NOT update the 336 label forwarding table. 338 Node Z checks if upstream LSR U already has assigned a label Lu to 339 upstream . If not, transit node Z waits until it receives an 340 HSMP-U Label Mapping from LSR U. Once the HSMP-U Label 341 Mapping is received from LSR U, node Z checks whether it already has 342 forwarding state upstream with incoming label Lu' and outgoing 343 label Lu. If it does not, it allocates a label Lu' and creates a new 344 label swap for Lu' with Label Lu over interface Iu. Interface Iu is 345 determined via the procedures in Section 3.7. Node Z determines the 346 downstream HSMP LSR as per Section 4.3.1, and sends an HSMP-U Label 347 Mapping to node D. 349 Since a packet from any downstream node is forwarded only to the 350 upstream node, the same label (representing the upstream path) SHOULD 351 be distributed to all downstream nodes. This differs from the 352 procedures for MP2MP LSPs [RFC6388], where a distinct label must be 353 distributed to each downstream node. The forwarding state upstream 354 on node Z will be like this {, }. Iu means the 355 upstream interface over which Z receives HSMP-U Label Map 356 from LSR U. Packets from any downstream interface over which Z sends 357 HSMP-U Label Map with label Lu' will be forwarded to Iu 358 with label Lu' swap to Lu. 360 3.4.3. HSMP LSP Root Node Operation 362 The procedure of HSMP-D Label Mapping message is much the same as 363 processing MP2MP-D Label Mapping message defined in [RFC6388] Section 364 3.3.1.6. The processing of HSMP-U Label Mapping message is different 365 with that of MP2MP-U Label Mapping message as specified below. 367 Suppose the root node Z receives an HSMP-D Label Mapping 368 from node D. Z checks whether it already has forwarding state for 369 downstream . If not, Z creates downstream forwarding state and 370 installs a outgoing label L over interface I. Interface I is 371 determined via the procedures in Section 3.7. If Z already has 372 forwarding state for downstream , then Z will add label L over 373 interface I to the existing state. 375 Node Z checks if it has forwarding state for upstream . If 376 not, Z creates a forwarding state for incoming label Lu' that 377 indicates that Z is the HSMP LSP egress LER. E.g., the forwarding 378 state might specify that the label stack is popped and the packet 379 passed to some specific application. Node Z determines the 380 downstream HSMP LSR as per Section 3.3, and sends an HSMP-U Label Map 381 to node D. 383 Since Z is the root of the tree, Z will not send an HSMP-D Label Map 384 and will not receive an HSMP-U Label Mapping. 386 Root node could also be a leaf node, and it is able to determine what 387 traffic to forward on this HSMP LSP which is outside the scope of 388 this document. 390 3.5. HSMP LSP Label Withdraw 392 3.5.1. HSMP Leaf Operation 394 If a leaf node Z discovers that it has no need to be an Egress LSR 395 for that LSP (by means outside the scope of this document), then it 396 SHOULD send an HSMP-D Label Withdraw to its upstream LSR U 397 for , where L is the label it had previously advertised to U 398 for . Leaf node Z will also send an unsolicited HSMP-U Label 399 Release to U to indicate that the upstream path is no 400 longer used and that label Lu can be removed. 402 Leaf node Z expects the upstream router U to respond by sending a 403 downstream Label Release for L. 405 3.5.2. HSMP Transit Node Operation 407 If a transit node Z receives an HSMP-D Label Withdraw message from node D, it deletes label L from its forwarding state 409 downstream . Node Z sends an HSMP-D Label Release message with 410 label L to D. There is no need to send an HSMP-U Label Withdraw to D because node D already removed Lu and sent a label 412 release for Lu to Z. 414 If deleting L from Z's forwarding state for downstream results 415 in no state remaining for , then Z propagates the HSMP-D Label 416 Withdraw to its upstream node U for . Z should also 417 check if there are any incoming interface in forwarding state 418 upstream . If all downstream nodes are released and there is 419 no incoming interface, Z should delete the forwarding state upstream 420 and send HSMP-U Label Release message to its upstream node. 421 Otherwise, no HSMP-U Label Release message will be sent to the 422 upstream node. 424 3.5.3. HSMP Root Node Operation 426 When the root node of an HSMP LSP receives an HSMP-D Label Withdraw 427 and HSMP-U Label Release message, the procedure is the same as that 428 for transit nodes, except that the root node will not propagate the 429 Label Withdraw and Label Release upstream (as it has no upstream). 431 3.6. HSMP LSP Upstream LSR Change 433 The procedure for changing the upstream LSR is the same as defined in 434 [RFC6388] Section 2.4.3, only with different processing FEC Element. 436 When the upstream LSR changes from U to U', node Z should set up the 437 HSMP LSP to U' by applying procedures in Section 3.4. Z will 438 also remove HSMP LSP to U by applying procedure in Section 439 3.5. 441 To set up HSMP LSP to U' before/after removing HSMP LSP to U is a 442 local matter, and the recommended default behavior is to remove 443 before adding. 445 3.7. Determining Forwarding Interface 447 The co-routed path between upstream and downstream LSP would be 448 achieved for HSMP LSP. Both LSR U and LSR D would ensure the same 449 interface to send traffic by applying some procedures. For a network 450 with symmetric IGP cost configuration, the following procedure MAY be 451 used. To determine the downstream interface, LSR U MUST do a lookup 452 in the unicast routing table to find the best interface and next-hop 453 to reach LSR D. If the next-hop and interface are also advertised by 454 LSR D via the LDP session, it should be used to transmit the packet 455 to LSR D. Determine the upstream interface mechanism is same as 456 determining the downstream interface by exchanging the role of LSR U 457 and LSR D. If symmetric IGP cost could not be ensured, static route 458 configuration on LSR U and D could also be a possible way to ensure 459 co-routed path. 461 If co-routed is not required for HSMP LSP, the procedure defined in 462 [RFC6388] Section 2.4.1.2 could be applied. LSR U is free to 463 transmit the packet on any of the interfaces to LSR D. The algorithm 464 it uses to choose a particular interface is a local matter. 465 Determine the upstream interface mechanism is the same as determining 466 the downstream interface. 468 4. HSMP LSP on a LAN 470 The procedure to process the downstream HSMP LSP on a LAN is much the 471 same as downstream MP2MP LSP described in [RFC6388] section 6.1.1. 473 When establishing the downstream path of an HSMP LSP, as defined in 474 [RFC6389], a Label Request message for an LSP label is sent to the 475 upstream LSR. The upstream LSR should send Label Mapping message 476 that contains the LSP label for the downstream HSMP FEC and the 477 upstream LSR context label defined in [RFC5331]. When the LSR 478 forwards a packet downstream on one of those LSPs, the packet's top 479 label must be the "upstream LSR context label", and the packet's 480 second label is "LSP label". The HSMP downstream path will be 481 installed in the context-specific forwarding table corresponding to 482 the upstream LSR label. Packets sent by the upstream LSR can be 483 forwarded downstream using this forwarding state based on a two-label 484 lookup. 486 The upstream path of an HSMP LSP on a LAN is the same as the one on 487 other kind of links. That is, the upstream LSR must send Label 488 Mapping message that contains the LSP label for upstream HSMP FEC to 489 downstream node. Packets travelling upstream need to be forwarded in 490 the direction of the root by using the label allocated for upstream 491 HSMP FEC. 493 5. Redundancy Considerations 495 In some scenario, it is necessary to provide two root nodes for 496 redundancy purpose. One way to implement this is to use two 497 independent HSMP LSPs acting as active/standby. At one time, only 498 one HSMP LSP will be active, and the other will be standby. After 499 detecting the failure of active HSMP LSP, the root and leaf nodes 500 will switch the traffic to the standby HSMP LSP which takes on the 501 role as active HSMP LSP. The detail of redundancy mechanism is out 502 of the scope. 504 6. Failure Detection of HSMP LSP 506 The idea of LSP ping for HSMP LSPs could be expressed as an intention 507 to test the LSP Ping Echo Request packets that enter at the root 508 along a particular downstream path of HSMP LSP, and end their MPLS 509 path on the leaf. The leaf node then sends the LSP Ping Echo Reply 510 along the upstream path of HSMP LSP, and end on the root that are the 511 (intended) root node. 513 New sub-TLVs are required to be assigned by IANA in Target FEC Stack 514 TLV to define the corresponding HSMP-upstream FEC type and HSMP- 515 downstream FEC type. In order to ensure the leaf node to send the 516 LSP Ping Echo Reply along the HSMP upstream path, the R bit (Validate 517 Reverse Path) in Global Flags Field defined in [RFC6426] is reused 518 here. 520 The node processing mechanism of LSP Ping Echo Request and Echo Reply 521 for HSMP LSP is inherited from [RFC6425] and [RFC6426] Section 3.4, 522 except the following: 524 1. The root node sending LSP Ping Echo Request message for HSMP LSP 525 MUST attach Target FEC Stack with HSMP downstream FEC, and set R bit 526 to '1' in Global Flags Field. 528 2. When the leaf node receiving the LSP Ping Echo Request, it MUST 529 send the LSP Ping Echo Reply to the associated HSMP upstream path. 530 The Reverse-path Target FEC Stack TLV attached by leaf node in Echo 531 Reply message SHOULD contain the sub-TLV of associated HSMP upstream 532 FEC. 534 7. Security Considerations 536 The same security considerations apply as for the MP2MP LSP described 537 in [RFC6388] and [RFC6425]. 539 Although this document introduces new FEC Elements and corresponding 540 procedures, the protocol does not bring any new security issues 541 compared to [RFC6388] and [RFC6425]. 543 8. IANA Considerations 545 8.1. New LDP FEC Element types 547 This document requires allocation of two new LDP FEC Element types 548 from the "Label Distribution Protocol (LDP) Parameters registry" the 549 "Forwarding Equivalence Class (FEC) Type Name Space": 551 1. the HSMP-upstream FEC type - requested value TBD 553 2. the HSMP-downstream FEC type - requested value TBD 555 The values should be allocated using the lowest free values from the 556 "IETF Consensus"-range (0-127). 558 8.2. HSMP LSP capability TLV 560 This document requires allocation of one new code points for the HSMP 561 LSP capability TLV from "Label Distribution Protocol (LDP) Parameters 562 registry" the "TLV Type Name Space": 564 HSMP LSP Capability Parameter - requested value TBD 566 The value should be allocated from the range 0x0901-0x3DFF (IETF 567 Consensus) using the first free value within this range. 569 8.3. New sub-TLVs for the Target Stack TLV 571 This document requires allocation of two new sub-TLV types for 572 inclusion within the LSP ping [RFC4379] Target FEC Stack TLV (TLV 573 type 1). 575 1. the HSMP-upstream LDP FEC Stack - requested value TBD 577 2. the HSMP-downstream LDP FEC Stack - requested value TBD 579 The value should be allocated from the IETF Standards Action range 580 (0-16383) that is used for mandatory and optional sub-TLVs that 581 requires a response if not understood. The value should be allocated 582 using the lowest free value within this range. 584 9. Acknowledgement 586 The author would like to thank Eric Rosen, Sebastien Jobert, Fei Su, 587 Edward, Mach Chen, Thomas Morin, Loa Andersson for their valuable 588 comments. 590 10. References 592 10.1. Normative references 594 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 595 Requirement Levels", BCP 14, RFC 2119, March 1997. 597 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 598 Label Assignment and Context-Specific Label Space", 599 RFC 5331, August 2008. 601 [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS 602 Multicast Encapsulations", RFC 5332, August 2008. 604 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 605 Le Roux, "LDP Capabilities", RFC 5561, July 2009. 607 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 608 "Label Distribution Protocol Extensions for Point-to- 609 Multipoint and Multipoint-to-Multipoint Label Switched 610 Paths", RFC 6388, November 2011. 612 [RFC6389] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label 613 Assignment for LDP", RFC 6389, November 2011. 615 [RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, 616 S., and T. Nadeau, "Detecting Data-Plane Failures in 617 Point-to-Multipoint MPLS - Extensions to LSP Ping", 618 RFC 6425, November 2011. 620 [RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS 621 On-Demand Connectivity Verification and Route Tracing", 622 RFC 6426, November 2011. 624 10.2. Informative References 626 [I-D.ietf-l2vpn-vpms-frmwk-requirements] 627 Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard, D., 628 and L. Jin, "Framework and Requirements for Virtual 629 Private Multicast Service (VPMS)", 630 draft-ietf-l2vpn-vpms-frmwk-requirements-05 (work in 631 progress), October 2012. 633 [I-D.ietf-pwe3-p2mp-pw] 634 Sivabalan, S., Boutros, S., and L. Martini, "Signaling 635 Root-Initiated Point-to-Multipoint Pseudowire using LDP", 636 draft-ietf-pwe3-p2mp-pw-04 (work in progress), March 2012. 638 [I-D.ietf-tictoc-1588overmpls] 639 Davari, S., Oren, A., Bhatia, M., Roberts, P., and L. 640 Montini, "Transporting Timing messages over MPLS 641 Networks", draft-ietf-tictoc-1588overmpls-05 (work in 642 progress), June 2013. 644 [IEEE1588] 645 "IEEE standard for a precision clock synchronization 646 protocol for networked measurement and control systems", 647 IEEE1588v2 , March 2008. 649 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 650 Thyagarajan, "Internet Group Management Protocol, Version 651 3", RFC 3376, October 2002. 653 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 654 Label Switched (MPLS) Data Plane Failures", RFC 4379, 655 February 2006. 657 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 658 Specification", RFC 5036, October 2007. 660 [RFC6826] Wijnands, IJ., Eckert, T., Leymann, N., and M. Napierala, 661 "Multipoint LDP In-Band Signaling for Point-to-Multipoint 662 and Multipoint-to-Multipoint Label Switched Paths", 663 RFC 6826, January 2013. 665 Authors' Addresses 667 Lizhong Jin 668 Shanghai, China 670 Email: lizho.jin@gmail.com 672 Frederic Jounay 673 France Telecom 674 2, avenue Pierre-Marzin 675 22307 Lannion Cedex, FRANCE 677 Email: frederic.jounay@orange.ch 679 IJsbrand Wijnands 680 Cisco Systems, Inc 681 De kleetlaan 6a 682 Diegem 1831, Belgium 684 Email: ice@cisco.com 686 Nicolai Leymann 687 Deutsche Telekom AG 688 Winterfeldtstrasse 21 689 Berlin 10781 691 Email: N.Leymann@telekom.de