idnits 2.17.1 draft-ietf-mpls-mldp-hsmp-02.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 11, 2013) is 3842 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: 'RFC4762' is defined on line 577, but no explicit reference was found in the text == Unused Reference: 'RFC6374' is defined on line 584, 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 (~~), 4 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 14, 2014 France Telecom 6 I. Wijnands 7 Cisco Systems 8 N. Leymann 9 Deutsche Telekom 10 October 11, 2013 12 LDP Extensions for Hub & Spoke Multipoint Label Switched Path 13 draft-ietf-mpls-mldp-hsmp-02.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 14, 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 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 87 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 12.1. Normative references . . . . . . . . . . . . . . . . . . . 13 89 12.2. Informative References . . . . . . . . . . . . . . . . . . 13 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 92 1. Introduction 94 The point-to-multipoint LSP defined in [RFC6388] allows traffic to 95 transmit from root to several leaf nodes, and multipoint-to- 96 multipoint LSP allows traffic from every node to transmit to every 97 other node. This draft introduces a hub & spoke multipoint LSP (or 98 HSMP LSP for short), which allows traffic both from root to leaf 99 through P2MP LSP and also leaf to root along the co-routed reverse 100 path. That means traffic entering the HSMP LSP at the root node 101 travels downstream, exactly as if it is travelling downstream along a 102 P2MP LSP, and traffic entering the HSMP LSP at any other node travels 103 upstream along the tree to the root. A packet travelling upstream 104 should be thought of as being unicast to the root, except that it 105 follows the path of the tree rather than routing protocol based 106 unicast path to the root. The combination of upstream LSPs initiated 107 from all leaf nodes forms a multipoint-to-point LSP. 109 2. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 This document uses some terms and acronyms as follows: 117 HSMP LSP: hub & spoke multipoint LSP. An LSP allows traffic both 118 from root to leaf through P2MP LSP and also leaf to root along the 119 co-routed reverse path. 121 mLDP: Multipoint extensions for LDP 123 MP2MP LSP: An LSP that connects a set of nodes, such that traffic 124 sent by any node in the LSP is delivered to all others. 126 PTP: The timing and synchronization protocol used by IEEE1588 128 P2MP LSP: An LSP that has one Ingress LSR and one or more Egress 129 LSRs. 131 3. Applications 133 In some cases, the P2MP LSP may not have a reply path for OAM 134 messages (e.g, LSP Ping Echo Request). If P2MP LSP is provided by 135 HSMP LSP instead, then the upstream path could be used as the OAM 136 message reply path. This is especially useful in the case of P2MP 137 LSP fault detection, performance measurement, root node redundancy 138 and etc. There are several other applications that could take 139 advantage of a LDP based HSMP LSP as described below. 141 3.1. Time Synchronization Scenario 143 [IEEE1588] over MPLS is defined in [I-D.ietf-tictoc-1588overmpls]. 144 It is required that the LSP used to transport PTP event message 145 between a Master Clock and a Slave Clock, and the LSP between the 146 same Slave Clock and Master Clock must be co-routed. Using point-to- 147 multipoint technology to transmit PTP event messages from Master 148 Clock at root side to Slave Clock at leaf side will greatly improve 149 the bandwidth usage. Unfortunately current point-to-multipoint LSP 150 only provides unidirectional path from root to leaf, which cannot 151 provides a co-routed reverse path for the PTP event messages. LDP 152 based HSMP LSP described in this draft provides unidirectional point- 153 to-multipoint LSP from root to leaf and co-routed reverse LSP from 154 leaf to root. 156 3.2. Virtual Private Multicast Service Scenario 158 Point to multipoint PW described in [I-D.ietf-pwe3-p2mp-pw] requires 159 to set up reverse path from leaf node (referred as egress PE) to root 160 node (referred as ingress PE), if HSMP LSP is used to multiplex P2MP 161 PW, the reverse path can also be multiplexed to HSMP upstream path to 162 avoid setup independent reverse path. In that case, the operational 163 cost will be reduced for maintaining only one HSMP LSP, instead of 164 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 leaf to root node. The P2MP PW multiplexed to HSMP 168 LSP can provide VPMS with reverse path, without introducing 169 independent reverse path from each leaf to root. 171 3.3. IPTV Scenario 173 The mLDP based HSMP LSP can also be applied in a typical IPTV 174 scenario. There is usually only one location with senders but there 175 are many receiver locations. If IGMP is used for signalling between 176 senders as IGMP querier [RFC3376] and receivers, the IGMP messages 177 from the receivers are travelling only from the leaves to the root 178 (and from root towards leaves) but not from leaf to leaf. In 179 addition traffic from the root is only replicated towards the leaves. 180 Then leaf node receiving IGMP report message (for source specific 181 multicast case) will join HSMP LSP(use similar mechanism in [RFC6826] 182 section 2), and then send IGMP report message upstream to root along 183 HSMP upstream LSP. Note that in above case, there is no node 184 redundancy for IGMP querier. And the node redundancy for IGMP 185 querier[RFC3376] could be provided by two independent VPMS instances 186 with HSMP applied. 188 4. Setting up HSMP LSP with LDP 190 HSMP LSP is similar with MP2MP LSP described in [RFC6388], with the 191 difference that the leaf LSRs can only send traffic to root node 192 along the same path of traffic from root node to leaf node. 194 HSMP LSP consists of a downstream path and upstream path. The 195 downstream path is same as MP2MP LSP, while the upstream path is only 196 from leaf to root node, without communication between leaf and leaf 197 nodes. The transmission of packets from the root node of an HSMP LSP 198 to the receivers is identical to that of a P2MP LSP. Traffic from a 199 leaf node follows the upstream path toward the root node, along a 200 path that traverse the same nodes as the downstream node, but in 201 reverse order. 203 For setting up the upstream path of an HSMP LSP, ordered mode MUST be 204 used which is same as MP2MP. Ordered mode can guarantee a leaf to 205 start sending packets to root immediately after the upstream path is 206 installed, without being dropped due to an incomplete LSP. 208 Due to much of similar behaviors between HSMP LSP and MP2MP LSP, the 209 following sections only describe the difference between the two 210 entities. 212 4.1. Support for HSMP LSP Setup with LDP 214 HSMP LSP requires the LDP capabilities [RFC5561] for nodes to 215 indicate that they support setup of HSMP LSPs. An implementation 216 supporting the HSMP LSP procedures specified in this document MUST 217 implement the procedures for Capability Parameters in Initialization 218 Messages. Advertisement of the HSMP LSP Capability indicates support 219 of the procedures for HSMP LSP setup. 221 A new Capability Parameter TLV is defined, the HSMP LSP Capability 222 Parameter. Following is the format of the HSMP LSP Capability 223 Parameter. 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 |1|0| HSMP LSP Cap(TBD IANA) | Length | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 |S| Reserved | 231 +-+-+-+-+-+-+-+-+ 232 Figure 1. HSMP LSP Capability Parameter encoding 234 The length SHOULD be 1, and the S bit and reserved bits are defined 235 in [RFC5561] section 3. 237 The HSMP LSP Capability Parameter type is to be assigned by IANA. 239 4.2. HSMP FEC Elements 241 Similar as MP2MP LSP, we define two new protocol entities, the HSMP 242 Downstream FEC Element and Upstream FEC Element. If a FEC TLV 243 contains one of the HSMP FEC Elements, the HSMP FEC Element MUST be 244 the only FEC Element in the FEC TLV. The structure, encoding and 245 error handling for the HSMP Downstream FEC Element and Upstream FEC 246 Element are the same as for the MP2MP FEC Element described in 247 [RFC6388] Section 3.2. The difference is that two additional new FEC 248 types are defined: HSMP Downstream FEC (TBD, IANA) and HSMP Upstream 249 FEC(TBD, IANA). 251 4.3. Using the HSMP FEC Elements 253 In order to describe the message processing clearly, the entries in 254 the list below define the processing of the HSMP FEC Elements. 255 Additionally, the entries defined in [RFC6388] section 3.3 are also 256 reused in the following sections. 258 1. HSMP downstream LSP (or simply downstream ): an HSMP 259 LSP downstream path with root node address X and opaque value Y. 261 2. HSMP upstream LSP (or simply upstream ): an HSMP LSP 262 upstream path for root node address X and opaque value Y which will 263 be used by any of downstream node to send traffic upstream to root 264 node. 266 3. HSMP downstream FEC Element : a FEC Element with root node 267 address X and opaque value Y used for a downstream HSMP LSP. 269 4. HSMP upstream FEC Element : a FEC Element with root node 270 address X and opaque value Y used for an upstream HSMP LSP. 272 5. HSMP-D Label Mapping : A Label Mapping message with a 273 single HSMP downstream FEC Element and label TLV with label L. 274 Label L MUST be allocated from the per-platform label space of the 275 LSR sending the Label Mapping Message. 277 6. HSMP-U Label Mapping : A Label Mapping message with a 278 single HSMP upstream FEC Element and label TLV with label Lu. 279 Label Lu MUST be allocated from the per-platform label space of the 280 LSR sending the Label Mapping Message. 282 4.3.1. HSMP LSP Label Map 284 This section specifies the procedures for originating HSMP Label 285 Mapping messages and processing received HSMP Label Mapping messages 286 for a particular HSMP LSP. The procedure of downstream HSMP LSP is 287 same as that of downstream MP2MP LSP described in [RFC6388]. When 288 LDP operates in Ordered Label Distribution Control mode [RFC5036], 289 the upstream LSP will be set up by sending HSMP LSP LDP Label Mapping 290 message with a label which is allocated by upstream LSR to its 291 downstream LSR hop by hop from root to leaf node, installing the 292 upstream forwarding table by every node along the LSP. The detail 293 procedure of setting up upstream HSMP LSP is different with that of 294 upstream MP2MP LSP, and is specified in below section. 296 All labels discussed here are downstream-assigned [RFC5332] except 297 those which are assigned using the procedures described in section 5. 299 Determining the upstream LSR for the HSMP LSP follows the 300 procedure for a MP2MP LSP described in [RFC6388] Section 3.3.1.1. 302 Determining one's HSMP downstream LSR follows the procedure defined 303 in [RFC6388] section 3.3.1.2. That is, an upstream LDP peer which 304 receives a Label Mapping with HSMP downstream FEC Element from an LDP 305 peer D will treat D as HSMP downstream LDP peer. 307 Determining the forwarding interface to an LSR follows the procedure 308 as defined in [RFC6388] section 2.4.1.2. 310 4.3.1.1. HSMP LSP Leaf Node Operation 312 The leaf node operation is same as the operation of MP2MP LSP defined 313 in [RFC6388] section 3.3.1.4. The only difference is the FEC 314 elements as specified below. 316 A leaf node Z will send an HSMP-D Label Mapping to U, 317 instead of MP2MP-D Label Mapping , and expects an HSMP-U 318 Label Mapping from node U and checks whether it already 319 has forwarding state for upstream . The created forwarding 320 state on leaf node Z is same as the leaf node of MP2MP LSP. Z will 321 push label Lu onto the traffic that Z wants to forward over the HSMP 322 LSP. 324 4.3.1.2. HSMP LSP Transit Node Operation 326 Suppose node Z receives an HSMP-D Label Mapping from LSR D, 327 the procedure is much the same as processing MP2MP-D Label Mapping 328 message defined in [RFC6388] section 3.3.1.5, and the processing 329 protocol entity is HSMP-D Label Mapping message. The only difference 330 is specified below. 332 Node Z checks if upstream LSR U already has assigned a label Lu to 333 upstream . If not, transit node Z waits until it receives an 334 HSMP-U Label Mapping from LSR U. Once the HSMP-U Label 335 Mapping is received from LSR U, node Z checks whether it already has 336 forwarding state upstream with incoming label Lu' and outgoing 337 label Lu. If it does, Z sends an HSMP-U Label Mapping to 338 downstream node. If it does not, it allocates a label Lu' and 339 creates a new label swap for Lu' with Label Lu over interface Iu. 340 Interface Iu is determined via the procedures in section 4.3.1. Node 341 Z determines the downstream HSMP LSR as per section 4.3.1, and sends 342 an HSMP-U Label Mapping to node D. 344 Since a packet from any downstream node is forwarded only to the 345 upstream node, the same label (representing the upstream path) SHOULD 346 be distributed to all downstream nodes. This differs from the 347 procedures for MP2MP LSPs [RFC6388], where a distinct label must be 348 distributed to each downstream node. The forwarding state upstream 349 on node Z will be like this {, }. Iu means the 350 upstream interface over which Z receives HSMP-U Label Map 351 from LSR U. Packets from any downstream interface over which Z sends 352 HSMP-U Label Map with label Lu' will be forwarded to Iu 353 with label Lu' swap to Lu. 355 4.3.1.3. HSMP LSP Root Node Operation 357 Suppose root node Z receives an HSMP-D Label Mapping from 358 node D, the procedure is much the same as processing MP2MP-D Label 359 Mapping message defined in [RFC6388] section 3.3.1.6, and the 360 processing protocol entity is HSMP-D Label Mapping message. The only 361 difference is specified below. 363 Node Z checks if it has forwarding state for upstream . If 364 not, Z creates a forwarding state for incoming label Lu' that 365 indicates that Z is the LSP egress. E.g., the forwarding state might 366 specify that the label stack is popped and the packet passed to some 367 specific application. Node Z determines the downstream HSMP LSR as 368 per section 4.3.1, and sends an HSMP-U Label Map to node 369 D. 371 Since Z is the root of the tree, Z will not send an HSMP-D Label Map 372 and will not receive an HSMP-U Label Mapping. 374 4.3.2. HSMP LSP Label Withdraw 376 The HSMP Label Withdraw procedure is much the same as MP2MP leaf 377 operation defined in [RFC6388] section 3.3.2, and the processing FEC 378 Elements are HSMP FEC Elements. The only difference is the process 379 of HSMP-U Label Release message, which is specified below. 381 When a transit node Z receives an HSMP-U Label Release message from 382 downstream node D, Z should check if there are any incoming interface 383 in forwarding state upstream . If all downstream nodes are 384 released and there is no incoming interface, Z should delete the 385 forwarding state upstream and send HSMP-U Label Release 386 message to its upstream node. Otherwise, no HSMP-U Label Release 387 message will be sent to the upstream node. 389 4.3.3. HSMP LSP Upstream LSR Change 391 The procedure for changing the upstream LSR is the same as defined in 392 [RFC6388] section 3.3.3, only with different processing FEC Element, 393 the HSMP FEC Element. 395 5. HSMP LSP on a LAN 397 The procedure to process the downstream HSMP LSP on a LAN is much the 398 same as downstream MP2MP LSP described in [RFC6388] section 6.1.1. 400 When establishing the downstream path of an HSMP LSP, as defined in 401 [RFC6389], a Label Request message for an LSP label is sent to the 402 upstream LSR. The upstream LSR should send Label Mapping message 403 that contains the LSP label for the downstream HSMP FEC and the 404 upstream LSR context label defined in [RFC5331]. When the LSR 405 forwards a packet downstream on one of those LSPs, the packet's top 406 label must be the "upstream LSR context label", and the packet's 407 second label is "LSP label". The HSMP downstream path will be 408 installed in the context-specific forwarding table corresponding to 409 the upstream LSR label. Packets sent by the upstream LSR can be 410 forwarded downstream using this forwarding state based on a two-label 411 lookup. 413 The upstream path of an HSMP LSP on a LAN is the same as the one on 414 other kind of links. That is, the upstream LSR must send Label 415 Mapping message that contains the LSP label for upstream HSMP FEC to 416 downstream node. Packets travelling upstream need to be forwarded in 417 the direction of the root by using the label allocated for upstream 418 HSMP FEC. 420 6. Redundancy Considerations 422 In some scenario, it is necessary to provide two root nodes for 423 redundancy purpose. One way to implement this is to use two 424 independent HSMP LSPs acting as active/standby. At one time, only 425 one HSMP LSP will be active, and the other will be standby. After 426 detecting the failure of active HSMP LSP, the root and leaf nodes 427 will switch the traffic to the standby HSMP LSP which takes on the 428 role as active HSMP LSP. The detail of redundancy mechanism is out 429 of the scope. 431 7. Co-routed Path Exceptions 433 There are some exceptional cases when mLDP based HSMP LSP could not 434 achieve co-routed path. One possible case is using static routing 435 between LDP neighbors; another possible case is IGP cost asymmetric 436 generated by physical link cost asymmetric, or TE-Tunnels used 437 between LDP neighbors. The LSR/LER in HSMP LSP should detect if the 438 path is co-routed or not. If not co-routed, an alarm indication 439 should be generated to the management system. 441 8. Failure Detection of HSMP LSP 443 The idea of LSP ping for HSMP LSPs could be expressed as an intention 444 to test the LSP Ping Echo Request packets that enter at the root 445 along a particular downstream path of HSMP LSP, and end their MPLS 446 path on the leaf. The leaf node then sends the LSP Ping Echo Reply 447 along the co-routed upstream path of HSMP LSP, and end on the root 448 that are the (intended) root node. 450 New sub-TLVs are required to be assigned by IANA in Target FEC Stack 451 TLV to define the corresponding HSMP-upstream FEC type and HSMP- 452 downstream FEC type. In order to ensure the leaf node to send the 453 LSP Ping Echo Reply along the HSMP upstream path, the R bit (Validate 454 Reverse Path) in Global Flags Field defined in [RFC6426] is reused 455 here. 457 The node processing mechanism of LSP Ping Echo Request and Echo Reply 458 for HSMP LSP is inherited from [RFC6425] and [RFC6426] section 3.4, 459 except the following: 461 1. The root node sending LSP Ping Echo Request message for HSMP LSP 462 MUST attach Target FEC Stack with HSMP downstream FEC, and set R bit 463 to '1' in Global Flags Field. 465 2. When the leaf node receiving the LSP Ping Echo Request, it MUST 466 send the LSP Ping Echo Reply to the associated HSMP upstream path. 467 The Reverse-path Target FEC Stack TLV attached by leaf node in Echo 468 Reply message SHOULD contain the sub-TLV of associated HSMP upstream 469 FEC. 471 9. Security Considerations 473 The same security considerations apply as for the MP2MP LSP described 474 in [RFC6388] and [RFC6425]. 476 Although this document introduces new FEC Elements and corresponding 477 procedures, the protocol does not bring any new security issues 478 compared to [RFC6388] and [RFC6425]. 480 10. IANA Considerations 482 This document requires allocation of two new LDP FEC Element types 483 from the "Label Distribution Protocol (LDP) Parameters registry" the 484 "Forwarding Equivalence Class (FEC) Type Name Space": 486 1. the HSMP-upstream FEC type - requested value TBD 488 2. the HSMP-downstream FEC type - requested value TBD 490 This document requires allocation of one new code points for the HSMP 491 LSP capability TLV from "Label Distribution Protocol (LDP) Parameters 492 registry" the "TLV Type Name Space": 494 HSMP LSP Capability Parameter - requested value TBD 496 This document requires allocation of two new sub-TLV types for 497 inclusion within the LSP ping [RFC4379] Target FEC Stack TLV (TLV 498 type 1). 500 1. the HSMP-upstream LDP FEC Stack - requested value TBD 502 2. the HSMP-downstream LDP FEC Stack - requested value TBD 504 11. Acknowledgement 506 The author would like to thank Eric Rosen, Sebastien Jobert, Fei Su, 507 Edward, Mach Chen, Thomas Morin, Loa Andersson for their valuable 508 comments. 510 12. References 512 12.1. Normative references 514 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 515 Requirement Levels", BCP 14, RFC 2119, March 1997. 517 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 518 Label Assignment and Context-Specific Label Space", 519 RFC 5331, August 2008. 521 [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS 522 Multicast Encapsulations", RFC 5332, August 2008. 524 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 525 Le Roux, "LDP Capabilities", RFC 5561, July 2009. 527 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 528 "Label Distribution Protocol Extensions for Point-to- 529 Multipoint and Multipoint-to-Multipoint Label Switched 530 Paths", RFC 6388, November 2011. 532 [RFC6389] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label 533 Assignment for LDP", RFC 6389, November 2011. 535 [RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, 536 S., and T. Nadeau, "Detecting Data-Plane Failures in 537 Point-to-Multipoint MPLS - Extensions to LSP Ping", 538 RFC 6425, November 2011. 540 [RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS 541 On-Demand Connectivity Verification and Route Tracing", 542 RFC 6426, November 2011. 544 12.2. Informative References 546 [I-D.ietf-l2vpn-vpms-frmwk-requirements] 547 Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard, D., 548 and L. Jin, "Framework and Requirements for Virtual 549 Private Multicast Service (VPMS)", 550 draft-ietf-l2vpn-vpms-frmwk-requirements-05 (work in 551 progress), October 2012. 553 [I-D.ietf-pwe3-p2mp-pw] 554 Sivabalan, S., Boutros, S., and L. Martini, "Signaling 555 Root-Initiated Point-to-Multipoint Pseudowire using LDP", 556 draft-ietf-pwe3-p2mp-pw-04 (work in progress), March 2012. 558 [I-D.ietf-tictoc-1588overmpls] 559 Davari, S., Oren, A., Bhatia, M., Roberts, P., and L. 560 Montini, "Transporting Timing messages over MPLS 561 Networks", draft-ietf-tictoc-1588overmpls-05 (work in 562 progress), June 2013. 564 [IEEE1588] 565 "IEEE standard for a precision clock synchronization 566 protocol for networked measurement and control systems", 567 IEEE1588v2 , March 2008. 569 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 570 Thyagarajan, "Internet Group Management Protocol, Version 571 3", RFC 3376, October 2002. 573 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 574 Label Switched (MPLS) Data Plane Failures", RFC 4379, 575 February 2006. 577 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 578 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 579 RFC 4762, January 2007. 581 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 582 Specification", RFC 5036, October 2007. 584 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 585 Measurement for MPLS Networks", RFC 6374, September 2011. 587 [RFC6826] Wijnands, IJ., Eckert, T., Leymann, N., and M. Napierala, 588 "Multipoint LDP In-Band Signaling for Point-to-Multipoint 589 and Multipoint-to-Multipoint Label Switched Paths", 590 RFC 6826, January 2013. 592 Authors' Addresses 594 Lizhong Jin 595 Shanghai, China 597 Email: lizho.jin@gmail.com 599 Frederic Jounay 600 France Telecom 601 2, avenue Pierre-Marzin 602 22307 Lannion Cedex, FRANCE 604 Email: frederic.jounay@orange.ch 606 IJsbrand Wijnands 607 Cisco Systems, Inc 608 De kleetlaan 6a 609 Diegem 1831, Belgium 611 Email: ice@cisco.com 613 Nicolai Leymann 614 Deutsche Telekom AG 615 Winterfeldtstrasse 21 616 Berlin 10781 618 Email: N.Leymann@telekom.de