idnits 2.17.1 draft-boutros-mpls-tp-li-lb-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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: In the in-band option, the MPLS-TP LI-LB channel is identified by the ACH as defined in RFC 5586 [6] with the Channel Type set to the MPLS-TP LI-LB code point = 0xHH. [HH to be assigned by IANA from the PW Associated Channel Type registry] The LI-LB Channel does not use ACH TLVs and MUST not include the ACH TLV header. The LI-LB ACH Channel is shown below. -- The document date (July 5, 2010) is 5043 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: '1' is defined on line 742, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 746, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 766, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 772, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4379 (ref. '4') (Obsoleted by RFC 8029) == Outdated reference: A later version (-07) exists of draft-ietf-mpls-tp-identifiers-01 -- Duplicate reference: RFC5654, mentioned in '8', was also mentioned in '1'. Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Sami Boutros (Ed.) 3 Internet Draft Siva Sivabalan (Ed.) 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: January 5, 2011 6 Rahul Aggarwal (Ed.) 7 Juniper Networks, Inc. 9 Martin Vigoureux (Ed.) 10 Alcatel-Lucent 12 Xuehui Dai (Ed.) 13 ZTE Corporation 15 July 5, 2010 17 MPLS Transport Profile Lock Instruct and Loopback Functions 18 draft-boutros-mpls-tp-li-lb-01.txt 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 This Internet-Draft will expire on January 5, 2007. 43 Abstract 44 This document specifies an extension to MPLS Operation, 45 administration, and Maintenance (OAM) to operate an MPLS Transport 46 Profile (MPLS-TP) Label Switched Path (LSP), bi-directional RSVP-TE 47 tunnels, pseudowires (PW), or Multi-segment PWs in loopback mode for 48 management purpose. This extension includes mechanism to lock and 49 unlock MPLS-TP Tunnels (i.e. data and control traffic) and can be 50 used to loop all traffic (i.e, data and control traffic) at a 51 specified LSR on the path of the MPLS-TP LSP back to the source. 53 Table of Contents 55 1. Introduction...................................................3 56 2. Terminology....................................................4 57 3. MPLS-TP Loopback/Lock Mechanism................................5 58 3.1. In-band Message Identification............................5 59 3.2. MPLS LI-LB Message Format.................................5 60 3.3. LSP Ping Extensions.......................................8 61 3.3.1. Lock Request TLV.....................................8 62 3.3.2. Unlock Request TLV...................................8 63 3.3.3. Loopback Request TLV.................................8 64 3.3.4. Loopback Removal TLV.................................9 65 3.3.5. Response TLV.........................................9 66 3.3.6. Authentication TLV..................................10 67 4. Loopback/Lock Operations......................................10 68 4.1. Lock Request.............................................10 69 4.2. Unlock Request...........................................10 70 4.3. Loopback Request.........................................11 71 4.4. Loopback Removal.........................................11 72 5. Data packets..................................................11 73 6. Operation.....................................................12 74 6.1. General Procedures.......................................12 75 6.2. Example Topology.........................................12 76 6.3. Locking an LSP...........................................13 77 6.4. Unlocking an LSP.........................................13 78 6.5. Setting an LSP into Loopback mode........................14 79 6.6. Removing an LSP from Loopback mode.......................15 80 7. Security Considerations.......................................16 81 8. IANA Considerations...........................................16 82 TBD..............................................................16 83 9. References....................................................16 84 9.1. Normative References.....................................16 85 9.2. Informative References...................................17 86 Author's Addresses...............................................17 87 Full Copyright Statement.........................................19 88 Intellectual Property Statement..................................19 90 1. Introduction 92 In traditional transport networks, circuits are provisioned across 93 multiple nodes and service providers have the ability to operate the 94 transport circuit such as T1 line in loopback mode for management 95 purposes, e.g., to test or verify connectivity of the circuit up to a 96 specific node on the path of the circuit, to test the circuit 97 performance with respect to delay/jitter, etc. MPLS-TP bidirectional 98 LSP emulating traditional transport circuits need to provide the same 99 loopback capability. The mechanisms in this document apply to 100 associated bidirectional paths as defined in [7], which include MPLS- 101 TP LSPs, bi-directional RSVP-TE tunnels, pseudowires (PW), and Multi- 102 segment PWs. 104 To describe the loopback functionality, let us assume a bi- 105 directional MPLS-TP LSP A <---> B <---> C <---> D where A, B, C, and 106 D are MPLS capable nodes. Also, let us assume that the network 107 operator requires C to loop, back to A, the packets sent from A. In 108 this example, A and D acts as Maintenance End Points (MEPs) and C 109 acts as a Maintenance Intermediate Point (MIP). The operator can 110 setup the MPLS-TP LSP into loopback mode such that C loops all the 111 packets (regardless of whether they are data or control packets) 112 generated by node A back to A. The packets are not also forwarded 113 towards D. Similarly, any traffic received by C from the reverse 114 direction will be dropped. 116 The operator must take the MPLS-TP LSP out of service before setting 117 up the MPLS-TP LSP in loopback mode. This is accomplished by the MEP 118 establishing the loopback first sending a Lock command to the remote 119 MEP(s). In the case above, A sends a Lock request message along the 120 MPLS-TP LSP and destined to D to lock the MPLS-TP LSP. The message 121 will be intercepted by D since it is at the end of the LSP. D 122 responds to the lock request with a reply message specifying whether 123 it can take the LSP out of service or not. 125 In order to set the MPLS-TP LSP in loopback mode, A sends a Loopback 126 request message to the MIP or MEP where the loopback is to be 127 enabled. In the above example, the MPLS TTL value is set so that the 128 message will be intercepted by C. 130 This message contains a request to instruct C to operate the 131 corresponding MPLS-TP LSP in Loopback mode. C responds to the 132 Loopback request with a reply message back to A to indicate whether 133 or not it has successfully set the MPLS-TP LSP into the loopback 134 mode. If the loopback cannot be set, the reply message would contain 135 an error code. Upon receiving such a reply to the loopback request, A 136 logs the event and takes further reporting actions as necessary. If 137 the MPLS-TP LSP was previously locked, A sends another request 138 message to D to unlock it. 140 If the loopback request can be performed, the input LSP from the 141 direction of A is directly cross-connected to the output LSP towards 142 A. All the packets generated by node A (data and control) are looped 143 back at C, excepting the case of TTL expiration. 145 When the loopback operation is no longer required, A sends a request 146 message to remove the loopback and thus restore the LSP to its 147 original forwarding state. In this example the MPLS TTL is set such 148 that this message is intercepted by C. It is expected that C sends a 149 reply back to A to with a return code either ACKing or NAK the 150 loopback removal request. Upon getting an ACK response to loopback 151 mode removal request, A sends another request message to unlock the 152 MPLS-TP LSP. The packet is intercepted by D as it is at the end of 153 the MPLS-TP LSP. 155 The proposed mechanism is based on a new set of messages and TLVs 156 which can be transported using one of the following methods: 158 (1) An in-band MPLS message transported using a new ACH code point, 159 the message will have different types to perform the loopback 160 request/remove and Lock/unlock functions, and may carry new set of 161 TLVs. 163 (2) A new set of TLVs which can be transported using LSP-Ping 164 extensions defined in [4], and in compliance to specifications [5]. 166 Method (1) and (2) are referred to as "in-band option" and "LSP-Ping 167 option" respectively in the rest of the document. 169 Conventions used in this document 171 In examples, "C:" and "S:" indicate lines sent by the client and 172 server respectively. 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in RFC-2119 [3]. 178 2. Terminology 180 ACH: Associated Channel Header 182 LSR: Label Switching Router 184 MEP: Maintenance Entity Group End Point 186 MIP: Maintenance Entity Group Intermediate Point. 188 MPLS-TP: MPLS Transport Profile 189 MPLS-OAM: MPLS Operations, Administration and Maintenance 191 MPLS-TP LSP: Bidirectional Label Switch Path representing a circuit 193 NMS: Network Management System 195 TLV: Type Length Value 197 TTL: Time To Live 199 LI-LB: Lock instruct-Loopback 201 3. MPLS-TP Loopback/Lock Mechanism 203 For the in-band option, the proposed mechanism uses a new code point 204 in the Associated Channel Header (ACH) described in [6]. 206 3.1. In-band Message Identification 208 In the in-band option, the MPLS-TP LI-LB channel is identified by the 209 ACH as defined in RFC 5586 [6] with the Channel Type set to the MPLS- 210 TP LI-LB code point = 0xHH. [HH to be assigned by IANA from the PW 211 Associated Channel Type registry] The LI-LB Channel does not use ACH 212 TLVs and MUST not include the ACH TLV header. The LI-LB ACH 213 Channel is shown below. 215 0 1 2 3 216 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 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 |0 0 0 1|Version|Reserved | 0xHH (MPLS-TP LI-LB) | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 Figure 1: ACH Indication of MPLS-TP LI-LB 223 The LI-LB Channel is 0xHH (to be assigned by IANA) 225 3.2. MPLS LI-LB Message Format 227 The format of an MPLS-TP LI-LB Message is shown below. 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Version | Message Type | Operation | Reserved | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Return Code | Cause Code | Message Length | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Sender's Handle | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Message ID | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | TLV's | 241 ~ ~ 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 Figure 2: MPLS LI-LB Message Format 246 Version: The Version Number is currently 1. (Note: the version 247 number is to be incremented whenever a change is made that affects 248 the ability of an implementation to correctly parse or process the 249 request/response message. These changes include any syntactic or 250 semantic changes made to any of the fixed fields, or to any Type- 251 Length-Value (TLV) or sub-TLV assignment or format that is defined at 252 a certain version number. The version number may not need to be 253 changed if an optional TLV or sub-TLV is added.) 255 Message Type 257 Two message types are defined as shown below. 259 Message Type Description 260 ------------ ------------- 261 0x0 LI-LB request 262 0x1 LI-LB response 264 Operation 266 Four operations are defined as shown below. The operations can appear 267 in a Request or Response message. 269 Operation Description 270 --------- ------------- 271 0x1 Lock 272 0x2 Unlock 273 0x3 Set_Loopback 274 0x4 Unset_Loopback 276 Message Length 278 The total length of any included TLVs. 280 Sender's Handle 282 The Sender's Handle is filled in by the sender, and returned 283 unchanged by the receiver in the MPLS response message (if any). 285 There are no semantics associated with this handle, although a sender 286 may find this useful for matching up requests with replies. 288 Message ID 290 The Message ID is set by the sender of an MPLS request message. It 291 MUST be copied unchanged by the receiver in the MPLS response message 292 (if any). A sender SHOULD increment this value on each new message. 293 A retransmitted message SHOULD leave the value unchanged. 295 Return code 297 Value Meaning 298 ----- ------- 299 0 Informational 300 1 Success 301 2 Failure 303 Cause code 305 Value Meaning 306 ----- ------- 307 0 No cause code 308 1 Fail to match target MIP/MEP ID 309 2 Malformed request received 310 3 One or more of the TLVs is/are unknown 311 4 Authentication failed 312 5 MPLS-TP LSP/PW already locked 313 6 MPLS-TP LSP/PW already unlocked 314 7 Fail to lock MPLS-TP LSP/PW 315 8 Fail to unlock MPLS-TP LSP/PW 316 9 MPLS-TP LSP/PW already in loopback mode 317 10 MPLS-TP LSP/PW is not in loopback mode 318 11 Fail to set MPLS-TP LSP/PW in loopback mode 319 12 Fail to remove MPLS-TP/PW from loopback mode 320 13 No label binding for received message 322 The Return code and Cause code only have meaning in a Response 323 message. In a request message the Return code and Cause code must be 324 set to zero and ignored on receipt. 326 3.3. LSP Ping Extensions 328 3.3.1. Lock Request TLV 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | type = TBD | length = 0 | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 A MEP includes a Lock Request TLV in the MPLS LSP Ping echo request 337 message to request the MEP on the other side of the MPLS-TP LSP to 338 take the LSP out of service. 340 3.3.2. Unlock Request TLV 342 0 1 2 3 343 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 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | type = TBD | length = 0 | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 The Unlock Request TLV is sent from the MEP which has previously sent 349 lock request. Upon receiving the LSP Ping Echo request message with 350 the unlock request TLV, the receiver MEP brings the MPLS-TP LSP back 351 in service. 353 3.3.3. Loopback Request TLV 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | type = TBD | length = 0 | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 When a MEP wants to put an MPLS-TP LSP in loopback mode, it sends a 362 MPLS LSP Ping echo request message with Loopback Request TLV. The 363 message can be intercepted by either a MIP or a MEP depending on the 364 MPLS TTL value. The receiver puts in corresponding MPLS-TP LSP in 365 loopback mode. 367 3.3.4. Loopback Removal TLV 369 0 1 2 3 370 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 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | type = TBD | length = 0 | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 When loopback mode operation of an MPLS-TP LSP is no longer required, 376 the MEP that previously sent the MPLS LSP Ping echo request message 377 with a loopback TLV, sends another MPLS LSP Ping echo request message 378 with a Loopback Removal TLV. The receiver MEP changes the MPLS-TP LSP 379 from loopback mode to normal mode of operation. 381 3.3.5. Response TLV 383 0 1 2 3 384 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 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | type = TBD | Length = 0x1 | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 |ReturnCode | 389 +-+-+-+-+-+-+-+ 391 Return code 392 Value Meaning 393 ----- ------- 394 0 Success 395 1 Fail to match target MIP/MEP ID 396 2 Malformed loopback request received 397 3 One or more of the TLVs is/are unknown 398 4 Authentication failed 399 5 MPLS-TP LSP/PW already locked 400 6 MPLS-TP LSP/PW already unlocked 401 7 Fail to lock MPLS-TP LSP/PW 402 8 Fail to unlock MPLS-TP LSP/PW 403 9 MPLS-TP LSP/PW already in loopback mode 404 10 MPLS-TP LSP/PW is not in loopback mode 405 11 Fail to set MPLS-TP LSP/PW in loopback mode 406 12 Fail to remove MPLS-TP LSP/PW from loopback mode 407 13 No label binding for received message 409 Note that in the case of error code 3, the unknown TLV can also be 410 optionally included in the response TLV. 412 3.3.6. Authentication TLV 414 0 1 2 3 415 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 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | type = TBD | Length = 0xx | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Variable Length Value | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 Mechanisms similar to PPP Chap can be used to authenticate the 423 Loopback request. A variable length key can be carried in an optional 424 authentication TLV which can be included in the MPLS OAM LSP Ping 425 echo request message containing a loopback request TLV or the LI-LB 426 Message. The use of authentication key is outside the scope of the 427 document. 429 4. Loopback/Lock Operations 431 4.1. Lock Request 433 Lock Request is used to request a MEP to take an MPLS-TP LSP out of 434 service so that some form of maintenance can be done. 436 The receiver MEP MUST send either an ACK or a NAK response to the 437 sender MEP. Until the sender MEP receives an ACK, it MUST NOT assume 438 that the receiver MEP has taken the MPLS-TP LSP out of service. A 439 receiver MEP sends an ACK only if it can successfully lock the MPLS- 440 TP LSP. Otherwise, it sends a NAK. 442 4.2. Unlock Request 444 The Unlock Request is sent from the MEP which has previously sent 445 lock request. Upon receiving the unlock request message, the receiver 446 MEP brings the MPLS-TP LSP back in service. 448 The receiver MEP MUST send either an ACK or a NAK response to the 449 sender MEP. Until the sender MEP receives an ACK, it MUST NOT assume 450 that the MPLS-TP LSP has been put back in service. A receiver MEP 451 sends an ACK only if the MPLS-TP LSP has been unlocked, and unlock 452 operation is successful. Otherwise, it sends a NAK. 454 4.3. Loopback Request 456 When a MEP wants to put an MPLS-TP LSP in loopback mode, it sends a 457 Loopback request message. The message can be intercepted by either a 458 MIP or a MEP depending on the MPLS TTL value. The receiver puts in 459 corresponding MPLS-TP LSP in loopback mode. 461 The receiver MEP or MIP MUST send either an ACK or NAK response to 462 the sender MEP. An ACK response is sent if the MPLS-TP LSP is 463 successfully put in loopback mode. Otherwise, a NAK response is sent. 464 Until an ACK response is received, the sender MEP MUST NOT assume 465 that the MPLS-TP LSP can operate in loopback mode. 467 4.4. Loopback Removal 469 When loopback mode operation of an MPLS-TP LSP is no longer required, 470 the MEP that previously sent the Loopback request message sends 471 another Loopback Removal message. The receiver MEP changes the MPLS- 472 TP LSP from loopback mode to normal mode of operation. 474 The receiver MEP or MIP MUST send either an ACK or NAK response to 475 the sender MEP. An ACK response is sent if the MPLS-TP LSP is already 476 in loopback mode, and if the MPLS-TP LSP is successfully put back in 477 normal operation mode. Otherwise, a NAK response is sent. Until an 478 ACK response is received, the sender MEP MUST NOT assume that the 479 MPLS-TP LSP is put back in normal operation mode. 481 5. Data packets 483 Data packets sent from the sender MEP will be looped back to that 484 sender MEP. In order for the sender MEP node to make sure that no 485 data packets are dropped, each data MPLS packets may contain a 486 sequence-id right after the label stack. A time-stamp fields in the 487 data packets can help calculate the Round trip delay of datapackets. 488 The Local Time-Stamp is set by the sender, and can be used to 489 calculate the round trip delay after the message is looped back. 491 0 1 2 3 492 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 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Label with EOS bit set | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Length | Reserved | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Sequence-Number | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Time-Stamp | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Time-Stamp | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Arbitrary Padding | 505 : : 506 | Arbitrary Padding | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 6. Operation 511 6.1. General Procedures 513 When placing an LSP into Loopback mode, the operation MUST first be 514 preceded by a Lock operation. 516 Sending LSP Ping Echo Request message with Loopback Request/Removal 517 or in-Band Loopback Request/Removal Message 519 The TTL of the topmost label is set as follows:- 521 If the target node is a MIP, the TTL MUST be set to the exact number 522 of hops required to reach that MIP. 524 If the target node is a MEP, the value MUST be set to at least the 525 number of hops required to reach that MEP. For most operations where 526 the target is a MEP, the TTL MAY be set to 255. 528 However, to remove a MEP from Loopback mode, the sending MEP MUST set 529 the TTL to the exact number of hops required to reach the MEP (if the 530 TTL were set higher, the Loopback removal message would be looped 531 back toward the sender). It is RECOMMENDED that the TTL be set to the 532 exact number of hops required to reach the MEP. 534 6.2. Example Topology 536 The next four sections discuss the procedures for Locking, Unlocking, 537 setting an LSP into loopback, and removing the loopback. The 538 description is worded using an example. Assume an MPLS-TP LSP 539 traverses nodes A <--> B <--> C <--> D. We will refer to the 540 Maintenance Entities involved as MEP-A, MIP-B, MIP-C, and MEP-D 541 respectively. Suppose a maintenance operation invoked at node A 542 requires a loopback be set at node C. To invoke Loopack mode at node 543 C, A would first need to lock the LSP. Then it may proceed to set the 544 loopback at C. Following the loopback operation, A would need to 545 remove the loopback at C and finally unlock the LSP. 547 The following sections describe MEP-A setting and unsetting a lock at 548 MEP-D and then setting and removing a loopback at MIP-C. 550 6.3. Locking an LSP 552 1. MEP-A sends an MPLS LSP Ping Echo request message with the Lock 553 TLV or an in-Band Lock request Message. Optionally, an authentication 554 TLV MAY be included. 556 2. Upon receiving the request message, D uses the received label 557 stack and the Target FEC/source MEP-ID to identify the LSP. If no 558 label binding exists or there is no associated LSP back to the 559 originator, the event is logged. Processing ceases. Otherwise the 560 message is delivered to the target MEP. 562 a. if the source MEP-ID does not match, the event is logged and 563 processing ceases. 565 b. if the target MEP-ID does not match, MEP-D sends a response with 566 error code 1. 568 MEP-D then examines the message, and: 570 c. if the message is malformed, it sends a response with error code 2 571 back to MEP-A. 573 d. if message authentication fails, it MAY send a response with error 574 code 4 back to MEP-A. 576 e. if any of the TLVs is not known, it sends a response with error 577 code 3 back to MEP-A. It may also include the unknown TLVs. 579 f. if the MPLS-TP LSP is already locked, it sends a response with 580 error code 5 back to MEP-A. 582 g. if the MPLS-TP LSP is not already locked and cannot be locked, it 583 sends a response with error code 7 back to A. 585 h. if the MPLS-TP LSP is successfully locked, it sends a response 586 with error code 0 (Success) back to MEP-A. 588 The response is sent using an MPLS LSP Ping echo reply with a 589 response TLV or an in-Band Lock response message. An authentication 590 TLV MAY be included. 592 6.4. Unlocking an LSP 594 1. MEP-A sends an MPLS Echo request message with the unLock TLV or an 595 in-Band unLock request Message. Optionally, an authentication TLV MAY 596 be included. 598 2. Upon receiving the unLock request message, D uses the received 599 label stack and target FEC/source MEP-ID to identify the LSP. If no 600 label binding exists or there is no associated LSP back to the 601 originator, the event is logged. Processing ceases. Otherwise the 602 message is delivered to the target MEP. 604 a. if the source MEP-ID does not match, the event is logged and 605 processing ceases. 607 b. if the target MEP-ID does not match, MEP-D sends a response with 608 error code 1. 610 MEP-D then examines the message, and: 612 c. if the message is malformed, it sends a response with error code 2 613 back to MEP-A. 615 d. if message authentication fails, it MAY send a response with error 616 code 4 back to MEP-A. 618 e. if any of the TLVs is not known, it sends a response with error 619 code 3 back to MEP-A. It may also include the unknown TLVs. 621 f. if the MPLS-TP LSP is already unlocked, it sends a response with 622 error code 6 back to MEP-A. 624 g. if the LSP is locked and cannot be unlocked, it sends a response 625 with error code 8 back to MEP-A. 627 h. if the LSP is successfully unlocked, it sends a response with 628 error code 0 (Success) back to MEP-A. 630 The response is sent using an MPLS LSP Ping echo reply with a 631 response TLV or an in-Band unlock response message. An authentication 632 TLV MAY be included. 634 6.5. Setting an LSP into Loopback mode 636 1. MEP-A sends an MPLS LSP Ping Echo request message with the 637 loopback TLV or an in-Band Loopback request message. Optionally, an 638 authentication TLV MAY be included. 640 2. Upon intercepting the MPLS Loopback message via TTL expiration, C 641 uses the received label stack and target FEC/source MEP-ID to 642 identify the LSP. 644 If no label binding exists or there is no associated LSP back to the 645 originator, the event is logged. Processing ceases. 647 Otherwise the message is delivered to the target MIP/MEP - in this 648 case MIP-C. 650 a. if the source MEP-ID does not match, the event is logged and 651 processing ceases. 653 b. if the target MIP-ID does not match, MIP-C sends a response with 654 error code 1. 656 MIP-C then examines the message, and: 658 c. if the message is malformed, it sends a response with error code 2 659 back to MEP-A. 661 d. if the message authentication fails, it sends a response with 662 error code 4 back to MEP-A. 664 e. if any of the TLV is not known, C sends a response with error code 665 3 back to MEP-A. It may also include the unknown TLVs. 667 f. if the MPLS-TP LSP is already in the requested loopback mode, it 668 sends a response with error code 9 back to MEP-A. 670 g. if the MPLS-TP LSP is not already in the requested loopback mode 671 and that loopback mode cannot be set, it sends a response with error 672 code 11 back to MEP-A. 674 h. if the MPLS-TP LSP is successfully programmed into the requested 675 loopback mode, it sends a response with error code 0 (Success) back 676 to MEP-A. 678 The response is sent using an MPLS LSP Ping echo reply with a 679 response TLV or an in-Band Loopback response message. An 680 authentication TLV MAY be included. 682 6.6. Removing an LSP from Loopback mode 684 1. MEP-A sends a MPLS LSP Ping Echo request message with the Loopback 685 removal TLV or an in-Band Loopback removal request message. 686 Optionally, an authentication TLV MAY be included. 688 2. Upon intercepting the MPLS Loopback removal message via TTL 689 expiration, C uses the received label stack and the target FEC/source 690 MEP-ID to identify the LSP. 692 If no label binding exists or there is no associated LSP back to 693 the originator, the event is logged. Processing ceases. 695 Otherwise the message is delivered to the target MIP/MEP - in this 696 case MIP-C. 698 a. if the source MEP-ID does not match, the event is logged and 699 processing ceases. 701 b. if the target MIP-ID does not match, MIP-C sends a response with 702 error code 1 back to MEP-A. 704 MIP-C then examines the message, and: 706 c. if the message is malformed, it sends a response with error code 2 707 back to MEP-A. 709 d. if the message authentication fails, it sends a response with 710 error code 4 back to MEP-A. 712 e. if any of the TLV is not known, C sends a response with error code 713 3 back to MEP-A. It may also include the unknown TLVs. 715 f. if the MPLS-TP is not in loopback mode, it sends a response with 716 error code 10 back to MEP-A. 718 g. if the MPLS-TP LSP loopback cannot be removed, it sends a response 719 with error code 12 back to MEP-A. 721 h. if the MPLS-TP is successfully changed from loopback mode to 722 normal mode of operation, it sends a reply with error code 0 (Success 723 ) back to MEP-A. 725 The response is sent using an MPLS LSP Ping echo reply with a 726 response TLV or an in-Band Loopback removal response message. An 727 authentication TLV MAY be included. 729 7. Security Considerations 731 The security considerations for the authentication TLV need further 732 study. 734 8. IANA Considerations 736 TBD 738 9. References 740 9.1. Normative References 742 [1] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and 743 S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, 744 September 2009. 746 [2] Vigoureux, M., Ward, D., and M. Betts, "Requirements for 747 Operations, Administration, and Maintenance (OAM) in MPLS 748 Transport Networks", RFC 5860, May 2010. 750 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 751 Levels", BCP 14, RFC 2119, March 1997. 753 [4] K. Kompella, G. Swallow, "Detecting Multi-Protocol Label 754 Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. 756 [5] N. Bahadur, et. al., "MPLS on-demand Connectivity Verification, 757 Route Tracing and Adjacency Verification", draft-nitinb-mpls- 758 tp-on-demand-cv-00, work in progress, June 2010 760 [6] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 761 Associated Channel", RFC 5586, June 2009. 763 [7] Bocci, M. and G. Swallow, "MPLS-TP Identifiers", draft-ietf- 764 mpls-tp-identifiers-01 (work in progress), June 2010. 766 [8] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and 767 S.Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, 768 September 2009. 770 9.2. Informative References 772 [9] Nabil Bitar, et. al, "Requirements for Multi-Segment Pseudowire 773 Emulation Edge-to-Edge (PWE3) ", RFC5254, October 2008. 775 Author's Addresses 777 Sami Boutros 778 Cisco Systems, Inc. 779 Email: sboutros@cisco.com 781 Siva Sivabalan 782 Cisco Systems, Inc. 783 Email: msiva@cisco.com 785 Rahul Aggarwal 786 Juniper Networks. 787 EMail: rahul@juniper.net 789 Martin Vigoureux 790 Alcatel-Lucent. 791 Email: martin.vigoureux@alcatel-lucent.com 793 Xuehui Dai 794 ZTE Corporation. 795 Email: dai.xuehui@zte.com.cn 796 George Swallow 797 Cisco Systems, Inc. 798 Email: swallow@cisco.com 800 David Ward 801 Juniper Networks. 802 Email: dward@juniper.net 804 Stewart Bryant 805 Cisco Systems, Inc. 806 Email: stbryant@cisco.com 808 Carlos Pignataro 809 Cisco Systems, Inc. 810 Email: cpignata@cisco.com 812 Nabil Bitar 813 Verizon. 814 Email: nabil.bitar@verizon.com 816 Italo Busi 817 Alcatel-Lucent. 818 Email: italo.busi@alcatel-lucent.it 820 Lieven Levrau 821 Alcatel-Lucent. 822 Email: llevrau@alcatel-lucent.com 824 Laurent Ciavaglia 825 Alcatel-Lucent. 826 Email: laurent.ciavaglia@alcatel-lucent.com 828 Bo Wu 829 ZTE Corporation. 830 Email: wu.bo@zte.com.cn 832 Jian Yang 833 ZTE Corporation. 834 Email: yang_jian@zte.com.cn 836 Full Copyright Statement 838 Copyright (c) 2008 IETF Trust and the persons identified as the 839 document authors. All rights reserved. 841 This document is subject to BCP 78 and the IETF Trust's Legal 842 Provisions Relating to IETF Documents 843 (http://trustee.ietf.org/license-info) in effect on the date of 844 publication of this document. Please review these documents 845 carefully, as they describe your rights and restrictions with respect 846 to this document. 848 All IETF Documents and the information contained therein are provided 849 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 850 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 851 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 852 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 853 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 854 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 855 FOR A PARTICULAR PURPOSE. 857 Intellectual Property Statement 859 The IETF takes no position regarding the validity or scope of any 860 Intellectual Property Rights or other rights that might be claimed to 861 pertain to the implementation or use of the technology described in 862 this document or the extent to which any license under such rights 863 might or might not be available; nor does it represent that it has 864 made any independent effort to identify any such rights. 866 Copies of Intellectual Property disclosures made to the IETF 867 Secretariat and any assurances of licenses to be made available, or 868 the result of an attempt made to obtain a general license or 869 permission for the use of such proprietary rights by implementers or 870 users of this specification can be obtained from the IETF on-line IPR 871 repository at http://www.ietf.org/ipr. 873 The IETF invites any interested party to bring to its attention any 874 copyrights, patents or patent applications, or other proprietary 875 rights that may cover technology that may be required to implement 876 any standard or specification contained in an IETF Document. Please 877 address the information to the IETF at ietf-ipr@ietf.org. 879 The definitive version of an IETF Document is that published by, or 880 under the auspices of, the IETF. Versions of IETF Documents that are 881 published by third parties, including those that are translated into 882 other languages, should not be considered to be definitive versions 883 of IETF Documents. The definitive version of these Legal Provisions 884 is that published by, or under the auspices of, the IETF. Versions of 885 these Legal Provisions that are published by third parties, including 886 those that are translated into other languages, should not be 887 considered to be definitive versions of these Legal Provions. 889 For the avoindance od doubt, each Contributor to the UETF Standards 890 Process licenses each Contribution that he or she makes as part of 891 the IETF Standards Process to the IETF Trust pursuant to the 892 provisions of RFC 5378. No language to the contrary, or terms, 893 conditions or rights that differ from or are inconsistent with the 894 rights and licenses granted under RFC 5378, shall have any effect and 895 shall be null and void, whether published or posted by such 896 Contributor, or included with or in such Contribution. 898 Acknowledgment 900 Funding for the RFC Editor function is currently provided by the 901 Internet Society.