idnits 2.17.1 draft-ietf-mpls-mldp-hsmp-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 16, 2013) is 3844 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) == 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 (~~), 2 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: April 19, 2014 France Telecom 6 I. Wijnands 7 Cisco Systems 8 N. Leymann 9 Deutsche Telekom 10 October 16, 2013 12 LDP Extensions for Hub & Spoke Multipoint Label Switched Path 13 draft-ietf-mpls-mldp-hsmp-03.txt 15 Abstract 17 This draft introduces a hub & spoke multipoint LSP (or HSMP LSP for 18 short), which allows traffic both from root to leaf through P2MP LSP 19 and also leaf to root along the co-routed reverse path. That means 20 traffic entering the HSMP LSP from application/customer at the root 21 node travels downstream to each leaf node, exactly as if it is 22 travelling downstream along a P2MP LSP to each leaf node. Upstream 23 traffic entering the HSMP LSP at any leaf node travels upstream along 24 the tree to the root, as if it is unicast to the root, and strictly 25 follows the downstream path of the tree rather than routing protocol 26 based unicast path to the root. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC2119 [RFC2119]. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 19, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.1. Time Synchronization Scenario . . . . . . . . . . . . . . 5 71 3.2. Virtual Private Multicast Service Scenario . . . . . . . . 5 72 3.3. IPTV Scenario . . . . . . . . . . . . . . . . . . . . . . 5 73 4. Setting up HSMP LSP with LDP . . . . . . . . . . . . . . . . . 6 74 4.1. Support for HSMP LSP Setup with LDP . . . . . . . . . . . 6 75 4.2. HSMP FEC Elements . . . . . . . . . . . . . . . . . . . . 7 76 4.3. Using the HSMP FEC Elements . . . . . . . . . . . . . . . 7 77 4.3.1. HSMP LSP Label Map . . . . . . . . . . . . . . . . . . 8 78 4.3.2. HSMP LSP Label Withdraw . . . . . . . . . . . . . . . 10 79 4.3.3. HSMP LSP Upstream LSR Change . . . . . . . . . . . . . 10 80 5. HSMP LSP on a LAN . . . . . . . . . . . . . . . . . . . . . . 10 81 6. Redundancy Considerations . . . . . . . . . . . . . . . . . . 11 82 7. Co-routed Path Exceptions . . . . . . . . . . . . . . . . . . 11 83 8. Failure Detection of HSMP LSP . . . . . . . . . . . . . . . . 11 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 85 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 86 10.1. New LDP FEC Element types . . . . . . . . . . . . . . . . 12 87 10.2. HSMP LSP capability TLV . . . . . . . . . . . . . . . . . 12 88 10.3. New sub-TLVs for the Target Stack TLV . . . . . . . . . . 13 89 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 90 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 91 12.1. Normative references . . . . . . . . . . . . . . . . . . . 13 92 12.2. Informative References . . . . . . . . . . . . . . . . . . 14 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 95 1. Introduction 97 The point-to-multipoint LSP defined in [RFC6388] allows traffic to 98 transmit from root to several leaf nodes, and multipoint-to- 99 multipoint LSP allows traffic from every node to transmit to every 100 other node. This draft introduces a hub & spoke multipoint LSP (or 101 HSMP LSP for short), which allows traffic both from root to leaf 102 through P2MP LSP and also leaf to root along the co-routed reverse 103 path. That means traffic entering the HSMP LSP at the root node 104 travels downstream, exactly as if it is travelling downstream along a 105 P2MP LSP, and traffic entering the HSMP LSP at any other node travels 106 upstream along the tree to the root. A packet travelling upstream 107 should be thought of as being unicast to the root, except that it 108 follows the path of the tree rather than routing protocol based 109 unicast path to the root. The combination of upstream LSPs initiated 110 from all leaf nodes forms a multipoint-to-point LSP. 112 2. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 This document uses some terms and acronyms as follows: 120 HSMP LSP: hub & spoke multipoint LSP. An LSP allows traffic both 121 from root to leaf through P2MP LSP and also leaf to root along the 122 co-routed reverse path. 124 mLDP: Multipoint extensions for LDP 126 MP2MP LSP: An LSP that connects a set of nodes, such that traffic 127 sent by any node in the LSP is delivered to all others. 129 PTP: The timing and synchronization protocol used by IEEE1588 131 P2MP LSP: An LSP that has one Ingress LSR and one or more Egress 132 LSRs. 134 3. Applications 136 In some cases, the P2MP LSP may not have a reply path for OAM 137 messages (e.g, LSP Ping Echo Request). If P2MP LSP is provided by 138 HSMP LSP instead, then the upstream path could be used as the OAM 139 message reply path. This is especially useful in the case of P2MP 140 LSP fault detection, performance measurement, root node redundancy 141 and etc. There are several other applications that could take 142 advantage of a LDP based HSMP LSP as described below. 144 3.1. Time Synchronization Scenario 146 [IEEE1588] over MPLS is defined in [I-D.ietf-tictoc-1588overmpls]. 147 It is required that the LSP used to transport PTP event message 148 between a Master Clock and a Slave Clock, and the LSP between the 149 same Slave Clock and Master Clock must be co-routed. Using point-to- 150 multipoint technology to transmit PTP event messages from Master 151 Clock at root side to Slave Clock at leaf side will greatly improve 152 the bandwidth usage. Unfortunately current point-to-multipoint LSP 153 only provides unidirectional path from root to leaf, which cannot 154 provides a co-routed reverse path for the PTP event messages. LDP 155 based HSMP LSP described in this draft provides unidirectional point- 156 to-multipoint LSP from root to leaf and co-routed reverse LSP from 157 leaf to root. 159 3.2. Virtual Private Multicast Service Scenario 161 Point to multipoint PW described in [I-D.ietf-pwe3-p2mp-pw] requires 162 to set up reverse path from leaf node (referred as egress PE) to root 163 node (referred as ingress PE), if HSMP LSP is used to multiplex P2MP 164 PW, the reverse path can also be multiplexed to HSMP upstream path to 165 avoid setup independent reverse path. In that case, the operational 166 cost will be reduced for maintaining only one HSMP LSP, instead of 167 P2MP LSP and n (number of leaf nodes) P2P reverse LSPs. 169 The VPMS defined in [I-D.ietf-l2vpn-vpms-frmwk-requirements] requires 170 reverse path from leaf to root node. The P2MP PW multiplexed to HSMP 171 LSP can provide VPMS with reverse path, without introducing 172 independent reverse path from each leaf to root. 174 3.3. IPTV Scenario 176 The mLDP based HSMP LSP can also be applied in a typical IPTV 177 scenario. There is usually only one location with senders but there 178 are many receiver locations. If IGMP is used for signalling between 179 senders as IGMP querier [RFC3376] and receivers, the IGMP messages 180 from the receivers are travelling only from the leaves to the root 181 (and from root towards leaves) but not from leaf to leaf. In 182 addition traffic from the root is only replicated towards the leaves. 183 Then leaf node receiving IGMP report message (for source specific 184 multicast case) will join HSMP LSP(use similar mechanism in [RFC6826] 185 section 2), and then send IGMP report message upstream to root along 186 HSMP upstream LSP. Note that in above case, there is no node 187 redundancy for IGMP querier. And the node redundancy for IGMP 188 querier[RFC3376] could be provided by two independent VPMS instances 189 with HSMP applied. 191 4. Setting up HSMP LSP with LDP 193 HSMP LSP is similar with MP2MP LSP described in [RFC6388], with the 194 difference that the leaf LSRs can only send traffic to root node 195 along the same path of traffic from root node to leaf node. 197 HSMP LSP consists of a downstream path and upstream path. The 198 downstream path is same as MP2MP LSP, while the upstream path is only 199 from leaf to root node, without communication between leaf and leaf 200 nodes. The transmission of packets from the root node of an HSMP LSP 201 to the receivers is identical to that of a P2MP LSP. Traffic from a 202 leaf node follows the upstream path toward the root node, along a 203 path that traverse the same nodes as the downstream node, but in 204 reverse order. 206 For setting up the upstream path of an HSMP LSP, ordered mode MUST be 207 used which is same as MP2MP. Ordered mode can guarantee a leaf to 208 start sending packets to root immediately after the upstream path is 209 installed, without being dropped due to an incomplete LSP. 211 Due to much of similar behaviors between HSMP LSP and MP2MP LSP, the 212 following sections only describe the difference between the two 213 entities. 215 4.1. Support for HSMP LSP Setup with LDP 217 HSMP LSP requires the LDP capabilities [RFC5561] for nodes to 218 indicate that they support setup of HSMP LSPs. An implementation 219 supporting the HSMP LSP procedures specified in this document MUST 220 implement the procedures for Capability Parameters in Initialization 221 Messages. Advertisement of the HSMP LSP Capability indicates support 222 of the procedures for HSMP LSP setup. 224 A new Capability Parameter TLV is defined, the HSMP LSP Capability 225 Parameter. Following is the format of the HSMP LSP Capability 226 Parameter. 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 |1|0| HSMP LSP Cap(TBD IANA) | Length | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 |S| Reserved | 234 +-+-+-+-+-+-+-+-+ 235 Figure 1. HSMP LSP Capability Parameter encoding 237 The length SHOULD be 1, and the S bit and reserved bits are defined 238 in [RFC5561] section 3. 240 The HSMP LSP Capability Parameter type is to be assigned by IANA. 242 4.2. HSMP FEC Elements 244 Similar as MP2MP LSP, we define two new protocol entities, the HSMP 245 Downstream FEC Element and Upstream FEC Element. If a FEC TLV 246 contains one of the HSMP FEC Elements, the HSMP FEC Element MUST be 247 the only FEC Element in the FEC TLV. The structure, encoding and 248 error handling for the HSMP Downstream FEC Element and Upstream FEC 249 Element are the same as for the MP2MP FEC Element described in 250 [RFC6388] Section 3.2. The difference is that two additional new FEC 251 types are defined: HSMP Downstream FEC (TBD, IANA) and HSMP Upstream 252 FEC(TBD, IANA). 254 4.3. Using the HSMP FEC Elements 256 In order to describe the message processing clearly, the entries in 257 the list below define the processing of the HSMP FEC Elements. 258 Additionally, the entries defined in [RFC6388] section 3.3 are also 259 reused in the following sections. 261 1. HSMP downstream LSP (or simply downstream ): an HSMP 262 LSP downstream path with root node address X and opaque value Y. 264 2. HSMP upstream LSP (or simply upstream ): an HSMP LSP 265 upstream path for root node address X and opaque value Y which will 266 be used by any of downstream node to send traffic upstream to root 267 node. 269 3. HSMP downstream FEC Element : a FEC Element with root node 270 address X and opaque value Y used for a downstream HSMP LSP. 272 4. HSMP upstream FEC Element : a FEC Element with root node 273 address X and opaque value Y used for an upstream HSMP LSP. 275 5. HSMP-D Label Mapping : A Label Mapping message with a 276 single HSMP downstream FEC Element and label TLV with label L. 277 Label L MUST be allocated from the per-platform label space of the 278 LSR sending the Label Mapping Message. 280 6. HSMP-U Label Mapping : A Label Mapping message with a 281 single HSMP upstream FEC Element and label TLV with label Lu. 282 Label Lu MUST be allocated from the per-platform label space of the 283 LSR sending the Label Mapping Message. 285 4.3.1. HSMP LSP Label Map 287 This section specifies the procedures for originating HSMP Label 288 Mapping messages and processing received HSMP Label Mapping messages 289 for a particular HSMP LSP. The procedure of downstream HSMP LSP is 290 same as that of downstream MP2MP LSP described in [RFC6388]. When 291 LDP operates in Ordered Label Distribution Control mode [RFC5036], 292 the upstream LSP will be set up by sending HSMP LSP LDP Label Mapping 293 message with a label which is allocated by upstream LSR to its 294 downstream LSR hop by hop from root to leaf node, installing the 295 upstream forwarding table by every node along the LSP. The detail 296 procedure of setting up upstream HSMP LSP is different with that of 297 upstream MP2MP LSP, and is specified in below section. 299 All labels discussed here are downstream-assigned [RFC5332] except 300 those which are assigned using the procedures described in section 5. 302 Determining the upstream LSR for the HSMP LSP follows the 303 procedure for a MP2MP LSP described in [RFC6388] Section 3.3.1.1. 305 Determining one's HSMP downstream LSR follows the procedure defined 306 in [RFC6388] section 3.3.1.2. That is, an upstream LDP peer which 307 receives a Label Mapping with HSMP downstream FEC Element from an LDP 308 peer D will treat D as HSMP downstream LDP peer. 310 Determining the forwarding interface to an LSR follows the procedure 311 as defined in [RFC6388] section 2.4.1.2. 313 4.3.1.1. HSMP LSP Leaf Node Operation 315 The leaf node operation is same as the operation of MP2MP LSP defined 316 in [RFC6388] section 3.3.1.4. The only difference is the FEC 317 elements as specified below. 319 A leaf node Z will send an HSMP-D Label Mapping to U, 320 instead of MP2MP-D Label Mapping , and expects an HSMP-U 321 Label Mapping from node U and checks whether it already 322 has forwarding state for upstream . The created forwarding 323 state on leaf node Z is same as the leaf node of MP2MP LSP. Z will 324 push label Lu onto the traffic that Z wants to forward over the HSMP 325 LSP. 327 4.3.1.2. HSMP LSP Transit Node Operation 329 Suppose node Z receives an HSMP-D Label Mapping from LSR D, 330 the procedure is much the same as processing MP2MP-D Label Mapping 331 message defined in [RFC6388] section 3.3.1.5, and the processing 332 protocol entity is HSMP-D Label Mapping message. The only difference 333 is specified below. 335 Node Z checks if upstream LSR U already has assigned a label Lu to 336 upstream . If not, transit node Z waits until it receives an 337 HSMP-U Label Mapping from LSR U. Once the HSMP-U Label 338 Mapping is received from LSR U, node Z checks whether it already has 339 forwarding state upstream with incoming label Lu' and outgoing 340 label Lu. If it does, Z sends an HSMP-U Label Mapping to 341 downstream node. If it does not, it allocates a label Lu' and 342 creates a new label swap for Lu' with Label Lu over interface Iu. 343 Interface Iu is determined via the procedures in section 4.3.1. Node 344 Z determines the downstream HSMP LSR as per section 4.3.1, and sends 345 an HSMP-U Label Mapping to node D. 347 Since a packet from any downstream node is forwarded only to the 348 upstream node, the same label (representing the upstream path) SHOULD 349 be distributed to all downstream nodes. This differs from the 350 procedures for MP2MP LSPs [RFC6388], where a distinct label must be 351 distributed to each downstream node. The forwarding state upstream 352 on node Z will be like this {, }. Iu means the 353 upstream interface over which Z receives HSMP-U Label Map 354 from LSR U. Packets from any downstream interface over which Z sends 355 HSMP-U Label Map with label Lu' will be forwarded to Iu 356 with label Lu' swap to Lu. 358 4.3.1.3. HSMP LSP Root Node Operation 360 Suppose root node Z receives an HSMP-D Label Mapping from 361 node D, the procedure is much the same as processing MP2MP-D Label 362 Mapping message defined in [RFC6388] section 3.3.1.6, and the 363 processing protocol entity is HSMP-D Label Mapping message. The only 364 difference is specified below. 366 Node Z checks if it has forwarding state for upstream . If 367 not, Z creates a forwarding state for incoming label Lu' that 368 indicates that Z is the LSP egress. E.g., the forwarding state might 369 specify that the label stack is popped and the packet passed to some 370 specific application. Node Z determines the downstream HSMP LSR as 371 per section 4.3.1, and sends an HSMP-U Label Map to node 372 D. 374 Since Z is the root of the tree, Z will not send an HSMP-D Label Map 375 and will not receive an HSMP-U Label Mapping. 377 4.3.2. HSMP LSP Label Withdraw 379 The HSMP Label Withdraw procedure is much the same as MP2MP leaf 380 operation defined in [RFC6388] section 3.3.2, and the processing FEC 381 Elements are HSMP FEC Elements. The only difference is the process 382 of HSMP-U Label Release message, which is specified below. 384 When a transit node Z receives an HSMP-U Label Release message from 385 downstream node D, Z should check if there are any incoming interface 386 in forwarding state upstream . If all downstream nodes are 387 released and there is no incoming interface, Z should delete the 388 forwarding state upstream and send HSMP-U Label Release 389 message to its upstream node. Otherwise, no HSMP-U Label Release 390 message will be sent to the upstream node. 392 4.3.3. HSMP LSP Upstream LSR Change 394 The procedure for changing the upstream LSR is the same as defined in 395 [RFC6388] section 3.3.3, only with different processing FEC Element, 396 the HSMP FEC Element. 398 5. HSMP LSP on a LAN 400 The procedure to process the downstream HSMP LSP on a LAN is much the 401 same as downstream MP2MP LSP described in [RFC6388] section 6.1.1. 403 When establishing the downstream path of an HSMP LSP, as defined in 404 [RFC6389], a Label Request message for an LSP label is sent to the 405 upstream LSR. The upstream LSR should send Label Mapping message 406 that contains the LSP label for the downstream HSMP FEC and the 407 upstream LSR context label defined in [RFC5331]. When the LSR 408 forwards a packet downstream on one of those LSPs, the packet's top 409 label must be the "upstream LSR context label", and the packet's 410 second label is "LSP label". The HSMP downstream path will be 411 installed in the context-specific forwarding table corresponding to 412 the upstream LSR label. Packets sent by the upstream LSR can be 413 forwarded downstream using this forwarding state based on a two-label 414 lookup. 416 The upstream path of an HSMP LSP on a LAN is the same as the one on 417 other kind of links. That is, the upstream LSR must send Label 418 Mapping message that contains the LSP label for upstream HSMP FEC to 419 downstream node. Packets travelling upstream need to be forwarded in 420 the direction of the root by using the label allocated for upstream 421 HSMP FEC. 423 6. Redundancy Considerations 425 In some scenario, it is necessary to provide two root nodes for 426 redundancy purpose. One way to implement this is to use two 427 independent HSMP LSPs acting as active/standby. At one time, only 428 one HSMP LSP will be active, and the other will be standby. After 429 detecting the failure of active HSMP LSP, the root and leaf nodes 430 will switch the traffic to the standby HSMP LSP which takes on the 431 role as active HSMP LSP. The detail of redundancy mechanism is out 432 of the scope. 434 7. Co-routed Path Exceptions 436 There are some exceptional cases when mLDP based HSMP LSP could not 437 achieve co-routed path. One possible case is using static routing 438 between LDP neighbors; another possible case is IGP cost asymmetric 439 generated by physical link cost asymmetric, or TE-Tunnels used 440 between LDP neighbors. The LSR/LER in HSMP LSP should detect if the 441 path is co-routed or not. If not co-routed, an alarm indication 442 should be generated to the management system. 444 8. Failure Detection of HSMP LSP 446 The idea of LSP ping for HSMP LSPs could be expressed as an intention 447 to test the LSP Ping Echo Request packets that enter at the root 448 along a particular downstream path of HSMP LSP, and end their MPLS 449 path on the leaf. The leaf node then sends the LSP Ping Echo Reply 450 along the co-routed upstream path of HSMP LSP, and end on the root 451 that are the (intended) root node. 453 New sub-TLVs are required to be assigned by IANA in Target FEC Stack 454 TLV to define the corresponding HSMP-upstream FEC type and HSMP- 455 downstream FEC type. In order to ensure the leaf node to send the 456 LSP Ping Echo Reply along the HSMP upstream path, the R bit (Validate 457 Reverse Path) in Global Flags Field defined in [RFC6426] is reused 458 here. 460 The node processing mechanism of LSP Ping Echo Request and Echo Reply 461 for HSMP LSP is inherited from [RFC6425] and [RFC6426] section 3.4, 462 except the following: 464 1. The root node sending LSP Ping Echo Request message for HSMP LSP 465 MUST attach Target FEC Stack with HSMP downstream FEC, and set R bit 466 to '1' in Global Flags Field. 468 2. When the leaf node receiving the LSP Ping Echo Request, it MUST 469 send the LSP Ping Echo Reply to the associated HSMP upstream path. 470 The Reverse-path Target FEC Stack TLV attached by leaf node in Echo 471 Reply message SHOULD contain the sub-TLV of associated HSMP upstream 472 FEC. 474 9. Security Considerations 476 The same security considerations apply as for the MP2MP LSP described 477 in [RFC6388] and [RFC6425]. 479 Although this document introduces new FEC Elements and corresponding 480 procedures, the protocol does not bring any new security issues 481 compared to [RFC6388] and [RFC6425]. 483 10. IANA Considerations 485 10.1. New LDP FEC Element types 487 This document requires allocation of two new LDP FEC Element types 488 from the "Label Distribution Protocol (LDP) Parameters registry" the 489 "Forwarding Equivalence Class (FEC) Type Name Space": 491 1. the HSMP-upstream FEC type - requested value TBD 493 2. the HSMP-downstream FEC type - requested value TBD 495 The values should be allocated using the lowest free values from the 496 "IETF Consensus"-range (0-127). 498 10.2. HSMP LSP capability TLV 500 This document requires allocation of one new code points for the HSMP 501 LSP capability TLV from "Label Distribution Protocol (LDP) Parameters 502 registry" the "TLV Type Name Space": 504 HSMP LSP Capability Parameter - requested value TBD 506 The value should be allocated from the range 0x0901-0x3DFF (IETF 507 Consensus) using the first free value within this range. 509 10.3. New sub-TLVs for the Target Stack TLV 511 This document requires allocation of two new sub-TLV types for 512 inclusion within the LSP ping [RFC4379] Target FEC Stack TLV (TLV 513 type 1). 515 1. the HSMP-upstream LDP FEC Stack - requested value TBD 517 2. the HSMP-downstream LDP FEC Stack - requested value TBD 519 The value should be allocated from the IETF Standards Action range 520 (0-16383) that is used for mandatory and optional sub-TLVs that 521 requires a response if not understood. The value should be allocated 522 using the lowest free value within this range. 524 11. Acknowledgement 526 The author would like to thank Eric Rosen, Sebastien Jobert, Fei Su, 527 Edward, Mach Chen, Thomas Morin, Loa Andersson for their valuable 528 comments. 530 12. References 532 12.1. Normative references 534 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 535 Requirement Levels", BCP 14, RFC 2119, March 1997. 537 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 538 Label Assignment and Context-Specific Label Space", 539 RFC 5331, August 2008. 541 [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS 542 Multicast Encapsulations", RFC 5332, August 2008. 544 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 545 Le Roux, "LDP Capabilities", RFC 5561, July 2009. 547 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 548 "Label Distribution Protocol Extensions for Point-to- 549 Multipoint and Multipoint-to-Multipoint Label Switched 550 Paths", RFC 6388, November 2011. 552 [RFC6389] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label 553 Assignment for LDP", RFC 6389, November 2011. 555 [RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, 556 S., and T. Nadeau, "Detecting Data-Plane Failures in 557 Point-to-Multipoint MPLS - Extensions to LSP Ping", 558 RFC 6425, November 2011. 560 [RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS 561 On-Demand Connectivity Verification and Route Tracing", 562 RFC 6426, November 2011. 564 12.2. Informative References 566 [I-D.ietf-l2vpn-vpms-frmwk-requirements] 567 Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard, D., 568 and L. Jin, "Framework and Requirements for Virtual 569 Private Multicast Service (VPMS)", 570 draft-ietf-l2vpn-vpms-frmwk-requirements-05 (work in 571 progress), October 2012. 573 [I-D.ietf-pwe3-p2mp-pw] 574 Sivabalan, S., Boutros, S., and L. Martini, "Signaling 575 Root-Initiated Point-to-Multipoint Pseudowire using LDP", 576 draft-ietf-pwe3-p2mp-pw-04 (work in progress), March 2012. 578 [I-D.ietf-tictoc-1588overmpls] 579 Davari, S., Oren, A., Bhatia, M., Roberts, P., and L. 580 Montini, "Transporting Timing messages over MPLS 581 Networks", draft-ietf-tictoc-1588overmpls-05 (work in 582 progress), June 2013. 584 [IEEE1588] 585 "IEEE standard for a precision clock synchronization 586 protocol for networked measurement and control systems", 587 IEEE1588v2 , March 2008. 589 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 590 Thyagarajan, "Internet Group Management Protocol, Version 591 3", RFC 3376, October 2002. 593 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 594 Label Switched (MPLS) Data Plane Failures", RFC 4379, 595 February 2006. 597 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 598 Specification", RFC 5036, October 2007. 600 [RFC6826] Wijnands, IJ., Eckert, T., Leymann, N., and M. Napierala, 601 "Multipoint LDP In-Band Signaling for Point-to-Multipoint 602 and Multipoint-to-Multipoint Label Switched Paths", 603 RFC 6826, January 2013. 605 Authors' Addresses 607 Lizhong Jin 608 Shanghai, China 610 Email: lizho.jin@gmail.com 612 Frederic Jounay 613 France Telecom 614 2, avenue Pierre-Marzin 615 22307 Lannion Cedex, FRANCE 617 Email: frederic.jounay@orange.ch 619 IJsbrand Wijnands 620 Cisco Systems, Inc 621 De kleetlaan 6a 622 Diegem 1831, Belgium 624 Email: ice@cisco.com 626 Nicolai Leymann 627 Deutsche Telekom AG 628 Winterfeldtstrasse 21 629 Berlin 10781 631 Email: N.Leymann@telekom.de