idnits 2.17.1 draft-ietf-pwe3-mpls-eth-oam-iwk-05.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 2) being 64 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 12, 2012) is 4369 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 4447 (Obsoleted by RFC 8077) -- Possible downref: Non-RFC (?) normative reference: ref. 'MEF16' == Outdated reference: A later version (-16) exists of draft-ietf-pwe3-oam-msg-map-14 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PWE3 Working Group Dinesh Mohan (Ed.) 3 INTERNET-DRAFT Nortel Networks 4 Intended status: Standards Track 5 Expires: October 2012 Nabil Bitar (Ed.) 6 Verizon 8 Ali Sajassi (Ed.) 9 Cisco 11 April 12, 2012 13 MPLS and Ethernet OAM Interworking 14 draft-ietf-pwe3-mpls-eth-oam-iwk-05.txt 16 Abstract 18 This document specifies the mapping of defect states between 19 Ethernet Attachment Circuits (ACs) and associated Ethernet 20 Pseudowires (PWs) connected in accordance to the PWE3 21 architecture to realize an end-to-end emulated Ethernet service. 22 It standardizes the behavior of Provider Edges (PEs) with 23 respect to Ethernet PW and AC defects. 25 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on October 12, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction.............................................. 2 59 1.1. Reference Model and Defect Locations................. 4 60 1.2. Abstract Defect States............................... 5 61 2. Terminology............................................... 7 62 3. PW Status and Defects..................................... 8 63 3.1. Use of Native Service (NS) notification.............. 8 64 3.2. Use of PW Status notification for MPLS PSNs.......... 9 65 3.3. Use of BFD Diagnostic Codes.......................... 9 66 4. Ethernet AC Defect States Entry or Exit Criteria......... 10 67 4.1. AC Receive Defect State Entry or Exit............... 10 68 4.2. AC Transmit Defect State Entry or Exit.............. 11 69 5. Ethernet AC and PW Defect States Interworking............ 12 70 5.1. PW Receive Defect Entry Procedures.................. 12 71 5.2. PW Receive Defect Exit Procedures................... 13 72 5.3. PW Transmit Defect Entry Procedures................. 14 73 5.4. PW Transmit Defect Exit Procedures.................. 15 74 5.5. AC Receive Defect Entry Procedures.................. 15 75 5.6. AC Receive Defect Exit Procedures................... 16 76 5.7. AC Transmit Defect Entry Procedures................. 16 77 5.8. AC Transmit Defect Exit Procedures.................. 17 78 6. Acknowledgments.......................................... 17 79 7. Security Considerations.................................. 17 80 8. IANA Considerations...................................... 17 81 9. References............................................... 17 82 9.1. Normative References................................ 17 83 9.2. Informative References.............................. 18 84 10. Appendix A: Ethernet Native Service Management.......... 18 86 1. Introduction 88 This document specifies the mapping of defect states between 89 Ethernet Attachment Circuits (ACs) and associated Ethernet 90 Pseudowires (PWs) connected in accordance to the PWE3 91 architecture [RFC3985] to realize an end-to-end emulated 92 Ethernet service. This document augments the mapping of defect 93 states between a PW and associated AC of the end-to-end emulated 94 service in [RFC6310]. It covers the following Ethernet OAM 95 (Opertaions, Administration and Maintenance) mechanisms and 96 their interworking with PW OAM mechanisms: 98 - Ethernet Continuity Check (CC) [802.1ag][Y.1731] 99 - Ethernet Alarm Indication Signaling (AIS) and Remote Defect 100 Indication (RDI) [Y.1731] 101 - Ethernet Link OAM [802.3] 102 - Ethernet Local Management Interface {E-LMI} [MEF16] 104 Ethernet Link OAM [802.3] allows some Link defect states to be 105 detected and communicated across an Ethernet Link. When an 106 Ethernet AC is an Ethernet physical port, there may be some 107 application of Ethernet Link OAM [802.3]. Further, E-LMI [MEF16] 108 also allows for some Ethernet Virtual Circuit (EVC) defect 109 states to be communicated across an Ethernet UNI where Ethernet 110 UNI constitutes a single hop Ethernet Link (i.e. without any 111 802.1Q/.1ad compliant bridges in between). There may be some 112 application of E-LMI [MEF16] for failure notification across 113 single hop Ethernet AC in certain deployments that specifically 114 do not support [802.1ag] and/or [Y.1731]. [Y.1731] and [802.1ag] 115 based mechanisms are applicable in all types of Ethernet ACs. 116 Ethernet Link OAM [802.3] and E-LMI [MEF16] are optional and 117 their applicability is called out, where applicable. 119 Native Service (NS) OAM may be transported transparently over 120 the corresponding PW as user data. This is referred to as "the 121 single emulated OAM loop" mode per [RFC6310]. For Ethernet, as 122 an example, 802.1ag continuity check messages (CCMs) between two 123 Maintenance End Points (MEPs) can be transported transparently 124 as user data over the corresponding PW. At MEP locations, 125 service failure is detected when CCMs are not received over an 126 interval that is 3.5 times the local CCM transmission interval. 127 This is one of the failure conditions detected via CC. 129 MEP peers can exist between Customer Equipment (CE) pairs (MEPs 130 of a given Maintenance Entity Group (MEG) reside on the CEs), PE 131 pairs (the MEPs of a given MEG reside on the PEs), or between 132 the CE and PE (the MEPs of a given MEG reside on the PE 133 and CE), as long as the MEG domain nesting rules are maintained. 134 It should be noted that Ethernet allows the definition of up to 135 8 MEG domains, each compromising of MEPs (down MEPs and UP MEPs) 136 and Maintenance Intermediate Points (MIPs). These domains can be 137 nested or touching. MEPs and MIPs generate and process messages 138 in the same domain level. Thus, whenever in this document we 139 refer to messages sent by a MEP or a MIP to a peer MEP or MIP, 140 these MEPs and MIPs are in the same MEG domain level. 142 When interworking two networking domains, such as native 143 Ethernet and PWs to provide an end-to-end emulated service, 144 there is need to identify the failure domain and location even 145 when a PE supports both the NS OAM mechanisms and the PW OAM 146 mechanisms. In addition, scalability constraints may not allow 147 running proactive monitoring, such as CCMs with transmission 148 enabled, at a PE to detect the failure of an EVC across the PW 149 domain. Thus, network-driven alarms generated upon failure 150 detection in the NS or PW domain and their mappings to the other 151 domain are needed. There are also cases where a PE may not be 152 able to process NS OAM messages received on the PW even when 153 such messages are defined, as in Ethernet case, necessitating 154 the need for fault notification message mapping between the PW 155 domain and the NS domain. 157 For Multi-Segment PWs (MS-PWs) [RFC5659], Switching PEs (S-PEs) 158 are not aware of the NS. Thus, failure detection and 159 notification at S-PEs will be based on PW OAM mechanisms. 160 Mapping between PW OAM and NS OAM will be required at the 161 Terminating PEs (T-PEs) to propagate the failure notification 162 to the EVC endpoints. 164 Similar to [RFC6310], the intent of this document is to 165 standardize the behavior of PEs with respect to failures on 166 Ethernet ACs and PWs, so that there is no ambiguity about the 167 alarms generated and consequent actions undertaken by PEs in 168 response to specific failure conditions. 170 1.1. Reference Model and Defect Locations 172 Figure 1 is the same as used in [RFC6310] and is reproduced 173 in this document as a reference to highlight defect locations. 175 ACs PSN tunnel ACs 176 +----+ +----+ 177 +----+ | PE1|==================| PE2| +----+ 178 | |---(a)---(b)..(c)......PW1..(d)..(e)..(f)---(g)---| | 179 | CE1| (N1) | | | | (N2) |CE2 | 180 | |----------|............PW2.............|----------| | 181 +----+ | |==================| | +----+ 182 ^ +----+ +----+ ^ 183 | Provider Edge 1 Provider Edge 2 | 184 | | 185 |<-------------- Emulated Service ---------------->| 187 Customer Customer 188 Edge 1 Edge 2 190 Figure 1: PWE3 Network Defect Locations 192 1.2. Abstract Defect States 194 Abstract Defect States are also introduced in [RFC6310]. This 195 document uses the same conventions, as shown in Figure 2 from 196 [RFC6310]. It may be noted however that CE devices, shown in 197 Figure 2, do not necessarily have to be end customer devices. 198 These are essentially devices in client network segments that 199 are connecting to the Packet Switched Network (PSN) for the 200 emuulated services. 202 +-----+ 203 ----AC receive ----->| |-----PW transmit----> 204 CE1 | PE1 | 205 PE2/CE2 206 <---AC transmit------| |<----PW receive----- 207 +-----+ 208 (arrows indicate direction of user traffic impacted by a 209 defect) 211 Figure 2: Transmit and Receive Defect States and Notifications 213 PE1 may detect a receive defect in a local Ethernet AC via one 214 of the following mechanisms: 216 - An AIS alarm generated at an upstream node in the client 217 domain (CE1 in Figure 2) and received by a local MEP. 219 - Failure of the local link on which the AC is configured. 220 Link failure may be detected via physical failures (e.g., loss 221 of signal (LoS)), via Ethernet Link OAM [802.3] critical link 222 event notifications generated at an upstream node CE1 with 223 "Dying Gasp" or "Critical Event" indication, or via a client 224 Signal Fail message [Y.1731]. 226 - Failure to receive CCMs on the AC if a local MEP is 227 configured for the AC with CCM transmission enabled. 229 - A CCM from CE1 with interface status TLV indicating 230 interface down. Other CCM interface status TLVs will not be 231 used to indicate failure or recovery from failure. 233 It should be noted when a MEP at a PE or a CE receives a CCM 234 with the wrong MEG ID, MEP ID, or MEP level, the receving PE 235 or CE SHOULD treat such an event as an AC receive defect. In 236 any case, if such events persist for 3.5 times the MEP local 237 CCM transmission time, loss of continuity will be declared at 238 the receiving end. 240 An AC receive defect at PE1 impacts the ability of PE1 to 241 receive user traffic from the Client domain attached to PE1 242 via that AC. 244 PE1 may detect a receive defect in the PW via one of the 245 following mechanisms: 247 - A Forward Defect notification received from PE2. This defect 248 notification could point to problems associated with PE2's 249 inability to transmit traffic on the PW or PE2's inability to 250 receive traffic on its local AC from CE2. 252 - Unavailability of a PSN path in the PW domain to PE2. 254 A PW forward defect indication received on PE1 impacts the 255 ability of PE1 to receive traffic on the PW. 257 PE1 may be notified of an AC transmit defect via one of the 258 following mechanisms: 260 - CCMs with RDI (Remote Defect Indication) bit set. 261 - In case when the AC is associated with a physical port, 262 failure of the local link on which the AC is configured (e.g., 263 LOS or via Ethernet Link OAM [802.3] critical link event 264 notifications generated at an upstream node CE1 with "Link 265 Fault" indication). 267 An AC transmit defect impacts the ability of PE1 to send user 268 traffic on the local AC. 270 Similarly, PE1 may be notified of a PW transmit defect via 271 Reverse Defect indication from PE2, which could point to 272 problems associated with PE2's inability to receive traffic on 273 the PW or PE2's inability to transmit traffic on its local AC. 274 PW transmit defect impacts PE1 ability to send user traffic 275 toward CE2. 277 The procedures outlined in this document define the entry and 278 exit criteria for each of the four defect states with respect 279 to Ethernet ACs and corresponding PWs, and the consequent 280 actions that PE1 must support to properly interwork these 281 defect states and corresponding notification messages between 282 the PW domain and the Native Service (NS) domain. Receive 283 Defect state SHOULD have precedence over Transmit Defect state 284 in terms of handling, when both transmit and receive defect 285 states are identified simultaneously. 287 1.3. Specification of Requirements 289 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 290 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 291 document are to be interpreted as described in [RFC2119]. 293 2. Terminology 295 This document uses the following terms: 296 AIS Alarm Indication Signal 297 MD Level Maintenance Domain (MD) Level which identifies a value 298 in the range of 0-7 associated with Ethernet OAM frame. 299 MD Level identifies the span of the Ethernet OAM frame. 300 MEP Maintenance End Point is responsible for origination 301 and termination of OAM frames for a given MEG 303 MIP Maintenance Intermediate Point is located between peer 304 MEPs and can process OAM frames but does not initiate 305 or terminate them 306 RDI Remote Defect Indication 308 Further, this document also uses the terminology and conventions 309 used in [RFC6310]. 311 3. PW Status and Defects 313 [RFC6310] introduces a range of defects that impact PW 314 status. All these defect conditions are applicable for Ethernet 315 PWs. 317 Similarly, there are different mechanisms described in [RFC6310] 318 to detect PW defects, depending on the PSN type (e.g. MPLS PSN, 319 MPLS-IP PSN). Any of these mechanisms can be used when 320 monitoring the state of Ethernet PWs. [RFC6310] also discusses 321 the applicability of these failure detection mechanisms. 323 3.1. Use of Native Service (NS) notification 325 When a MEP is defined on the PE and associated with an Ethernet 326 PW,the PE can use native service OAM capabilities for failure 327 notifications. Options include: 329 - Sending of AIS frames from the local MEP to the MEP on the 330 remote PE when the MEP needs to convey PE receive defects, and 331 when CCM transmission is disabled. 332 - Suspension of CCM frames transmission from the local MEP to 333 the peer MEP on the remote PE to convey PE receive defects, 334 when CCM transmission is enabled. 335 - setting the RDI bit in transmitted CCM frames, when loss of 336 CCMs from the peer MEP is detected or the PE needs to convey PW 337 reverse defects. 339 These NS OAM notifications are inserted into the corresponding 340 PW. 342 Similarly, when the defect conditions are cleared, a PE can take 343 one of the following actions, depending on the mechanism that 344 was used for failure notification, to clear the defect sate on 345 the peer PE: 347 - Stopping AIS frame transmission from the local MEP to the MEP 348 on the remote PE to clear PW receive defects. 349 - Resuming CCM frames transmission from the local MEP to the 350 peer MEP on the remote PE to clear PW forward defects 351 notification, when CCM transmission is enabled. 352 - Clearing the RDI bit in transmitted CCM frames, to clear PW 353 transmit defects notification, when CCM transmission is enabled. 355 3.2. Use of PW Status notification for MPLS PSNs 357 When PWs are established using LDP, LDP status notification 358 signaling MUST be used as the default mechanism to signal AC and 359 PW status and defects [RFC4447]. That is known as the "coupled 360 loop mode". For PWs established over an MPLS or MPLS-IP PSN 361 using other mechanisms (e.g. static configuration), inband 362 signaling using VCCV-BFD [RFC5885] SHOULD be used to convey AC 363 and PW status and defects. 365 [RFC6310] identifies the following PW defect status codepoints: 366 - Forward defect: corresponds to a logical OR of local AC 367 (ingress) Receive fault, local PSN-facing PW (egress) transmit 368 fault, and PW not forwarding fault. 369 - Reverse defect: corresponds to a logical OR of local AC 370 (egress) transmit fault and local PW PSN-facing (ingress) 371 receive fault. 373 There are also scenarios where a PE carries out PW label 374 withdrawal instead of PW status notification. These include 375 administrative disablement of the PW or loss of Target LDP 376 session with the peer PE. 378 3.3. Use of BFD Diagnostic Codes 380 When using VCCV, the control channel (CC) type and Connectivity 381 Verification (CV) Type are agreed on between the peer PEs using 382 the OAM capability sub-TLV signaled as part of the interface 383 parameter TLV when using FEC 129 and the interface parameter 384 sub-TLV when using FEC 128. 386 As defined in [RFC6310], when CV type of 0x04 0r 0x1 is used to 387 indicate that BFD is used for PW fault detection only, PW defect 388 is detected via the BFD session while other defects, such as AC 389 defect or PE internal defects preventing it from forwarding 390 traffic, are communicated via LDP Status notification message in 391 MPLS and MPLS-IP PSNs or other mechanisms in L2TP-IP PSN. 393 Similarly, when CV type of 0x08 or 0x20 is used to indicate that 394 BFD is used for both PW fault detection and AC/PW Fault 395 Notification, all defects are signaled via BFD. 397 4. Ethernet AC Defect States Entry or Exit Criteria 399 4.1. AC Receive Defect State Entry or Exit 401 PE1 enters the AC Receive Defect state if any of the following 402 conditions is met: 404 - It detects or is notified of a physical layer fault on the 405 Ethernet interface. Ethernet link failure can be detected based 406 on loss of signal (LoS) or via Ethernet Link OAM [802.3] 407 critical link event notifications generated at an upstream node 408 CE1 with "Dying Gasp" or "Critical Event" indication. 410 - A MEP associated with the local AC receives an Ethernet AIS 411 frame. 413 - A MEP associated with the local AC does not receive CCM frames 414 from the peer MEP in the client domain (e.g. CE1) within an 415 interval equal to 3.5 times the CCM transmission period 416 configured for the MEP. This is the case when CCM transmission 417 is enabled. 419 - A CCM with interface status TLV indicating interface down. 420 Other CCM interface status TLVs will not be used to indicate 421 failure or recovery from failure. 423 PE1 exits the AC Receive Defect state if all of the conditions 424 that resulted in entering the defect state are cleared. This 425 includes all of the following conditions: 427 - Any physical layer fault on the Ethernet interface, if 428 detected or notified previously is renoved (e.g., loss of signal 429 (LoS) cleared, or Ethernet Link OAM [802.3] critical link event 430 notifications with "Dying Gasp" or "Critical Event" indication 431 cleared at an upstream node CE1). 433 - A MEP associated with the local AC does not receive any 434 Ethernet AIS frame within a period indicated by previously 435 received AIS, if AIS resulted in entering the defect 436 state. 438 - A MEP associated with the local AC and configured with CCM 439 enabled receives a configured number (e.g., 3 or more) of 440 consecutive CCM frames from the peer MEP on CE1 within an 441 interval equal to a multiple (3.5) of the CCM transmission 442 period configured for the MEP. 444 - CCM indicates interface status up. 446 4.2. AC Transmit Defect State Entry or Exit 448 PE1 enters the AC Transmit Defect state if any of the following 449 conditions is met: 451 - It detects or is notified of a physical layer fault on the 452 Ethernet interface (e.g., via loss of signal (LoS) or Ethernet 453 Link OAM [802.3] critical link event notifications generated at 454 an upstream node CE1 with "Link Fault" indication). 456 - A MEP configured with CCM transmission enabled and associated 457 with the local AC receives a CCM frame, with its RDI bit set, 458 from the peer MEP in the client domain (e.g., CE1). 460 PE1 exits the AC Transmit Defect state if all of the conditions 461 that resulted in entering the defect state are cleared. This 462 includes all of the following conditions: 464 - Any physical layer fault on the Ethernet interface, if 465 detected or notified previously is removed (e.g., LOS cleared, 466 Ethernet Link OAM [802.3] critical link event notifications 467 with "Link Fault" indication cleared at an upstream node CE1). 469 - A MEP configured with CCM transmission enabled and associated 470 with the local AC does not receive a CCM frame with RDI bit set, 471 having received a previous CCM frame with RDI bit set from the 472 peer MEP in the client domain (e.g. CE1). 474 5. Ethernet AC and PW Defect States Interworking 476 5.1. PW Receive Defect Entry Procedures 478 When the PW status on PE1 transitions from working to PW Receive 479 Defect state, PE1's ability to receive user traffic from CE2 is 480 impacted. As a result, PE1 needs to notify CE1 about this 481 problem. 483 Upon entry to the PW Receive Defect state, the following must be 484 done: 486 - If PE1 is configured with a down MEP associated with the local 487 AC and CCM transmission is not enabled, the MEP associated with 488 the AC must transmit AIS frames periodically to the peer MEP in 489 the client domain (e.g., on CE1) based on configured AIS 490 transmission period. 492 - If PE1 is configured with a down MEP associated with the local 493 AC and CCM transmission is enabled, and the MEP associated with 494 the AC is configured to support Interface Status TLV in CCM 495 messages, the MEP associated with the AC must transmit CCM 496 frames with Interface Status TLV as being down to the peer MEP 497 in the client domain (e.g., on CE1). 499 - If PE1 is configured with a down MEP associated with the local 500 AC and CCM transmission is enabled, and the MEP 501 associated with the AC is configured to not support Interface 502 Status TLV in CCM messages, the MEP associated with the AC must 503 stop transmitting CCM frames to the peer MEP in the client 504 domain (e.g., on CE1). 506 - If PE1 is configured to run E-LMI [MEF16] with CE1 and if 507 E-LMI is used for failure notification, PE1 must transmit E-LMI 508 asynchronous STATUS message with report type Single EVC 509 Asynchronous Status indicating that PW is Not Active. 511 Further, when PE1 enters the Receive Defect state, it must 512 assume that PE2 has no knowledge of the defect and must send 513 reverse defect failure notification to PE2. For MPLS PSN or 514 MPLS-IP PSN, this is done via either a PW Status notification 515 message indicating a reverse defect; or via VCCV-BFD diagnostic 516 code of reverse defect if VCCV CV type of 0x08 had been 517 negotiated. When Native Service OAM mechanism is supported on 518 PE1, it can also use the NS OAM notification as specified in 519 Section 3.1. 521 If PW receive defect is entered as a result of a forward defect 522 notification from PE2 or via loss of control adjacency, no 523 additional action is needed since PE2 is expected to be aware of 524 the defect. 526 5.2. PW Receive Defect Exit Procedures 528 When the PW status transitions from PW Receive Defect state to 529 working, PE1's ability to receive user traffic from CE2 is 530 restored. As a result, PE1 needs to cease defect notification to 531 CE1 by performing the following: 533 - If PE1 is configured with a down MEP associated with the local 534 AC and CCM transmission is not enabled, the MEP associated with 535 the AC must stop transmitting AIS frames towards the peer MEP in 536 the client domain (e.g., on CE1). 538 - If PE1 is configured with a down MEP associated with the local 539 AC and CCM transmission is enabled, and the MEP associated with 540 the AC is configured to support Interface Status TLV in CCM 541 messages, the MEP associated with the AC must transmit CCM 542 frames with Interface Status TLV as being Up to the peer MEP in 543 the client domain (e.g., on CE1). 545 - If PE1 is configured with a down MEP associated with the local 546 AC and CCM transmission is enabled, and the MEP associated with 547 the AC is configured to not support Interface Status TLV in CCM 548 messages, the MEP associated with the AC must resume 549 transmitting CCM frames to the peer MEP in the client domain 550 (e.g., on CE1). 552 - If PE1 is configured to run E-LMI [MEF16] with CE1 and E-LMI 553 is used for fault notification, PE1 must transmit E-LMI 554 asynchronous STATUS message with report type Single EVC 555 Asynchronous Status indicating that PW is Active. 557 Further, if the PW receive defect was explicitly detected by 558 PE1, it must now notify PE2 about clearing of Receive Defect 559 state by clearing reverse defect notification. For PWs over 560 MPLS PSN or MPLS-IP PSN, this is either done via PW Status 561 message indicating working; or via VCCV-BFD diagnostic code if 562 VCCV CV type of 0x08/0x20 had been negotiated. When Native 563 Service OAM mechanism is supported on PE, it can also clear the 564 NS OAM notification specified in Section 3.1. 566 If PW receive defect was established via notification from PE2 567 or via loss of control adjacency, no additional action is 568 needed, since PE2 is expected to be aware of the defect 569 clearing. 571 5.3. PW Transmit Defect Entry Procedures 573 When the PW status transitions from working to PW Transmit 574 Defect state, PE1's ability to transmit user traffic to CE2 is 575 impacted. As a result, PE1 needs to notify CE1 about this 576 problem which has been detected by PE1. 578 Upon entry to the PW Transmit Defect state, the following must 579 be done: 581 - If PE1 is configured with a down MEP associated with the local 582 AC and CCM transmission is enabled, the MEP associated with the 583 AC MUST set the RDI bit in transmitted CCM frames or send status 584 TLV with interface down to the peer MEP in the client domain 585 (e.g. on CE1). 587 - If PE1 is configured to run E-LMI [MEF16] with CE1 and E-LMI 588 is used for fault notification, PE1 must transmit E-LMI 589 asynchronous STATUS message with report type Single EVC 590 Asynchronous Status indicating that PW is Not Active. 592 5.4. PW Transmit Defect Exit Procedures 594 When the PW status transitions from PW Transmit Defect state to 595 working, PE1's ability to transmit user traffic to CE2 is 596 restored. As a result, PE1 needs to cease defect notifications 597 to CE1 and perform the following: 599 - If PE1 is configured with a down MEP associated with the local 600 AC and CCM transmission is enabled, the MEP associated with the 601 AC must clear the RDI bit in the transmitted CCM frames to the 602 peer MEP (e.g., on CE1). 604 - If PE1 is configured to run E-LMI [MEF16] with CE1, PE1 must 605 transmit E-LMI asynchronous STATUS message with report type 606 Single EVC Asynchronous Status indicating that PW is Active. 608 5.5. AC Receive Defect Entry Procedures 610 When AC status transitions from working to AC Receive Defect 611 state, PE1's ability to receive user traffic from CE1 is 612 impacted. As a result, PE1 needs to notify PE2 and CE1 about 613 this problem. 615 If the AC receive defect is detected by PE1, it must notify PE2 616 in the form of a forward defect notification. 618 When NS OAM is not supported on PE1, and for PW over MPLS PSN 619 or MPLS-IP PSN, forward defect notification is done via either 620 PW Status message indicating a forward defect or via VCCV-BFD 621 diagnostic code of forward defect if VCCV CV type of 0x08/0x20 622 had been negotiated. 624 When Native Service OAM mechanism is supported on PE1, it can 625 also use the NS OAM notification as specified in Section 3.1. 627 In addition to above actions, PE1 must perform the following: 629 - If PE1 is configured with a down MEP associated with the local 630 AC and CCM transmission is enabled, the MEP associated with the 631 AC must set the RDI bit in transmitted CCM frames. 633 5.6. AC Receive Defect Exit Procedures 635 When AC status transitions from AC Receive Defect to working, 636 PE1's ability to receive user traffic from CE1 is restored. As 637 a result, PE1 needs to cease defect notifications to PE2 and CE1 638 and perform the following: 640 - When NS OAM is not supported on PE1 and for PW over MPLS PSN 641 or MPLS-IP PSN, forward defect notification is cleared via PW 642 Status message indicating a working state; or via VCCV-BFD 643 diagnostic code if VCCV CV type of 0x08 or 0x20 had been 644 negotiated. 646 - When Native Service OAM mechanism is supported on PE1, PE1 647 clears the NS OAM notification as specified in Section 3.1. 649 - If PE1 is configured with a down MEP associated with the local 650 AC and CCM transmission is enabled, the MEP associated with the 651 AC must clear the RDI bit in transmitted CCM frames to the 652 peer MEP in the client domain (e.g., on CE1). 654 5.7. AC Transmit Defect Entry Procedures 656 When AC status transitions from working to AC Transmit Defect, 657 PE1's ability to transmit user traffic to CE1 is impacted. As a 658 result, PE1 needs to notify PE2 about this problem. 660 If the AC transmit defect is detected by PE1, it must notify PE2 661 in the form of a reverse defect notification. 663 When NS OAM is not supported on PE1, in PW over MPLS PSN or 664 MPLS-IP PSN, reverse defect notification is either done via PW 665 Status message indicating a reverse defect; or via VCCV-BFD 666 diagnostic code of reverse defect if VCCV CV type of 0x08 or 667 0x20 had been negotiated. 669 When Native Service OAM mechanism is supported on PE1, it can 670 also use the NS OAM notification as specified in Section 3.1. 672 5.8. AC Transmit Defect Exit Procedures 674 When AC status transitions from AC Transmit defect to working, 675 PE1's ability to transmit user traffic to CE1 is restored. As a 676 result, PE1 must clear reverse defect notification to PE2. 678 When NS OAM is not supported on PE1 and for PW over MPLS PSN or 679 MPLS-IP PSN, reverse defect notification is cleared via either a 680 PW Status message indicating a working state or via VCCV-BFD 681 diagnostic code if VCCV CV type of 0x08 had been negotiated. 683 When Native Service OAM mechanism is supported on PE1, PE1 can 684 clear NS OAM notification as specified in Section 3.1. 686 6. Acknowledgments 688 The authors are thankful to Samer Salam for his valuable 689 comments. 691 7. Security Considerations 693 This document does not impose any security concerns since it 694 makes use of existing OAM mechanisms and mapping of these 695 messages does not change inherent security features. 697 8. IANA Considerations 699 This document has no actions for IANA. 701 9. References 703 9.1. Normative References 705 [Y.1731] "OAM Functions and mechanisms for Ethernet based 706 networks", ITU-T Y.1731, May 2006 708 [802.1ag] "Connectivity Fault Management", IEEE 802.1ag/D8.1, 709 July 2007 711 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 712 Requirement Levels", BCP 14, RFC 2119, March 1997. 714 [RFC4447] "Pseudowire Setup and Maintenance using LDP", RFC4447, 715 April 2006 717 [RFC5885] "Bidirectional Forwarding Detection (BFD) for the 718 Pseudowire Virtual Circuit Connectivity Verification (VCCV)", 719 RFC5885, June 2010 721 [802.3] "CDMA/CD access method and physical layer 722 specifications", Clause 57 for Operations, Administration and 723 Maintenance, 2005 725 [MEF16] "Ethernet Local Management Interface", MEF16, January 726 2006 728 9.2. Informative References 730 [RFC3985] "Pseudo Wire Emulation Edge-to-Edge (PWE3) 731 Architecture", RFC 3985, April 2005 733 [RFC6310] "Pseudo Wire (PW) OAM Message Mapping", draft-ietf- 734 pwe3-oam-msg-map-14.txt, Work in progress, October 2010 736 [RFC5659] "An Architecture for Multi-Segment Pseudo Wire 737 Emulation Edge-to-Edge", RFC5659, October 2009 739 10. Appendix A: Ethernet Native Service Management 741 Ethernet OAM mechanisms are broadly classified into two 742 categories: Fault Management (FM) and Performance Monitoring 743 (PM). ITU-T Y.1731 provides coverage for both FM and PM while 744 IEEE 802.1ag provides coverage for a sub-set of FM functions. 746 Ethernet OAM also introduces the concept of Maintenance Entity 747 (ME) which is used to identify the entity that needs to be 748 managed. An ME is inherently a point-to-point association. 749 However, in case of a multipoint association, Maintenance Entity 750 Group (MEG) consisting of different MEs is used. IEEE 802.1 uses 751 the concept of Maintenance Association (MA) which is used to 752 identify both point-to-point and multipoint associations. Each 753 MA consists of Maintenance End Points (MEPs) which are 754 responsible for originating OAM frames. In between the MEPs, 755 there can also be Maintenance Intermediate Points (MIPs) which 756 do not originate OAM frames however do respond to OAM frames 757 from MEPs. 759 Ethernet OAM allows for hierarchical maintenance entities to 760 allow for simultaneous end-to-end and segment monitoring. This 761 is achieved by having a provision of up to 8 Maintenance Domain 762 Levels (MD Levels) where each MEP or MIP is associated with a 763 specific MD Level. 765 It is important to note that the common set of FM mechanisms 766 between IEEE 802.1ag and ITU-T Y.1731 are completely compatible. 768 The common FM mechanisms include: 770 1) Continuity Check Messages (CCM) 771 2) Loopback Message (LBM) and Loopback Reply (LBR) 772 3) Linktrace Message (LTM) and Linktrace Reply (LTR) 774 CCM messages are used for fault detection including misconnections 775 and mis-configurations. Typically CCM messages are sent as 776 multicast frames or Unicast frames and also allow RDI 777 notifications. LBM/LBR are used to perform fault verification, 778 while also allow for MTU verification and CIR/EIR measurements. 779 LTM/LTR can be used for discovering the path traversed between a 780 MEP and another target MIP/MEP in the same MA. LTM/LTR also allow 781 for fault localization. 783 In addition, ITU-T Y.1731 also specifies the following FM 784 functions: 785 4) Alarm Indication Signal (AIS) 787 AIS allows for fault notification to downstream and upstream nodes 789 Further, ITU-T Y.1731 also specifies the following PM functions: 791 5) Loss Measurement Message (LMM) and Reply (LMR) 792 6) Delay Measurement Message (DMR) and Reply (DMR) 793 7) 1-way Delay Message (1DM) 795 While LMM/LMR is used to measure Frame Loss Ratio (FLR), DMM/DMR is 796 used to measure single-ended (aka two-way) Frame Delay (FD) and 797 Frame Delay Variation (FDV, also known as Jitter). 1DM can be used 798 for dual-ended (aka one-way) FD and FDV measurements. 800 Authors' Addresses: 802 Dinesh Mohan 803 Nortel 804 3500 Carling Ave 805 Ottawa, ON K2H8E9 806 Email: dinmohan@hotmail.com 808 Nabil Bitar 809 Verizon 810 60 Sylvan Road 811 Waltham, MA 02145 812 Email: nabil.n.bitar@verizon.com 814 Simon Delord 815 Telstra 816 242 Exhibition St 817 Melbourne VIC 3000, Australia 818 E-mail: simon.a.delord@team.telstra.com 820 Philippe Niger 821 France Telecom 822 2 av. Pierre Marzin 823 22300 LANNION, France 824 E-mail: philippe.niger@francetelecom.com 826 Ali Sajassi 827 Cisco 828 170 West Tasman Drive 829 San Jose, CA 95134, US 830 Email: sajassi@cisco.com 832 Ray Qiu 833 330 Central Expressway 834 Santa Clara, CA 95050, US 835 Email: ray@huawei.com