idnits 2.17.1 draft-boutros-mpls-tp-performance-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (March 9, 2009) is 5520 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) ** Obsolete normative reference: RFC 4379 (ref. '3') (Obsoleted by RFC 8029) == Outdated reference: A later version (-03) exists of draft-boutros-mpls-tp-loopback-01 -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-02) exists of draft-bryant-mpls-tp-ach-tlv-00 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-tp-gach-gal-02 Summary: 2 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 Sami Boutros (Ed.) 3 Internet Draft Siva Sivabalan(Ed.) 4 Intended status: Standards Track George Swallow 5 Expires: September 2009 David Ward 6 Stewart Bryant 7 Cisco Systems, Inc. 9 March 9, 2009 11 Performance Monitoring of MPLS Transport Profile LSP 12 draft-boutros-mpls-tp-performance-01.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on September 9, 2009. 37 Abstract 39 This document specifies an extension to MPLS Operation, 40 Administration, and Maintenance (OAM) for monitoring the performance 41 of an MPLS Transport Profile(MPLS-TP) Label Switched Path (LSP) with 42 respect to packet loss and unidirectional delay/jitter. 44 Table of Contents 45 1. Introduction...................................................2 46 2. Terminology....................................................4 47 3. MPLS-TP Performance Monitor Mechanism..........................5 48 4. MPLS-OAM Performance Message...................................5 49 4.1. In-band Message Identification............................5 50 4.2. Out-of-band Message Identification........................6 51 4.3. MPLS-OAM Performance control Message Format...............6 52 4.4. Performance Request TLV...................................8 53 4.5. Packet Loss Reporting TLV.................................9 54 4.6. Performance Removal.......................................9 55 4.7. MPLS-OAM PF Packet........................................9 56 4.8. Monitoring regular PW packets............................10 57 4.9. Network Management System................................10 58 5. Operation.....................................................11 59 6. Security Considerations.......................................12 60 7. IANA Considerations...........................................12 61 8. References....................................................12 62 8.1. Normative References.....................................12 63 8.2. Informative References...................................13 64 Author's Addresses...............................................14 65 Full Copyright Statement.........................................14 66 Intellectual Property Statement..................................15 68 1. Introduction 70 In traditional transport networks, circuits such as T1 lines are 71 provisioned on multiple switches, and service providers should be 72 able to monitor the performance of such circuits for management 73 purpose. For example, when performance of a primary circuit degrades 74 backup circuit may be activated. An MPLS-TP bidirectional LSPs 75 emulate the traditional transport circuits and hence should provide 76 the same performance measurement capability. In this document, an 77 MPLS-TP LSP means either an MPLS transport LSP or an MPLS Pseudowire 78 (PW). 80 This document specifies an MPLS-TP LSP performance monitoring scheme 81 that is based on two new types of MPLS-OAM packets called "MPLS-OAM 82 Performance Control(PC)" and "MPLS-OAM Performance Flow(PF)". These 83 packets are sent at a rate that is acceptable to both sender and 84 receiver. The MPLS-OAM PC packets are used to setup an MPLS-TP LSP 85 for performance monitoring, and the MPLS-OAM PF packets are used as 86 the probes for collecting performance data. 88 Performance can be monitored using one of the two following modes: 90 On-Demand: An MPLS-TP LSP's performance is monitored only based on 91 operator request, i.e., performance is not monitored automatically 92 as soon as the LSP becomes operational. 94 Continuous: In this mode, it is assumed that an MPLS-TP LSP is 95 configured for continuous performance monitoring. Also, the 96 relevant configuration can be applied to and removed from an MPLS- 97 TP LSP at any time during the life of the LSP. When configured for 98 continuous performance monitoring, an MPLS-TP LSP's performance is 99 continuously monitored as soon as it becomes operational. 101 The following features are common to both the on-demand and the 102 continuous modes: 104 1. The LSP can be optionally locked for data traffic. 106 2. MPLS-OAM PC and PF packets can be consumed by either a Maintenance 107 Intermediate Point (MIP) or a Maintenance End Point (MEP). 109 3. MPLS-OAM PC and PF packets are intercepted at any MIP based on 110 MPLS TTL expiry, and are intercepted at MEP simply because it is 111 the egress LSR of the LSP (i.e., regardless of the TTL value). 113 4. More than one MPLS-OAM performance flows can be maintained 114 simultaneously from a MEP to any MIP or the other MEP. 116 5. The transmission rate of MPLS-OAM PF packets MUST be acceptable to 117 both the sender and the receiver, otherwise transmission of such 118 packets MUST NOT begin. The rate is negotiated via MPLS-OAM PC 119 packets. 121 6. An MPLS OAM PF packets contains sequence number and time-stamp to 122 measure packet loss and unidirectional delay/jitter. 124 In the continuous mode, the MEP at which performance is monitored is 125 configured to send MPLS-OAM PF packets continuously to different MIPs 126 and/or the other MEP. The configuration specifies: 128 . Rate at which the MPLS-OAM PF packets are sent. 130 . Addresses of MIPs/MEP to which the MPLS-OAM PF packets are 131 destined. 133 . Whether or not performance is monitored in both directions of the 134 MPLS-TP LSP. 136 . Rate at which the number of lost MPLS-OAM PF packets should be 137 reported to the sender MEP. 139 The proposed mechanism is based on a set of new TLVs which can be 140 transported using one of the following methods: 142 1. Using in-band MPLS OAM messages which are forwarded as MPLS 143 packets (non-IP based). 145 2. Using in-band LSP-Ping extensions defined in [3] where IP/UDP 146 packets are used (IP-based). The LSP-Ping messages are sent 147 using the codepoint defined in [2]. 149 Method (1) and (2) are referred to as "Non-IP option" and "LSP-Ping 150 option" respectively in the rest of the document. 152 Conventions used in this document 154 In examples, "C:" and "S:" indicate lines sent by the client and 155 server respectively. 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in RFC-2119 [1]. 161 2. Terminology 163 ACH: Associated Channel Header 165 LSR: Label Switching Router 167 MEP: Maintenance End Point 169 MIP: Maintenance Intermediate Point 171 MPLS-OAM: MPLS Operations, Administration and Maintenance 173 MPLS-TP: MPLS Transport Profile 175 MPLS-TP LSP: Bidirectional Label Switch Path representing a circuit 177 NMS: Network Management System 179 PC: Performance Control 181 PF: Performance Flow 182 PM: Performance Monitoring 184 TLV: Type Length Value 186 TTL: Time To Live 188 3. MPLS-TP Performance Monitor Mechanism 190 For the Non-IP option, the proposed mechanism uses two new code 191 points in the Associated Channel Header (ACH) described in [6]. The 192 LSP-Ping option is in compliance to the specifications [2],[3], and 193 [7]. 195 The proposed mechanism requires a set of new TLVs called Performance 196 Request TLV, Performance Loss Report TLV. 198 In addition, the proposed mechanism uses the Address and LSPI TLVs 199 defined in [5]. Moreover, it can also be used in conjunction with the 200 data-locking mechanism defined in [4]. 202 The new TLVs are described below. 204 4. MPLS-OAM Performance Message 206 4.1. In-band Message Identification 208 In the in-band option, under MPLS label stack of the MPLS-TP LSP, the 209 ACH with "MPLS-TP Performance Control" code point indicates that the 210 message is an MPLS OAM Performance Control (PC) message. The ACH with 211 code point "MPLS-TP Performance Flow" indicates that the message is 212 an MPLS OAM Performance Flow (PF) message. 214 0 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 |0 0 0 1|Version|Flags | 0xHH MPLS-TP Performance | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 Figure 1: ACH Indication of MPLS-TP Performance Control 222 The first nibble (0001b) indicates the ACH. The version and the 223 reserved values are both set to 0 as specified in [1]. MPLS-TP 224 Performance control and performance flow code points = 0xHH and 0xhh. 225 [HH and hh to be assigned by IANA from the PW Associated Channel Type 226 registry.] 228 4.2. Out-of-band Message Identification 230 [To be added] 232 4.3. MPLS-OAM Performance control Message Format 234 The format of an MPLS-OAM Performance control Message is shown below. 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Version | Message Type | Operation | Reserved | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Return Code | Cause Code | Message Length | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Sender's Handle | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Message ID | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | TLV's | 248 ~ ~ 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 Figure 2: MPLS-TP OAM Message Format 253 Version 254 The Version Number is currently 1. 256 Message Type 257 Four message types are defined as shown below. 259 Message Type Description 260 ------------ ------------- 261 0x1 Performance Request 262 0x2 Performance Report 263 0x3 Performance Removal 264 0x4 Performance Response 266 Operation 267 Two operations are defined as shown below. In the unidirectional 268 mode, the receiver MIP or MEP does not have to maintain a PM flow 269 towards the sender MEP. But, in the bidirectional mode, the receiver 270 MIP or MEP MUST maintain a PM flow towards the sender MEP. 272 Operation Description 273 --------- ------------- 274 0x0 Unidirectional 275 0x1 Bidirectional 277 Sender's Handle 278 The Sender's Handle is filled in by the sender. There are no 279 semantics associated with this handle. 281 Message Length 282 The total length of any included TLVs. 284 Message ID 285 The Message ID is set by the sender and is incremented everytime the 286 sender sends a new message. The receiver MUST include the Message ID 287 in the response. This way, the sender can correlate a reply with the 288 corresponding request. 290 Return code 292 Value Meaning 293 ----- ------- 294 0 Informational 295 1 Success 296 2 Failure 298 Cause code 300 Value Meaning 301 ----- ------- 302 1 Fail to match MPLS-TP LSP ID. 303 2 Malformed performance message received 304 3 One or more of the TLVs is/are unknown 305 4 Authentication failed 306 5 Specified PF Packet Rate cannot be supported 307 6 Specified Packet Loss Report Rate cannot be supported 309 Note that the MPLS-TP LSP whose performance is to be monitored is 310 identified by the LSP ID TLV as defined in [5] in the MPLS-OAM 311 performance message. 313 MPLS-TP performance control message may include authentication TLV 314 defined in [4]. 316 4.4. Performance Request TLV 318 0 1 2 3 319 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 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | type = TBD | length = 9 | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Performance Flow Packet Rate | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Packet Loss Report Rate | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 Figure 2: Performance Request TLV 330 When a MEP wants to monitor performance on an MPLS-TP, it sends an 331 MPLS-OAM PC packet with Performance Request TLV. The Performance 332 Request message can be intercepted by either a MIP (due to TTL 333 expiry) or a MEP (simply because it is the egress LSR). 335 Performance Flow Packet Rate (in packets per second) specifies the 336 maximum rate at which MPLS-OAM PF packets can be sent. 338 Packet loss Report Rate specifies the maximum rate at which the loss 339 of MPLS-OAM PF packets can be reported to the sender MEP. 341 The receiver MIP or MEP MUST send either an ACK or NAK response to 342 the sender MEP using an MPLS OAM performance response message. An ACK 343 response is sent if the receiver can support the specified rates. 344 Otherwise, a NAK response is sent. Until an ACK response is received, 345 the sender MEP MUST NOT assume that the MPLS-TP LSP is ready for 346 performance monitoring. 348 If multiple Performance Request TLVs are present, only the first TLV 349 is taken into consideration. 351 4.5. Packet Loss Reporting TLV 353 0 1 2 3 354 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 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | type = TBD | length = 8 | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Lost packets | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Total Number of Packets Sent | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 Figure 4: Packet Loss Report TLV 365 Performance monitor report MPLS-OAM Messages will be sent at the rate 366 that does not exceed the maximum packet loss reporting rate specified 367 in the MPLS-OAM Performance Request TLV. 369 This TLV includes the number of lost MPLS-OAM PF packets as well as 370 the total number of MPLS-OAM PF flow packets that it must have 371 received from the sender. The receiver figures out the latter using 372 the sequence number in the MPLS-OAM PF packets (described below). 374 4.6. Performance Removal 376 When performance monitor mode operation of an MPLS-TP LSP is no 377 longer required, the MEP that previously sent the MPLS OAM 378 Performance request message sends another MPLS OAM performance 379 removal message. 381 The receiver MEP or MIP MUST send either an ACK or NAK response to 382 the sender MEP using an MPLS OAM performance response message. An ACK 383 response is sent if the MPLS-TP LSP is already monitoring 384 performance. Otherwise, a NAK response is sent. 386 4.7. MPLS-OAM PF Packet 388 When the performance of MPLS-TP LSP is monitored, MPLS-OAM PF packets 389 are sent from the sender MEP to the MEP/MIP end of the flow. A PF 390 packet contains a sequence number and a time-stamp using which the 391 receiver can calculate packet loss and one-way delay/jitter. 393 0 1 2 3 394 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 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | MPLS Label stack | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Label with EOS bit set | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 |0 0 0 1|Version|Reserved |0xHH (MPLS-TP Performance Flow)| 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Sequence Number | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | TimeStamp | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 Figure 5: MPLS-OAM PF Packet 409 4.8. Monitoring regular PW packets 411 When the performance of PW is monitored, in continuous mode, regular 412 PW data packets can be used to monitor performance. PW packets in the 413 presence of CW contain a sequence number that can be used to measure 414 packets loss. 416 Data traffic is sent over an MPLS-TP PW using the format shown 417 below:- 419 0 1 2 3 420 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 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | PSN LSP label stack (as required) | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | PW label with EOS set | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 |0 0 0 0| Flags |FRG| Length | Sequence Number | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 4.9. Network Management System 431 An operator should be able to provision any given LSR to: 433 1. Lock/Unlock any MPLS-TP LSP. 435 2. Send MPLS OAM packets from a MEP and notify NMS when MPLS OAM 436 response arrives. 438 When NMS is used to provision any of the above the functionality, the 439 corresponding MPLS OAM message is not used. 441 5. Operation 443 Consider an MPLS-TP LSP LSR-1 <--> LSR-2 <--> LSR-3 <--> LSR-4 <--> 444 LSR-5. LSR-1 and LSR-5 are ingress and egress LSR for the respective 445 direction, and LSR-1 and LSR-5 act as MEPs and LSR-2, LSR-3 and LSR-5 446 acts as a MIPs. 448 Assume that the objective is to evaluate the performance of the 449 segment between LSR-1 and LSR-2 at LSR-1. Thus, LSR-2 is the 450 destination for the MPLS-OAM PM packets. 452 1- LSR-1 sends an optional Lock Request MPLS-OAM message to LSR-5 453 (egress LSR) to take the MPLS-TP LSP out of service 455 2- LSR-5 takes the MPLS-TP LSP out of service from data-plane and 456 sends an ACK MPLS-OAM message back to LSR-1 458 3- LSR-1 sends a PM Request MPLS-OAM message to LSR-2 containing its 459 source address the MPLS-TP LSP ID, and destination address of 460 LSR-2, maximum rate at which PF packets are to be sent, maximum 461 packet loss report rate (back to LSR-1), and an indication as to 462 whether or not LSR-2 also needs to send MPLS-OAM PM packets. 464 4- LSR-2 verifies the LSP ID, and the destination address and sends 465 a performance response MPLS-OAM message with return code 466 1(success) back to LSR-1 if it can handle the specified PM packet 467 transmission and loss reporting rate, otherwise LSR-2 sends the 468 performance response MPLS-OAM message with return code 2(failure) 469 back to LSR-1 with the following cause codes: 471 1. if destination address or LSP-ID cannot be matched, it sends 472 a response with cause code 1. 474 2. if the message is malformed, it sends a response with the 475 cause code 2. 477 3. if any of the TLV is not known, it sends a response with 478 cause code 3. It may also include the unknown TLVs. 480 4. if message authentication fails, it sends a response with 481 the cause code 4. 483 5. if the specified PF packet rate cannot be handled, it sends 484 a response with cause code 5. 486 6. if the specified packet loss report rate cannot be 487 supported, it sends a response with cause code 6. 489 Note that MPLS TTL value is set to 255 in the response message. 491 After receiving the ACK from LSR-2 for the MPLS-OAM PM request, 492 MPLS-OAM PF packets are transmitted on the MPLS-TP LSP. 494 Both LSR-1 and LSR-2 keep a count of the lost MPLS-OAM PF packets. 496 The receiver LSR computes the number of lost MPLS-OAM PF flow 497 packets using the sequence number. Note that the sequence number 498 equals the total number of packets that must have received in the 499 absence of any packet loss. 501 The receiver periodically send the number of lost MPLS-OAM PF 502 packets as well as the total number of MPLS-OAM PF packets that it 503 must have received to the sender. 505 Removal of PM mode (only for on-demand mode) 507 1- LSR-1 sends an MPLS-OAM message to LSR-2 in order to stop 508 operating the MPLS-TP LSP in Performance Management mode. 510 2- LSR-2 sends its latest Packet Loss Report to LSR-1 via an MPLS-OAM 511 message. 513 3- LSR-1 sends an Unlock Request MPLS-OAM message to LSR-5 515 4- LSR-5 puts the MPLS-TP LSP back in service and sends an ACK MPLS- 516 OAM message back to LSR-1. 518 6. Security Considerations 520 The security considerations for the authentication TLV need further 521 study. 523 7. IANA Considerations 525 To be added. 527 8. References 529 8.1. Normative References 531 [1] Bradner. S, "Key words for use in RFCs to Indicate Requirement 532 Levels", RFC 2119, March, 1997. 534 [2] T. Nadeau, et. al, "Pseudowire Virtual Circuit Connectivity 535 Verification (VCCV): A Control Channel for Pseudowires ", RFC 536 5085, December 2007. 538 [3] K. Kompella, G. Swallow, "Detecting Multi-Protocol Label 539 Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. 541 [4] S. Boutros, et. al., "Operating MPLS Transport Profile LSP in 542 Loopback Mode", draft-boutros-mpls-tp-loopback-01.txt, Work in 543 Progress, December 2008. 545 8.2. Informative References 547 [5] S. Boutros, et. al., "Definition of ACH TLV Structure", draft- 548 bryant-mpls-tp-ach-tlv-00.txt, Work in Progress, January 2009. 550 [6] M. Bocci, et. al., "MPLS Generic Associated Channel", draft- 551 ietf-mpls-tp-gach-gal-02.txt, work in progress, January 6, 552 2009. 554 [7] Nabil Bitar, et. al, "Requirements for Multi-Segment Pseudowire 555 Emulation Edge-to-Edge (PWE3) ", RFC5254, October 2008. 557 Author's Addresses 559 Sami Boutros 560 Cisco Systems, Inc. 561 3750 Cisco Way 562 San Jose, California 95134 563 USA 564 Email: sboutros@cisco.com 566 Siva Sivabalan 567 Cisco Systems, Inc. 568 2000 Innovation Drive 569 Kanata, Ontario, K2K 3E8 570 Canada 571 Email: msiva@cisco.com 573 George Swallow 574 Cisco Systems, Inc. 575 300 Beaver Brook Road 576 Boxborough , MASSACHUSETTS 01719 577 United States 578 Email: swallow@cisco.com 580 David Ward 581 Cisco Systems, Inc. 582 3750 Cisco Way 583 San Jose, California 95134 584 USA 585 Email: wardd@cisco.com 587 Stewart Bryant 588 Cisco Systems, Inc. 589 250, Longwater, Green Park, 590 Reading RG2 6GB, UK 591 UK 592 Email: stbryant@cisco.com 594 Full Copyright Statement 596 Copyright (c) 2009 IETF Trust and the persons identified as the 597 document authors. All rights reserved. 599 This document is subject to BCP 78 and the IETF Trust's Legal 600 Provisions Relating to IETF Documents in effect on the date of 601 publication of this document (http://trustee.ietf.org/license-info). 602 Please review these documents carefully, as they describe your rights 603 and restrictions with respect to this document. 605 All IETF Documents and the information contained therein are provided 606 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 607 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 608 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 609 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 610 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 611 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 612 FOR A PARTICULAR PURPOSE. 614 Intellectual Property Statement 616 The IETF takes no position regarding the validity or scope of any 617 Intellectual Property Rights or other rights that might be claimed to 618 pertain to the implementation or use of the technology described in 619 this document or the extent to which any license under such rights 620 might or might not be available; nor does it represent that it has 621 made any independent effort to identify any such rights. 623 Copies of Intellectual Property disclosures made to the IETF 624 Secretariat and any assurances of licenses to be made available, or 625 the result of an attempt made to obtain a general license or 626 permission for the use of such proprietary rights by implementers or 627 users of this specification can be obtained from the IETF on-line IPR 628 repository at http://www.ietf.org/ipr. 630 The IETF invites any interested party to bring to its attention any 631 copyrights, patents or patent applications, or other proprietary 632 rights that may cover technology that may be required to implement 633 any standard or specification contained in an IETF Document. Please 634 address the information to the IETF at ietf-ipr@ietf.org. 636 The definitive version of an IETF Document is that published by, or 637 under the auspices of, the IETF. Versions of IETF Documents that are 638 published by third parties, including those that are translated into 639 other languages, should not be considered to be definitive versions 640 of IETF Documents. The definitive version of these Legal Provisions 641 is that published by, or under the auspices of, the IETF. Versions of 642 these Legal Provisions that are published by third parties, including 643 those that are translated into other languages, should not be 644 considered to be definitive versions of these Legal Provisions. 646 For the avoidance of doubt, each Contributor to the UETF Standards 647 Process licenses each Contribution that he or she makes as part of 648 the IETF Standards Process to the IETF Trust pursuant to the 649 provisions of RFC 5378. No language to the contrary, or terms, 650 conditions or rights that differ from or are inconsistent with the 651 rights and licenses granted under RFC 5378, shall have any effect and 652 shall be null and void, whether published or posted by such 653 Contributor, or included with or in such Contribution. 655 Acknowledgment 657 Funding for the RFC Editor function is currently provided by the 658 Internet Society.