idnits 2.17.1 draft-ietf-mpls-mldp-hsmp-01.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 (April 18, 2013) is 4026 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 541, but no explicit reference was found in the text == Unused Reference: 'RFC6374' is defined on line 545, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-tictoc-1588overmpls-04 -- 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: October 20, 2013 France Telecom 6 I. Wijnands 7 Cisco Systems, Inc 8 N. Leymann 9 Deutsche Telekom AG 10 April 18, 2013 12 LDP Extensions for Hub & Spoke Multipoint Label Switched Path 13 draft-ietf-mpls-mldp-hsmp-01.txt 15 Abstract 17 This draft introduces a hub & spoke multipoint LSP (short for HSMP 18 LSP), 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, exactly as if it was traveling downstream 22 along a P2MP LSP to each leaf node, and traffic entering the HSMP LSP 23 at any leaf node travels upstream along the tree to the root as if it 24 is unicast to the root, except that it follows the path of the tree 25 rather than ordinary unicast to the root. 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 October 20, 2013. 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. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3.1. Time synchronization scenario . . . . . . . . . . . . . . 4 71 3.2. VPMS scenario . . . . . . . . . . . . . . . . . . . . . . 4 72 3.3. IPTV scenario . . . . . . . . . . . . . . . . . . . . . . 4 73 4. Setting up HSMP LSP with LDP . . . . . . . . . . . . . . . . . 5 74 4.1. Support for HSMP LSP setup with LDP . . . . . . . . . . . 5 75 4.2. HSMP FEC Elements . . . . . . . . . . . . . . . . . . . . 6 76 4.3. Using the HSMP FEC Elements . . . . . . . . . . . . . . . 6 77 4.3.1. HSMP LSP Label Map . . . . . . . . . . . . . . . . . . 6 78 4.3.2. HSMP LSP Label Withdraw . . . . . . . . . . . . . . . 8 79 4.3.3. HSMP LSP upstream LSR change . . . . . . . . . . . . . 9 80 5. HSMP LSP on a LAN . . . . . . . . . . . . . . . . . . . . . . 9 81 6. Redundancy considerations . . . . . . . . . . . . . . . . . . 9 82 7. Co-routed path exceptions . . . . . . . . . . . . . . . . . . 9 83 8. Failure Detection of HSMP LSP . . . . . . . . . . . . . . . . 10 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 85 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 86 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 87 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 12.1. Normative references . . . . . . . . . . . . . . . . . . . 11 89 12.2. Informative References . . . . . . . . . . . . . . . . . . 12 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 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 98 (short for HSMP LSP), 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 was traveling 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 traveling upstream 104 should be thought of as being unicast to the root, except that it 105 follows the path of the tree rather than ordinary unicast to the 106 root. 108 2. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 This document uses some terms and acronyms as follows: 116 mLDP: Multipoint extensions for LDP 118 P2MP LSP: An LSP that has one Ingress LSR and one or more Egress 119 LSRs. 121 MP2MP LSP: An LSP that connects a set of nodes, such that traffic 122 sent by any node in the LSP is delivered to all others. 124 HSMP LSP: hub & spoke multipoint LSP. An LSP allows traffic both 125 from root to leaf through P2MP LSP and also leaf to root along the 126 co-routed reverse path. 128 PTP: The timing and synchronization protocol used by IEEE1588 130 3. Applications 132 In some cases, the P2MP LSP may not have a reply path for the OAM 133 message (e.g, LSP Ping). If P2MP LSP is provided by HSMP LSP, then 134 the upstream path could be exactly used as the OAM message reply 135 path. This is especially useful in the case of P2MP LSP fault 136 detection, performance measurement, root node redundancy and etc. 137 There are several other applications that could take advantage of 138 such kind of LDP based HSMP LSP as described below. 140 3.1. Time synchronization scenario 142 [IEEE1588] over MPLS is defined in [I-D.ietf-tictoc-1588overmpls]. 143 It is required that the LSP used to transport PTP event message 144 between a Master Clock and a Slave Clock, and the LSP between the 145 same Slave Clock and Master Clock must be co-routed. By using point- 146 to-multipoint technology to transmit PTP event messages from Master 147 Clock at root side to Slave Clock at leaf side will greatly improve 148 the bandwidth usage. Unfortunately current point-to-multipoint LSP 149 only provides unidirectional path from root to leaf, which cannot 150 provide a co-routed reverse path for the PTP event messages. LDP 151 based HSMP LSP described in this draft provides unidirectional point- 152 to-multipoint LSP from root to leaf and co-routed reverse path from 153 leaf to root. 155 3.2. VPMS scenario 157 Point to multipoint PW described in [I-D.ietf-pwe3-p2mp-pw] requires 158 to setup reverse path from leaf node (referred as egress PE) to root 159 node (referred as ingress PE), if HSMP LSP is used to multiplex P2MP 160 PW, the reverse path can also be multiplexed to HSMP upstream path to 161 avoid setup independent reverse path. In that case, the operational 162 cost will be reduced for maintaining only one HSMP LSP, instead of 163 P2MP LSP and n (number of leaf nodes) P2P reverse LSPs. 165 The VPMS defined in [I-D.ietf-l2vpn-vpms-frmwk-requirements] requires 166 reverse path from leaf to root node. The P2MP PW multiplexed to HSMP 167 LSP can provide VPMS with reverse path, without introducing 168 independent reverse path from each leaf to root. 170 3.3. IPTV scenario 172 The mLDP based HSMP LSP can also be applied in a typical IPTV 173 scenario. There is usually only one location with senders but there 174 are many receiver locations. If IGMP is used for signaling between 175 senders as IGMP querier and receivers, the IGMP messages from the 176 receivers are travelling only from the leaves to the root (and from 177 root towards leaves) but not from leaf to leaf. In addition traffic 178 from the root is only replicated towards the leaves. Then leaf node 179 receiving IGMP message (for SSM case) will join HSMP LSP, and then 180 send IGMP message upstream to root along HSMP LSP. Note that in 181 above case, there is no node redundancy for IGMP querier. And the 182 node redundancy for IGMP querier could be provided by two independent 183 VPMS instances with HSMP applied. 185 4. Setting up HSMP LSP with LDP 187 HSMP LSP is similar with MP2MP LSP described in [RFC6388], with the 188 difference that the leaf LSRs can only send traffic to root node 189 along the same path of traffic from root node to leaf node. 191 HSMP LSP consists of a downstream path and upstream path. The 192 downstream path is same as MP2MP LSP, while the upstream path is only 193 from leaf to root node, without communication between leaf and leaf 194 nodes. The transmission of packets from the root node of a HSMP LSP 195 to the receivers is identical to that of a P2MP LSP. Traffic from a 196 leaf node follows the upstream path toward the root node, along the 197 identical path of downstream path. 199 For setting up the upstream path of a HSMP LSP, ordered mode MUST be 200 used which is same as MP2MP. Ordered mode can guarantee a leaf to 201 start sending packets to root immediately after the upstream path is 202 installed, without being dropped due to an incomplete LSP. 204 Due to much of same behavior between HSMP LSP and MP2MP LSP, the 205 following sections only describe the difference between the two 206 entities. 208 4.1. Support for HSMP LSP setup with LDP 210 HSMP LSP also needs the LDP capabilities [RFC5561] to indicate the 211 supporting for the setup of HSMP LSPs. An implementation supporting 212 the HSMP LSP procedures specified in this document MUST implement the 213 procedures for Capability Parameters in Initialization Messages. 214 Advertisement of the HSMP LSP Capability indicates support of the 215 procedures for HSMP LSP setup. 217 A new Capability Parameter TLV is defined, the HSMP LSP Capability. 218 Following is the format of the HSMP LSP Capability Parameter. 220 0 1 2 3 221 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 |1|0| HSMP LSP Cap(TBD IANA) | Length (= 1) | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 |1| Reserved | 226 +-+-+-+-+-+-+-+-+ 227 Figure 1. HSMP LSP Capability Parameter encoding 229 The HSMP LSP capability type is to be assigned by IANA. 231 4.2. HSMP FEC Elements 233 Similar as MP2MP LSP, we define two new protocol entities, the HSMP 234 downstream FEC and upstream FEC Element. If a FEC TLV contains an 235 HSMP FEC Element, the HSMP FEC Element MUST be the only FEC Element 236 in the FEC TLV. The structure, encoding and error handling for the 237 HSMP downstream and upstream FEC Elements are the same as for the 238 MP2MP FEC Element described in [RFC6388] Section 4.2. The difference 239 is that two additional new FEC types are used: HSMP downstream type 240 (TBD, IANA) and HSMP upstream type (TBD, IANA). 242 4.3. Using the HSMP FEC Elements 244 In order to describe the message processing clearly, following 245 defines the processing of the HSMP FEC Elements, which is inherited 246 from [RFC6388] section 4.3. 248 1. HSMP downstream LSP (or simply downstream ): a HSMP 249 LSP downstream path with root node address X and opaque value Y. 251 2. HSMP upstream LSP (or simply upstream ): a HSMP LSP 252 upstream path for root node address X and opaque value Y which will 253 be used by any of downstream node to send traffic upstream to root 254 node. 256 3. HSMP downstream FEC Element : a FEC Element with root node 257 address X and opaque value Y used for a downstream HSMP LSP. 259 4. HSMP upstream FEC Element : a FEC Element with root node 260 address X and opaque value Y used for an upstream HSMP LSP. 262 5. HSMP-D Label Map : A Label Map message with a single 263 HSMP downstream FEC Element and label TLV with label L. Label 264 L MUST be allocated from the per-platform label space of the LSR 265 sending the Label Map Message. 267 6. HSMP-U Label Map : A Label Map message with a single 268 HSMP upstream FEC Element and label TLV with label Lu. Label 269 Lu MUST be allocated from the per-platform label space of the LSR 270 sending the Label Map Message. 272 4.3.1. HSMP LSP Label Map 274 This section specifies the procedures for originating HSMP Label Map 275 messages and processing received HSMP label map messages for a 276 particular HSMP LSP. The procedure of downstream HSMP LSP is same as 277 that of downstream MP2MP LSP described in [RFC6388]. Under the 278 operation of ordered mode, the upstream LSP will be setup by sending 279 HSMP LSP mapping message with label which is allocated by upstream 280 LSR to its downstream LSR one by one from root to leaf node, 281 installing the upstream forwarding table by every node along the LSP. 282 Detail procedure of upstream HSMP LSP is different with that of 283 upstream MP2MP LSP, and is specified in below section. 285 All labels discussed here are downstream-assigned [RFC5332] except 286 those which are assigned using the procedures described in section 5. 288 Determining the upstream LSR for a HSMP LSP follows the 289 procedure for a MP2MP LSP described in [RFC6388] Section 4.3.1.1. 291 Determining one's downstream HSMP LSR procedure is much same as 292 defined in [RFC6388] section 4.3.1.2. A LDP peer U which receives a 293 HSMP-D Label Map from a LDP peer D will treat D as downstream HSMP 294 LSR. 296 Determining the forwarding interface to an LSR has same procedure as 297 defined in [RFC6388] section 2.4.1.2. 299 4.3.1.1. HSMP LSP leaf node operation 301 The leaf node operation is same as the operation of MP2MP LSP defined 302 in [RFC6388] section 4.3.1.4, only with different FEC element 303 processing and specified below. 305 A leaf node Z will send a HSMP-D Label Map to U, instead of 306 MP2MP-D Label Map . and expects a HSMP-U Label Map from node U and checks whether it already has forwarding state 308 for upstream . The created forwarding state on leaf node Z is 309 same as the leaf node of MP2MP LSP. Z will push label Lu onto the 310 traffic that Z wants to forward over the HSMP LSP. 312 4.3.1.2. HSMP LSP transit node operation 314 Suppose node Z receives a HSMP-D Label Map from LSR D, the 315 procedure is same as processing MP2MP-D Label Mapping message defined 316 in [RFC6388] section 4.3.1.5, and the processing protocol entity is 317 HSMP-D label mapping message. The different procedure is specified 318 below. 320 Node Z checks if upstream LSR U already assigned a label Lu to 321 upstream . If not, transit node Z waits until it receives a 322 HSMP-U Label Map from LSR U. Once the HSMP-U Label Map is 323 received from LSR U, node Z checks whether it already has forwarding 324 state upstream with incoming label Lu' and outgoing label Lu. 325 If it does, Z sends a HSMP-U Label Map to downstream 326 node. If it does not, it allocates a label Lu' and creates a new 327 label swap for Lu' with Label Lu over interface Iu. Interface Iu is 328 determined via the procedures in Section 4.3.1. Node Z determines 329 the downstream HSMP LSR as per Section 4.3.1, and sends a HSMP-U 330 Label Map to node D. 332 Since a packet from any downstream node is forwarded only to the 333 upstream node, the same label (representing the upstream path) can be 334 distributed to all downstream nodes. This differs from the 335 procedures for MPMP LSPs [RFC6388], where a distinct label must be 336 distributed to each downstream node. The forwarding state upstream 337 on node Z will be like this {, }. Iu means the 338 upstream interface over which Z receives HSMP-U Label Map 339 from LSR U. Packets from any downstream interface over which Z send 340 HSMP-U Label Map with label Lu' will be forwarded to Iu 341 with label Lu' swap to Lu. 343 4.3.1.3. HSMP LSP root node operation 345 Suppose root node Z receives a HSMP-D Label Map from node 346 D, the procedure is much same as processing MP2MP-D Label Mapping 347 message defined in [RFC6388] section 4.3.1.6, and the processing 348 protocol entity is HSMP-D label mapping message. The different 349 procedure is specified below. 351 Node Z checks if it has forwarding state for upstream . If 352 not, Z creates a forwarding state for incoming label Lu' that 353 indicates that Z is the LSP egress. E.g., the forwarding state might 354 specify that the label stack is popped and the packet passed to some 355 specific application. Node Z determines the downstream HSMP LSR as 356 per section 4.3.1, and sends a HSMP-U Label Map to node 357 D. 359 Since Z is the root of the tree, Z will not send a HSMP-D Label Map 360 and will not receive a HSMP-U Label Map. 362 4.3.2. HSMP LSP Label Withdraw 364 The HSMP Label Withdraw procedure is much same as MP2MP leaf 365 operation defined in [RFC6388] section 4.3.2, and the processing 366 protocol entities are HSMP FECs. The only difference is process of 367 HSMP-U label release message, which is specified below. 369 When a transit node Z receives a HSMP-U label release message from 370 downstream node D, Z should check if there are any incoming interface 371 in forwarding state upstream . If all downstream nodes are 372 released and there is no incoming interface, Z should delete the 373 forwarding state upstream and send HSMP-U label release 374 message to its upstream node. 376 4.3.3. HSMP LSP upstream LSR change 378 The procedure for changing the upstream LSR is the same as defined in 379 [RFC6388] section 4.3.3, except it is applied to HSMP FECs. 381 5. HSMP LSP on a LAN 383 The procedure to process P2MP LSP on a LAN has been described in 384 [RFC6388]. When the LSR forwards a packet downstream on one of those 385 LSPs, the packet's top label must be the "upstream LSR label", and 386 the packet's second label is "LSP label". 388 When establishing the downstream path of a HSMP LSP, as defined in 389 [RFC6389], a label request for a LSP label is send to the upstream 390 LSR. The upstream LSR should send label mapping that contains the 391 LSP label for the downstream HSMP FEC and the upstream LSR context 392 label. At the same time, it must also send label mapping for 393 upstream HSMP FEC to downstream node. Packets sent by the upstream 394 router can be forwarded downstream using this forwarding state based 395 on a two label lookup. Packets traveling upstream need to be 396 forwarded in the direction of the root by using the label allocated 397 by upstream LSR. 399 6. Redundancy considerations 401 In some scenario, it is necessary to provide two root nodes for 402 redundancy purpose. One way to implement this is to use two 403 independent HSMP LSPs acting as active/standby. At one time, only 404 one HSMP LSP will be active, and the other will be standby. After 405 detecting the failure of active HSMP LSP, the root and leaf nodes 406 will switch the traffic to the new active HSMP LSP which is switched 407 from former standby LSP. The detail of redundancy mechanism will be 408 for future study. 410 7. Co-routed path exceptions 412 There are some exceptional cases that mLDP based HSMP LSP could not 413 achieve co-routed path. One possible case is using static routing 414 between LDP neighbors; another possible case is IGP cost asymmetric 415 generated by physical link cost asymmetric, or TE-Tunnels used 416 between LDP neighbors. The LSR/LER in HSMP LSP could detect if the 417 path is co-routed or not, if not co-routed, an indication could be 418 generated to the management system. 420 8. Failure Detection of HSMP LSP 422 The idea of LSP ping for HSMP LSPs could be expressed as an intention 423 to test the packets that enter at the root along a particular 424 downstream path of HSMP LSP, and end their MPLS path on the leaf. 425 The leaf node then sends the LSP ping response along the co-routed 426 upstream path of HSMP LSP, and end on the root that are the 427 (intended) root node. 429 New sub-TLVs are required to be assigned by IANA in Target FEC Stack 430 TLV to define the corresponding HSMP-upstream FEC type and HSMP- 431 downstream FEC type. In order to ensure the leaf node to send the 432 LSP ping response along the HSMP upstream path, the R bit (Validate 433 Reverse Path) in Global Flags Field defined in [RFC6426] is reused 434 here. 436 The node processing mechanism of LSP ping for HSMP LSP is inherited 437 from [RFC6425] and [RFC6426] section 3.4, except the following: 439 1. The root node sending LSP ping message for HSMP LSP MUST attach 440 Target FEC Stack with HSMP downstream FEC, and set R bit to '1' in 441 Global Flags Field. 443 2. When the leaf node receiving the LSP ping, it MUST send the LSP 444 ping response to the associated HSMP upstream path. The Reverse-path 445 Target FEC Stack TLV attached by leaf node in reply message SHOULD 446 contain the sub-TLV of associated HSMP upstream FEC. 448 9. Security Considerations 450 The same security considerations apply as for the MP2MP LSP described 451 in [RFC6388] and [RFC6425]. 453 10. IANA Considerations 455 This document requires allocation of two new LDP FEC Element types 456 from the "Label Distribution Protocol (LDP) Parameters registry" the 457 "Forwarding Equivalence Class (FEC) Type Name Space": 459 1. the HSMP-upstream FEC type - requested value TBD 461 2. the HSMP-downstream FEC type - requested value TBD 463 This document requires allocation of one new code points for the HSMP 464 LSP capability TLV from "Label Distribution Protocol (LDP) Parameters 465 registry" the "TLV Type Name Space": 467 HSMP LSP Capability Parameter - requested value TBD 469 This document requires allocation of two new sub-TLV types for 470 inclusion within the LSP ping [RFC4379] Target FEC Stack TLV (TLV 471 type 1). 473 1. the HSMP-upstream LDP FEC Stack - requested value TBD 475 2. the HSMP-downstream LDP FEC Stack - requested value TBD 477 11. Acknowledgement 479 The author would like to thank Eric Rosen, Sebastien Jobert, Fei Su, 480 Edward, Mach Chen, Thomas Morin for their valuable comments. 482 12. References 484 12.1. Normative references 486 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 487 Requirement Levels", BCP 14, RFC 2119, March 1997. 489 [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS 490 Multicast Encapsulations", RFC 5332, August 2008. 492 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 493 Le Roux, "LDP Capabilities", RFC 5561, July 2009. 495 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 496 "Label Distribution Protocol Extensions for Point-to- 497 Multipoint and Multipoint-to-Multipoint Label Switched 498 Paths", RFC 6388, November 2011. 500 [RFC6389] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label 501 Assignment for LDP", RFC 6389, November 2011. 503 [RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, 504 S., and T. Nadeau, "Detecting Data-Plane Failures in 505 Point-to-Multipoint MPLS - Extensions to LSP Ping", 506 RFC 6425, November 2011. 508 [RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS 509 On-Demand Connectivity Verification and Route Tracing", 510 RFC 6426, November 2011. 512 12.2. Informative References 514 [I-D.ietf-l2vpn-vpms-frmwk-requirements] 515 Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard, D., 516 and L. Jin, "Framework and Requirements for Virtual 517 Private Multicast Service (VPMS)", 518 draft-ietf-l2vpn-vpms-frmwk-requirements-05 (work in 519 progress), October 2012. 521 [I-D.ietf-pwe3-p2mp-pw] 522 Sivabalan, S., Boutros, S., and L. Martini, "Signaling 523 Root-Initiated Point-to-Multipoint Pseudowire using LDP", 524 draft-ietf-pwe3-p2mp-pw-04 (work in progress), March 2012. 526 [I-D.ietf-tictoc-1588overmpls] 527 Davari, S., Oren, A., Bhatia, M., Roberts, P., and L. 528 Montini, "Transporting Timing messages over MPLS 529 Networks", draft-ietf-tictoc-1588overmpls-04 (work in 530 progress), February 2013. 532 [IEEE1588] 533 "IEEE standard for a precision clock synchronization 534 protocol for networked measurement and control systems", 535 IEEE1588v2 , March 2008. 537 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 538 Label Switched (MPLS) Data Plane Failures", RFC 4379, 539 February 2006. 541 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 542 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 543 RFC 4762, January 2007. 545 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 546 Measurement for MPLS Networks", RFC 6374, September 2011. 548 Authors' Addresses 550 Lizhong Jin 551 Shanghai, China 553 Email: lizho.jin@gmail.com 554 Frederic Jounay 555 France Telecom 556 2, avenue Pierre-Marzin 557 22307 Lannion Cedex, FRANCE 559 Email: frederic.jounay@orange.ch 561 IJsbrand Wijnands 562 Cisco Systems, Inc 563 De kleetlaan 6a 564 Diegem 1831, Belgium 566 Email: ice@cisco.com 568 Nicolai Leymann 569 Deutsche Telekom AG 570 Winterfeldtstrasse 21 571 Berlin 10781 573 Email: N.Leymann@telekom.de