idnits 2.17.1 draft-bhh-mpls-tp-oam-y1731-08.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([2], [8]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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: The transmission period of the CCM MUST always be the configured period and MUST not change unless the operator reconfigures it. This is a fundamental requirement to allow deterministic and predictable protocol behavior: in transport networks the operator configures and fully controls the repetition rate of pro-active CC-V. -- The document date (January 11, 2012) is 4486 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) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Downref: Normative reference to an Informational draft: draft-ietf-mpls-tp-oam-framework (ref. '6') == Outdated reference: A later version (-08) exists of draft-ietf-mpls-tp-li-lb-02 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-tp-identifiers-02 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group I. Busi (Ed) 2 Internet Draft Alcatel-Lucent 3 Intended status: Standard Track H. van Helvoort (Ed) 4 J. He (Ed) 5 Huawei 7 Expires: July 2012 January 11, 2012 9 MPLS-TP OAM based on Y.1731 10 draft-bhh-mpls-tp-oam-y1731-08.txt 12 Abstract 14 This document describes methods to leverage Y.1731 [2] Protocol Data 15 Units (PDU) and procedures (state machines) to provide a set of 16 Operation, Administration, and Maintenance (OAM) mechanisms that 17 meets the MPLS Transport Profile (MPLS-TP) OAM requirements as 18 defined in [8]. 20 In particular, this document describes the MPLS-TP technology 21 specific encapsulation mechanisms to carry these OAM PDUs within 22 MPLS-TP packets to provide MPLS-TP OAM capabilities in MPLS-TP 23 networks. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that other 32 groups may also distribute working documents as Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress". 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. 57 Table of Contents 59 1. Introduction.................................................4 60 1.1. Contributing Authors....................................5 61 2. Conventions used in this document............................5 62 2.1. Terminology.............................................6 63 3. Encapsulation of OAM PDU in MPLS-TP..........................6 64 4. MPLS-TP OAM Packet Formats...................................7 65 4.1. Continuity Check Message (CCM)..........................8 66 4.1.1. MEG ID Formats.....................................9 67 4.2. OAM Loopback (LBM/LBR)..................................9 68 4.2.1. Format of MEP and MIP ID TLVs.....................12 69 4.3. Alarm Indication Signal (AIS)..........................16 70 4.4. Lock Reporting (LCK)...................................16 71 4.5. Test (TST).............................................17 72 4.6. Loss Measurement (LMM/LMR).............................17 73 4.7. One-way delay measurement (1DM)........................17 74 4.8. Two-way delay Measurement Message/Reply (DM)...........17 75 4.9. Client Signal Fail (CSF)...............................18 76 5. MPLS-TP OAM Procedures......................................18 77 5.1. Continuity Check Message (MT-CCM) procedures...........18 78 5.2. OAM Loopback (MT-LBM/LBR) procedures...................20 79 5.3. Alarm Indication Signal (MT-AIS) procedures............21 80 5.4. Lock Reporting (LCK)...................................22 81 5.5. Test (TST).............................................23 82 5.6. Loss Measurement (LMM/LMR).............................23 83 5.7. One-way delay measurement (1DM)........................23 84 5.8. Two-way delay Measurement Message/Reply (DM)...........23 85 5.9. Client Signal Fail (CSF)...............................23 86 6. Security Considerations.....................................23 87 7. IANA Considerations.........................................23 88 8. Acknowledgments.............................................23 89 9. References..................................................25 90 9.1. Normative References...................................25 91 9.2. Informative References.................................25 93 1. Introduction 95 This document describes the method for leveraging Y.1731 [2] Protocol 96 Data Units (PDUs) and procedures to provide a set of Operation, 97 Administration, and Maintenance (OAM) mechanisms that meet the MPLS 98 Transport Profile (MPLS-TP) OAM requirements as defined in [8]. 100 This version of the draft does not introduce any technical change to 101 the -06 version of this draft. 103 ITU-T Recommendation Y.1731 [2] specifies: 105 o OAM PDUs and procedures that meet the transport networks 106 requirements for OAM 108 o Encapsulation mechanisms to carry these OAM PDUs within Ethernet 109 frames to provide Ethernet OAM capabilities in Ethernet networks 111 Although Y.1731 is focused on Ethernet OAM, the definition of OAM 112 PDUs and procedures are technology independent and can also be used 113 in other packet technologies (e.g., MPLS-TP) provided that the 114 technology specific encapsulation is defined. 116 The OAM toolset defined in Y.1731 [2] serves as a benchmark for a 117 high performance, comprehensive suite of packet transport OAM 118 capabilities. It can be provided by lightweight protocol design and 119 supports operational simplicity by providing commonality with the 120 established operation models utilized in other transport network 121 technologies (e.g., SDH/SONET and OTN). 123 This document describes mechanisms for MPLS-TP OAM that reuse the 124 same OAM PDUs and procedures defined in Y.1731 [2], together with the 125 necessary MPLS-TP technology specific encapsulation mechanisms. 127 The advantages offered by this toolset are summarized below: 129 o Simplify the operations for the network operators and service 130 providers that have to test and maintain a single general OAM 131 protocol set when operating LSP, PW and VPLS networks. 133 o Accelerate the market adoption of MPLS-TP since Y.1731 is already 134 mature, supported, and deployed. 136 o Reduce the complexity and increase the reuse of code for 137 implementation in packet transport devices that may support both 138 Ethernet and MPLS-TP capabilities, e.g. VPLS and H-VPLS 139 applications. 141 It is worth noting that multi-vendor interoperable implementations of 142 the OAM mechanisms described in this document already exist to meet 143 the essential OAM requirements for MPLS-TP deployments in PTN 144 applications as described in [9]. 146 Ethernet OAM is also defined by IEEE 802.1ag [14]. IEEE 802.1ag and 147 ITU-T Y.1731 have been developed in cooperation by IEEE and ITU. They 148 support a common subset of OAM functions. ITU-T Y.1731 further 149 extends this common subset with additional OAM mechanisms that are 150 important for the transport network (e.g. AIS, DM, LM). 152 This document does not deprecate existing MPLS and PW OAM mechanisms 153 nor preclude definition of other MPLS-TP OAM tools. 155 The mechanisms described in this document, when used to provide 156 MPLS-TP PW OAM functions, are open to support the OAM message mapping 157 procedures defined in [10]. In order to support those procedures, the 158 PEs MUST map the states of the procedures defined in Y.1731 to the PW 159 defect states defined in [10]. 161 The mapping procedures are outside the scope of this document. 163 In the rest of this document the term "OAM PDU" is used to indicate 164 an OAM PDU whose format and associated procedures are defined in 165 Y.1731 [2] and that this document proposes to be used to provide 166 MPLS-TP OAM functions. 168 1.1. Contributing Authors 170 Italo Busi, Huub van Helvoort, Jia He, Christian Addeo, Alessandro 171 D'Alessandro, Simon Delord, John Hoffmans, Ruiquan Jing, Kam Lam, 172 Wang Lei, Han Li, Vishwas Manral, Masahiko Mizutani, Manuel Paul, 173 Josef Roese, Vincenzo Sestito, Yuji Tochio, Munefumi Tsurusawa, 174 Maarten Vissers, Rolf Winter 176 2. Conventions used in this document 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in RFC-2119 [1]. 182 2.1. Terminology 184 ACH Associated Channel Header 186 G-ACh Generic Associated Channel 188 GAL G-ACh Label 190 ME Maintenance Entity 192 MEL MEG Level 194 MEG Maintenance Entity Group 196 MEP Maintenance End Point 198 MIP Maintenance Intermediate Point 200 PTN Packet Transport Network 202 TLV Type Length Value 204 3. Encapsulation of OAM PDU in MPLS-TP 206 Although Y.1731 is focused on Ethernet OAM, the definition of OAM 207 PDUs and procedures are technology independent. 209 When used to provide Ethernet OAM capabilities, these PDUs are 210 encapsulated into an Ethernet frame where an Ethernet header is 211 prepended to the OAM PDUs. 213 The MAC DA is used to identify the MEPs and MIPs where the OAM PDU 214 needs to be processed. The EtherType is used to distinguish OAM 215 frames from user data frames. 217 Within MPLS-TP OAM Framework [6], OAM packets are distinguished from 218 user data packets using the GAL and ACH [5] construct and they are 219 addressed to MEPs or MIPs using existing MPLS forwarding mechanisms 220 (i.e. label stacking and TTL expiration). It is therefore possible to 221 reuse the OAM PDUs defined in [2] within MPLS-TP and encapsulate them 222 within ACH. 224 A single ACH Channel Type (0xXXXX) is required to identify the 225 presence of Y.1731 OAM PDU. Within the OAM PDU, the OpCode field, 226 defined in [2], allows identifying the specific OAM PDU. 228 OAM PDUs are encapsulated using the ACH, according to [5], as 229 described in Figure 1 below. 231 0 1 2 3 232 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 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| Y.1731 Channel Type (0xXXXX) | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | MEL | Version | OpCode | Flags | TLV Offset | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | | 239 + + 240 | OAM function specific fields | 241 | (Y.1731 based) | 242 + + 243 : ... : 244 | | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 Figure 1 G-ACh Packet carrying a Y.1731 PDU 249 Moreover, MPLS-TP relies upon a different mechanism for supporting 250 tandem connection monitoring (i.e. label stacking) than the fixed MEL 251 (Maintenance Entity Group Level) field used in Ethernet. 253 Therefore in MPLS-TP the MEL field is allowed not to be used for 254 supporting tandem connection monitoring. 256 When OAM PDUs are used in MPLS-TP, the MEL field MUST be set on 257 transmission and checked at reception for compliancy with Y.1731 [2]. 259 The MEL value to set and check MUST be configurable. The DEFAULT 260 value MUST be "111". With co-routed bidirectional transport paths, 261 the configured MEL MUST be the same in both directions. 263 The OpCode field identifies the type of the OAM PDU. 265 The setting of the Version, Flags and TLV Offset is OpCode specific 266 and described in Y.1731 [2]. 268 4. MPLS-TP OAM Packet Formats 270 This section describes the OAM functions that can be supported 271 reusing the OAM PDUs and procedures defined in Y.1731 [2] to meet 272 MPLS-TP OAM Requirements, as defined in [8]. 274 This document is proposing not to use the Y.1731 MCC OAM PDU in 275 MPLS-TP. The solution proposed in [7], where MCC PDU is directly 276 encapsulated within an ACH with a PID, SHOULD be used instead. 278 The LTM/LTR OAM PDUs, as currently defined Y.1731 [2], are tracing 279 the path for a specific MAC address: this tool is therefore 280 addressing a different requirement than the "Route Tracing" 281 functional requirement described in section 2.2.4 of RFC 5860 [8]. 282 Their purpose is to test the MAC Address Forwarding tables. Due to 283 the fact that MPLS-TP forwarding is not based on the MAC Address 284 Forwarding tables, these tools are not applicable to MPLS-TP as 285 currently defined. 287 Procedures for supporting the route tracing MPLS-TP OAM functional 288 requirement (section 2.2.4 of RFC 5860 [8]) are outside the scope of 289 this document. 291 4.1. Continuity Check Message (CCM) 293 The CCM PDU is defined in Y.1731 [2]. When encapsulated within MPLS- 294 TP as described in section 3, it can be used to support the following 295 MPLS-TP OAM functional requirements: 297 o Pro-active continuity check (section 2.2.2 of RFC 5860 [8]); 299 o Pro-active connectivity verification (section 2.2.3 of RFC 5860 300 [8]); 302 o Pro-active remote defect indication (section 2.2.9 of RFC 5860 303 [8]); 305 o Pro-active packet loss measurement (section 2.2.11 of RFC 5860 306 [8]). 308 Procedures for transmitting and receiving CCM PDUs are defined in 309 Y.1731 [2] and described in section 5.1. 311 It is worth noting that the use of CCM does not require any 312 additional status information other than the configuration parameters 313 and defect states. 315 The transmission period of the CCM MUST always be the configured 316 period and MUST not change unless the operator reconfigures it. This 317 is a fundamental requirement to allow deterministic and predictable 318 protocol behavior: in transport networks the operator configures and 319 fully controls the repetition rate of pro-active CC-V. 321 In order to perform pro-active Connectivity Verification, the CCM 322 packet contains a globally unique identifier of the source MEP, as 323 described in [6]. 325 The source MEP for LSPs, PWs and Sections is identified by combining 326 a globally unique MEG ID (see section 4.1.1) with a MEP ID that is 327 unique within the scope of the Maintenance Entity Group. 329 4.1.1. MEG ID Formats 331 The generic format for MEG ID is defined in Figure A-1 of Y.1731 [2]. 332 Different formats of MEG ID are allowed: the MEG ID format type is 333 identified by the MEG ID Format field. 335 The format of the ICC-based MEG ID is defined in Annex A of Y.1731 336 [2]. This format is applicable to MPLS-TP Sections, LSPs and PWs. 338 MPLS-TP supports also IP-based format for MEG ID. These formats are 339 still under definition in [12] and therefore outside the scope of 340 this document. 342 4.2. OAM Loopback (LBM/LBR) 344 The LBM/LBR PDUs, defined in Y.1731 [2]. When encapsulated within 345 MPLS-TP, as described in section 3, they can be used to support the 346 following MPLS-TP OAM functional requirements: 348 o On-demand bidirectional connectivity verification (section 2.2.3 349 of RFC 5860 [8]); 351 o Bidirectional in-service or out-of-service diagnostic test (section 352 2.2.5 of RFC 5860 [8]). 354 Procedures for transmitting and receiving LBM/LBR PDUs are defined in 355 Y.1731 [2] and described in section 5.2. 357 It is worth noticing that these OAM PDUs cover different functions 358 than those defined in [11]. 360 When the LBM/LBR is used for out-of-service diagnostic test, it is 361 REQUIRED that the transport path is locked on both MEPs before the 362 diagnostic test is performed. In transport networks, the transport 363 path is locked on both sides by network management operations. 364 However, single-ended procedures as defined in [11] MAY be used. 366 In order to allow proper identification of the target MEP/MIP the LBM 367 is addressed to, the LBM PDU MUST include the Target MEP/MIP ID TLV: 368 this TLV MUST be present in an LBM PDU and MUST be located at the top 369 of the TLVs (i.e., it MUST start at the offset indicated by the TLV 370 Offset field). 372 A LBM packet with the Target MIP/MEP ID equal to the ID of receiving 373 MIP or MEP is considered to be a valid LBM packet. Every field in the 374 LBM packet is copied to the LBR packet, only the OpCode field is 375 changed from LBM to LBR. 377 To allow proper identification of the actual MEP/MIP that has replied 378 to an LBM PDU, the LBR PDU MUST include the Replying MEP/MIP ID TLV: 379 this TLV MUST be present in an LBR PDU and it MUST be located at the 380 top of the TLVs (i.e., it MUST start at the offset indicated by the 381 TLV Offset field). 383 In order to simplify hardware based implementations, these TLVs have 384 been defined to have a fixed position (as indicated by the TLV Offset 385 field) and a fixed length (see clause 4.2.1). 387 It is worth noting that the MEP/MIP identifiers used in the Target 388 MEP/MIP ID and in the Replying MEP/MIP ID TLVs SHOULD be unique 389 within the scope of the MEG. When LBM/LBR OAM is used for 390 connectivity verification purposes, there are some misconnectivity 391 cases that could not be easily located by simply relying upon these 392 TLVs. In order to locate these misconnectivity configurations, the 393 LBM PDU SHOULD carry a Requesting MEP ID TLV that provides a globally 394 unique identification of the MEP that has originated the LBM PDU. 395 When the Requesting MEP ID TLV is present in the LBM PDU, the 396 replying MIP/MEP MUST check that the received requesting MEP 397 identifier matches with the expected requesting MEP identifier before 398 replying. In this case, the LBR PDU MUST carry the Requesting MEP ID 399 TLV confirming to the MEP the LBR PDU is sent to that the Requesting 400 MEP ID TLV in the LBM PDU has been checked before replying. 402 When LBM/LBR OAM is used for bidirectional diagnostic tests, the 403 Requesting MEP ID TLVs MUST NOT be included. 405 The format of the LBM and LBR PDUs are shown in Figure 2 and in 406 Figure 3. 408 0 1 2 3 409 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 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| Y.1731 Channel Type (0xXXXX) | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | MEL | Version | OpCode | Flags | TLV Offset | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Transaction ID/Sequence Number | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Target MEP/MIP ID TLV | 418 | ... | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | [optional Requesting MEP ID TLV] | 421 | ... | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | [other optional TLV starts here] | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | End TLV | 426 +-+-+-+-+-+-+-+-+-+ 428 Figure 2 LBM Packet Format 430 The OpCode MUST be set to 0x03 (LBM). The TLV Offset MUST be set to 431 0x04. The formats of the Target MEP/MIP ID TLV and of the Requesting 432 MEP ID TLV are defined in 4.2.1. 434 The Target MEP/MIP ID MUST be always present as the first TLV within 435 the LBM PDU. When present, the Requesting MEP ID TLV MUST immediately 436 follow the Target MEP/MIP ID TLV. 438 When the LBM packet is sent to a target MIP, the source MEP MUST know 439 the hop count to the target MIP and set the TTL field accordingly, as 440 described in [6]. 442 This solution allows supporting per-node and per-interface MIP 443 implementations as described in section 3.4 of [6]: 445 o In the case of a per-node MIP implementation, the LBM packet is 446 processed in the per-node MIP if the Target MEP/MIP ID matches the 447 per-node MIP identifier; otherwise, the LBM packet is dropped; 449 o In the case of a per-interface MIP implementation, the LBM packet 450 is processed in the ingress MIP if the Target MEP/MIP ID matches 451 the ingress MIP identifier; otherwise, the LBM packet is forwarded 452 to the egress port(s) together (i.e., fate sharing) with the user 453 data packets. The LBM packet is processed in the egress MIP if the 454 Target MEP/MIP ID matches the egress MIP identifier; otherwise, 455 the LBM packet is dropped. 457 0 1 2 3 458 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 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| Y.1731 Channel Type (0xXXXX) | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | MEL | Version | OpCode | Flags | TLV Offset | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Transaction ID/Sequence Number | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Replying MEP/MIP ID TLV | 467 | ... | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | [optional Requesting MEP ID TLV] | 470 | ... | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | [other optional TLV starts here] | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | End TLV | 475 +-+-+-+-+-+-+-+-+-+ 477 Figure 3 LBR Packet Format 479 The Replying MEP/MIP ID TLV MUST be present as the first TLV within 480 the LBR PDU. When present, the Requesting MEP ID TLV MUST follow the 481 Replying MEP/MIP ID TLV within the LBR PDU. 483 4.2.1. Format of MEP and MIP ID TLVs 485 The format of the Target and Replying MIP/MEP ID TLVs are shown in 486 Figure 4 and Figure 5. 488 0 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Type (0x21) | Length (25) | Sub-Type | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | ... | 494 | MEP/MIP Identifier (format is ID Sub-Type specific) | 495 | ... | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 Figure 4 Target MEP/MIP ID TLV format 500 0 1 2 3 501 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 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Type (0x22) | Length (25) | Sub-Type | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | ... | 506 | MEP/MIP Identifier (format is ID Sub-Type specific) | 507 | ... | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 Figure 5 Replying MEP/MIP ID TLV format 512 Different formats of MEP/MIP identifiers MAY be used: the format type 513 is described by the MEP/MIP ID Sub-Type field. 515 The "Discovery ingress/node MEP/MIP" and the "Discovery egress 516 MEP/MIP" identifiers MAY only be used within the LBM PDU (and MUST 517 NOT appear in an LBR PDU) for discovering the identifiers of the MEPs 518 or of the MIPs located at a given TTL distance from the MEP 519 originating the LBM PDU. 521 The format of the Target MEP/MIP ID TLV carrying a "Discovery 522 ingress/node MEP/MIP" is shown in Figure 6. 524 0 1 2 3 525 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 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Type (0x21) | Length (25) |Sub-Type (0x00)| 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | ... | 530 | MUST be ZERO | 531 | ... | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 Figure 6 Target MEP/MIP ID TLV format (discovery ingress/node 535 MEP/MIP) 537 The format of the Target MEP/MIP ID TLV carrying a "Discovery egress 538 MEP/MIP" is shown in Figure 7. 540 0 1 2 3 541 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 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Type (0x21) | Length (25) |Sub-Type (0x01)| 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | ... | 546 | MUST be ZERO | 547 | ... | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 Figure 7 Target MEP/MIP ID TLV format (discovery egress MEP/MIP) 552 The format of the Target or Replying MEP/MIP ID TLV carrying an 553 "ICC-based MEP ID" is shown in Figure 8. 555 0 1 2 3 556 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 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Type | Length (25) |Sub-Type (0x02)| 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | MEP ID | | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 562 | ... | 563 | MUST be ZERO | 564 | ... | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 Figure 8 Target or Replying MEP/MIP ID TLV format (ICC-based MEP ID) 569 The MEP ID is a 16-bit integer value identifying the transmitting MEP 570 within the MEG. 572 The format of the Target or Replying MEP/MIP ID TLV carrying an 573 "ICC-based MIP ID" is shown in Figure 9. 575 0 1 2 3 576 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 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Type | Length (25) |Sub-Type (0x03)| 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | ITU-T Carrier Code (ICC) | 581 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | | Node-ID | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Node-ID | IF-Num | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | IF-Num | | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 588 | ... | 589 | MUST be ZERO | 590 | ... | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 Figure 9 Target or Replying MEP/MIP ID TLV format (ICC-based MIP ID) 595 The ITU-T Carrier Code (ICC) is a code assigned to a network 596 operator/service provider and maintained by the ITU-T 597 Telecommunication Standardization Bureau (TSB) as per [13]. 599 The Node-ID is a numeric identifier of the node where the MIP is 600 located. Its assignment is a matter for the organization to which the 601 ICC has been assigned, provided that uniqueness within that 602 organization is guaranteed. 604 The IF-Num is a numeric identifier of the Access Point (AP) toward 605 the server layer trail, which can be either an MPLS-TP or a non 606 MPLS-TP server layer, where a per-interface MIP is located. Its 607 assignment is a matter for the node the MIP is located, provided that 608 uniqueness within that node is guaranteed. Note that the value 0 for 609 IF-Num is reserved to identify per-node MIPs. 611 MPLS-TP supports also IP-based format for MIP and MEP identifiers. 612 These formats are still under definition in [12] and therefore 613 outside the scope of this document. 615 The format of the Requesting MEP ID TLVs is shown in Figure 10. 617 0 1 2 3 618 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 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Type (0x23) | Length (53) | Loopback Ind. | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | MEP ID | | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 624 | | 625 | MEG ID | 626 | | 627 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | | Reserved (0x0000) | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 Figure 10Requesting MEP ID TLV format 633 The MEP ID and MEG ID carry the globally unique MEP ID as defined in 634 section 4.1.1. 636 The Reserved bits MUST be set to all-ZEROes in transmission and 637 ignored in reception. 639 The Loopback Indication MUST be set to 0x0000 when this TLV is 640 inserted in an LBM PDU and SHOULD be set to 0x0001 in the LBR PDU. 641 This is used to indicate that the value of this TLV has been checked 642 by the node that generated the LBR PDU. 644 4.3. Alarm Indication Signal (AIS) 646 The AIS PDU is defined in Y.1731 [2]. When encapsulated within MPLS- 647 TP, as described in section 3, it can be used to support the alarm 648 reporting MPLS-TP OAM functional requirement (section 2.2.8 of RFC 649 5860 [8]). 651 Procedures for transmitting and receiving AIS PDUs are defined in 652 Y.1731 [2] and described in section 5.3. 654 4.4. Lock Reporting (LCK) 656 The LCK PDU is defined in Y.1731 [2]. When encapsulated within MPLS- 657 TP, as described in section 3, it can be used to support the lock 658 reporting MPLS-TP OAM functional requirement (section 2.2.7 of RFC 659 5860 [8]). 661 Procedures for transmitting and receiving LCK PDUs are defined in 662 Y.1731 [2] and described in section 5.4. 664 4.5. Test (TST) 666 The TST PDU is defined in Y.1731 [2]. When encapsulated within MPLS- 667 TP, as described in section 3, it can be used to support the 668 uni-directional in-service or out-of-service diagnostic tests MPLS-TP 669 OAM functional requirement (section 2.2.8 of RFC 5860 [8]). 671 Procedures for transmitting and receiving TST PDUs are defined in 672 Y.1731 [2] and described in section 5.5. 674 4.6. Loss Measurement (LMM/LMR) 676 The LMM/LMR PDUs are defined in Y.1731 [2]. When encapsulated within 677 MPLS-TP, as described in section 3, they can be used to support on- 678 demand packet loss measurement MPLS-TP OAM functional requirement 679 (section 2.2.11 of RFC 5860 [8]). 681 Procedures for transmitting and receiving LMM/LMR PDUs are defined in 682 Y.1731 [2] and described in section 5.6. 684 4.7. One-way delay measurement (1DM) 686 The 1DM PDU is defined in Y.1731 [2]. When encapsulated within MPLS- 687 TP, as described in section 3, it can be used to support the on- 688 demand one-way packet delay measurement MPLS-TP OAM functional 689 requirement (section 2.2.12 of RFC 5860 [8]). 691 It can also be used to support proactive one-way delay measurement 692 MPLS-TP OAM functional requirement (section 2.2.12 of RFC 5860 [8]). 694 Procedures for transmitting and receiving 1DM PDUs are defined in 695 Y.1731 [2] and described in section 5.7. 697 4.8. Two-way delay Measurement Message/Reply (DM) 699 The DMM/DMR PDUs are defined in Y.1731 [2]. When encapsulated within 700 MPLS-TP, as described in section 3, they can be used to support on- 701 demand two-ways packet delay measurement MPLS-TP OAM functional 702 requirement (section 2.2.12 of RFC 5860 [8]). 704 They can also be used to support proactive two-ways packet delay 705 measurement MPLS-TP OAM functional requirement (section 2.2.12 of RFC 706 5860 [8]). 708 Procedures for transmitting and receiving DMM/DMR PDUs are defined in 709 Y.1731 [2] and described in section 5.8. 711 4.9. Client Signal Fail (CSF) 713 The CSF PDU is defined in Y.1731 Amendment 1 [3]. When encapsulated 714 within MPLS-TP, as described in section 3, it can be used to support 715 the client failure indication MPLS-TP OAM functional requirement 716 (section 2.2.10 of RFC 5860 [8]). 718 Procedures for transmitting and receiving CSF PDUs are defined in 719 Y.1731 Amendment 1 [3] and described in section 5.9. 721 5. MPLS-TP OAM Procedures 723 The high level procedures for processing Y.1731 OAM PDUs are 724 described in [2] and [3]. The technology independent procedures are 725 also applicable to MPLS-TP OAM. 727 More detailed and formal procedures for processing Y.1731 OAM PDUs 728 are defined in G.8021 [4]. Although the description in [4] is 729 Ethernet-specific, the technology independent procedures are also 730 applicable to MPLS-TP OAM. 732 This section describes the MPLS-TP OAM procedures based on the 733 technology independent ones defined in [2], [3] and [4]. 735 5.1. Continuity Check Message (MT-CCM) procedures 737 The MT-CCM PDU format is defined in section 4.1. 739 When CCM generation is enabled, the MEP MUST generate CCM OAM packets 740 with the periodicity and the PHB configured by the operator: 742 o MEL field MUST be set to the configured value (see section 3); 744 o Version field MUST be set to 0 (see section 3); 746 o OpCode field MUST be set to 0x01 (see section 4.1); 747 o RDI flag MUST be set, if the MEP asserts signal file. Otherwise, 748 it MUST be cleared; 750 o Reserved flags MUST be set to 0 (see section 4.1); 752 o Period field MUST be set according to the configured periodicity 753 (see Table 9-3 of [2]); 755 o TLV Offset field MUST be set to 70 (see section 4.1); 757 o Sequence Number MUST be set to 0 (see section 4.1); 759 o MEP ID and MEG ID fields MUST carry the configured values; 761 o The TxFCf field MUST carry the current value of the counter for 762 in-profile data packets transmitted towards the peer MEP, when 763 pro-active loss measurement is enabled. Otherwise it MUST be set 764 to 0. 766 o The RxFCb field MUST carry the current value of the counter for 767 in-profile data packets received from the peer MEP, if pro-active 768 loss measurement is enabled. Otherwise it MUST be set to 0. 770 o The TxFCb field MUST carry the value of TxFCf of the last received 771 CCM PDU from the peer MEP, if pro active loss measurement is 772 enabled. Otherwise it MUST be set to 0. 774 o Reserved field MUST be set to 0 (see section 4.1); 776 o End TLV MUST be inserted after the Reserved field (see section 777 4.1). 779 The transmission period of the CCM is always the configured period 780 and does not change unless the operator reconfigures it. 782 When a MEP receives a CCM OAM packet, it checks the various fields 783 (see Figure 8-19 of [4]). The following defects are detected as 784 described in clause 6.1 of [4]: dLOC, dUNL, dMMG, dUNM, dUNP, dUNPr 785 and dRDI. 787 If the Version, MEL, MEG and MEP fields are valid and pro-active loss 788 measurement is enabled, the values of the packet counters are 789 processed as described in clause 8.1.7.4 of [4]. 791 5.2. OAM Loopback (MT-LBM/LBR) procedures 793 The MT-LBM/LBR PDU formats are defined in section 4.2. 795 When an out-of-service OAM loopback function is performed, client 796 data traffic is disrupted in the diagnosed ME. The MEP configured for 797 the out-of-service test MUST transmit MT-LCK packets in the immediate 798 client (sub-)layer, as described in section 5.4. 800 When an in-service OAM loopback function is performed, client data 801 traffic is not disrupted and the packets with MT-LBM/LBR information 802 are transmitted in such a manner that a limited part of the service 803 bandwidth is utilized. The periodicity for packets with MT-LBM/LBR 804 information is pre-determined. 806 When on-demand OAM loopback is enabled at a MEP, the (requesting) MEP 807 MUST generate and send to one of the MIPs or the peer MEP MT-LBM OAM 808 packets with the periodicity and the PHB configured by the operator: 810 o MEL field MUST be set to the configured value (see section 3); 812 o Version field MUST be set to 0 (see section 3); 814 o OpCode field MUST be set to 0x03 (see section 4.2); 816 o Flags field MUST be set to all-ZEROes (see section 4.2); 818 o TLV Offset field MUST be set to 4 (see section 4.2); 820 o Transaction field is a 4-octet field that contains the transaction 821 ID/sequence number for the loop-back measurement; 823 o Target MEP/MIP-ID and Originator MEP-ID fields are set to carry 824 the configured values; 826 o Optional TLV field whose length and contents are configurable at 827 the requesting MEP. The contents can be a test pattern and an 828 optional checksum. Examples of test patterns include pseudo-random 829 bit sequence (PRBS) (2^31-1) as specified in sub-clause 5.8/O.150, 830 all '0' pattern, etc. For bidirectional diagnostic test 831 application, configuration is required for a test signal generator 832 and a test signal detector associated with the MEP; 834 o End TLV field is set to all-ZEROes (see section 4.2). 836 Whenever a valid MT-LBM packet is received by a (receiving) MIP or a 837 (receiving) MEP, an MT-LBR packet is generated and transmitted by the 838 receiving MIP/MEP to the requesting MEP: 840 o MEL field MUST be copied from the received MT-LBM PDU; 842 o Version field MUST be copied from the received MT-LBM PDU; 844 o OpCode field MUST be set to 2 (see section 4.2); 846 o Flags field MUST be copied from the received MT-LBM PDU; 848 o TLV Offset field MUST be copied from the received MT-LBM PDU; 850 o Transaction field MUST be copied from the received MT-LBM PDU 852 o The Target MEP/MIP-ID and Originator MEP-ID fields are is set to 853 the value which is copied from the last received MT-LBM PDU; 855 o The Optional TLV field MUST be copied from the received MT-LBM 856 PDU; 858 o End TLV field MUST be inserted after the last TLV field and it 859 MUST be copied from the last received MT-LBM PDU. 861 5.3. Alarm Indication Signal (MT-AIS) procedures 863 The MT-AIS PDU format is described in section 4.3. 865 When the server layer trail termination sink asserts signal fail, it 866 notifies the server/MT_A_Sk function that raises the aAIS consequent 867 action. The aAIS is cleared when the server layer trail termination 868 clears the signal fail condition and notifies the server/MT_A_Sk. 870 When the aAIS consequent action is raised, the server/MT_A_Sk MUST 871 continuously generate MPLS-TP OAM packets carrying the AIS PDU until 872 the aAIS consequent action is cleared: 874 o MEL field MUST be set to the configured value (see section 3): 876 o Version field MUST be set to 0 (see section 3): 878 o OpCode MUST be set to 0x21 (see section 4.3): 880 o Reserved flags MUST be set to 0 (see section 4.3): 882 o Period field MUST be set according to the configure periodicity 883 (see Table 9-4 of [2]); 885 o TLV Offset MUST be set to 0 (see section 4.3): 887 o End TLV MUST be inserted after the TLV Offset field (see section 888 4.3). 890 The DEFAULT periodicity for MT-AIS is once per second. 892 The generated AIS packets MUST be inserted in the incoming stream, 893 i.e., the output stream contains the incoming packets and the 894 generated AIS packets. 896 When a MEP receives an AIS packet with the correct MEL value, it MUST 897 detect the dAIS defect as described in clause 6.1 of [4]. 899 5.4. Lock Reporting (LCK) 901 The MT-LCK PDU format is described in section 4.4. 903 When the access to the server layer trail is administratively locked 904 by the operator, the server/MT_A_So and server/MT_A_Sk functions 905 raise the aLCK consequent action. The aLCK is cleared when the access 906 to the server layer trail is administratively unlocked. 908 When the aLCK consequent action is raised, the server/MT_A_So and 909 server/MT_A_Sk MUST continuously generate, on both directions, 910 MPLS-TP OAM packets carrying the LCK PDU until the aLCK consequent 911 action is cleared: 913 o MEL field MUST be set to the configured value (see section 3): 915 o Version field MUST be set to 0 (see section 3): 917 o OpCode MUST be set to 0x23 (see section 4.4): 919 o Reserved flags MUST be set to 0 (see section 4.4): 921 o Period field MUST be set according to the configure periodicity 922 (see Table 9-4 of [2]); 924 o TLV Offset MUST be set to 0 (see section 4.4): 926 o End TLV MUST be inserted after the TLV Offset field (see section 927 4.4). 929 The DEFAULT periodicity for MT-LCK is once per second. 931 When a MEP receives an LCK packet with the correct MEL value, it 932 detects the dLCK defect as described in clause 6.1 of [4]. 934 5.5. Test (TST) 936 5.6. Loss Measurement (LMM/LMR) 938 5.7. One-way delay measurement (1DM) 940 5.8. Two-way delay Measurement Message/Reply (DM) 942 5.9. Client Signal Fail (CSF) 944 6. Security Considerations 946 Spurious OAM messages, such as those defined in this document, 947 potentially could form a vector for a denial of service attack. 948 However, since these messages are carried in a control channel, one 949 would have to gain access to a node providing the service in order to 950 launch such an attack. Since transport networks are usually operated 951 as a walled garden, such threats are less likely. 953 7. IANA Considerations 955 IANA is requested to allocate a Channel Type value 0xXXXX to identify 956 an associated channel carrying all the OAM PDUs that are defined in 957 section 4 959 [Editor's note - The value 0x8902 has been proposed to keep the 960 channel type identical to the EtherType value used in Ethernet OAM] 962 8. Acknowledgments 964 The authors gratefully acknowledge the contributions of Malcolm 965 Betts, Zhenlong Cui, Feng Huang, Kam Lam, Jian Yang, Haiyan Zhang for 966 the definition of extensions to LBM/LBR required for supporting 967 on-demand connectivity verification OAM functions. 969 The authors would like to thank all the members of the CCSA for their 970 comments and support. 972 The authors would also like to thank Brian Branscomb, Feng Huang, Kam 973 Lam, Fang Li, Akira Sakurai and Yaakov Stein for their comments and 974 enhancements to the text. 976 This document was prepared using 2-Word-v2.0.template.dot. 978 9. References 980 9.1. Normative References 982 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 983 Levels", BCP 14, RFC 2119, March 1997. 985 [2] ITU-T Recommendation Y.1731 (02/08), "OAM functions and 986 mechanisms for Ethernet based networks", February 2008 988 [3] ITU-T Recommendation Y.1731 Amendment 1 (07/10), "OAM functions 989 and mechanisms for Ethernet based networks", July 2010 991 [4] ITU-T Recommendation G.8021 (12/07), "Characteristics of 992 Ethernet transport network equipment functional blocks", 993 December 2007 995 [5] Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal, R., 996 "MPLS Generic Associated Channel", RFC 5586, June 2009 998 [6] Busi, I., Allan, D., " Operations, Administration and 999 Maintenance Framework for MPLS-based Transport Networks", 1000 draft-ietf-mpls-tp-oam-framework-11 (work in progress), 1001 February 2011 1003 [7] Beller, D., Farrel, A., "An Inband Data Communication Network 1004 For the MPLS Transport Profile", RFC 5718, January 2010 1006 9.2. Informative References 1008 [8] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in 1009 MPLS Transport Networks", RFC 5860, May 2010 1011 [9] Li, F., Li, H., D'Alessandro, A., Jing, R., Wang, G., "Operator 1012 Considerations on MPLS-TP OAM Mechanisms", 1013 draft-fang-mpls-tp-oam-considerations-02 (work in progress), 1014 July 2011 1016 [10] Nadeau, T., et al., "Pseudo Wire (PW) OAM Message Mapping", 1017 draft-ietf-pwe3-oam-msg-map-16 (work in progress), April 2011 1019 [11] Boutros, S., et al., "Operating MPLS Transport Profile LSP in 1020 Loopback Mode", draft-ietf-mpls-tp-li-lb-02 (work in progress), 1021 June 2011 1023 [12] Swallow, G., Bocci, M., " MPLS-TP Identifiers", draft-ietf- 1024 mpls-tp-identifiers-02 (work in progress), July 2010 1026 [13] ITU-T Recommendation M.1400 (07/06), " Designations for 1027 interconnections among operators' networks", July 2006 1029 [14] IEEE Standard 802.1ag-2007, "IEEE Standard for Local and 1030 Metropolitan Area Networks: Connectivity Fault Management", 1031 September 2007 1033 Author's Addresses 1035 Italo Busi (Editor) 1036 Alcatel-Lucent 1038 Email: Italo.Busi@alcatel-lucent.com 1040 Huub van Helvoort (Editor) 1041 Huawei Technologies 1043 Email: hhelvoort@huawei.com 1045 Jia He (Editor) 1046 Huawei Technologies 1048 Email: hejia@huawei.com 1050 Contributing Authors' Addresses 1052 Christian Addeo 1053 Alcatel-Lucent 1055 Email: Christian.Addeo@alcatel-lucent.com 1057 Alessandro D'Alessandro 1058 Telecom Italia 1060 Email: alessandro.dalessandro@telecomitalia.it 1061 Simon Delord 1062 Telstra 1064 Email: simon.a.delord@team.telstra.com 1066 John Hoffmans 1067 KPN 1069 Email: john.hoffmans@kpn.com 1071 Ruiquan Jing 1072 China Telecom 1074 Email: jingrq@ctbri.com.cn 1076 Hing-Kam (Kam) Lam 1077 Alcatel-Lucent 1079 Email: Kam.Lam@alcatel-lucent.com 1081 Wang Lei 1082 China Mobile Communications Corporation 1084 Email: wangleiyj@chinamobile.com 1086 Han Li 1087 China Mobile Communications Corporation 1089 Email: lihan@chinamobile.com 1091 Vishwas Manral 1092 IPInfusion Inc 1094 Email: vishwas@ipinfusion.com 1095 Masahiko Mizutani 1096 Hitachi, Ltd. 1098 Email: masahiko.mizutani.ew@hitachi.com 1100 Manuel Paul 1101 Deutsche Telekom 1103 Email: Manuel.Paul@telekom.de 1105 Josef Roese 1106 Deutsche Telekom 1108 Email: Josef.Roese@t-systems.com 1110 Vincenzo Sestito 1111 Alcatel-Lucent 1113 Email: vincenzo.sestito@alcatel-lucent.com 1115 Yuji Tochio 1116 Fujitsu 1118 Email: tochio@jp.fujitsu.com 1120 Munefumi Tsurusawa 1121 KDDI R&D Labs 1123 Email: tsuru@kddilabs.jp 1125 Maarten Vissers 1126 Huawei Technologies 1128 Email: maarten.vissers@huawei.com 1129 Rolf Winter 1130 NEC 1132 Email: Rolf.Winter@nw.neclab.eu