idnits 2.17.1 draft-ietf-pwe3-mpls-eth-oam-iwk-06.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 22 longer pages, the longest (page 1) being 61 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 (July 16, 2012) is 4299 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' Summary: 1 error (**), 0 flaws (~~), 2 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: January 2013 Nabil Bitar (Ed.) 6 Verizon 8 Ali Sajassi (Ed.) 9 Cisco 11 July 16, 2012 13 MPLS and Ethernet OAM Interworking 14 draft-ietf-pwe3-mpls-eth-oam-iwk-06.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 architecture 21 to realize an end-to-end emulated Ethernet service. It standardizes 22 the behavior of Provider Edges (PEs) with respect to Ethernet PW 23 and AC defects. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet 31 Engineering Task Force (IETF). Note that other groups may also 32 distribute working documents as Internet-Drafts. The list of 33 current Internet-Drafts is at 34 http://datatracker.ietf.org/drafts/current/. 36 Mohan, et al. Expires January 15, 2013 37 Internet-Drafts are draft documents valid for a maximum of six 38 months and may be updated, replaced, or obsoleted by other 39 documents at any time. It is inappropriate to use Internet- 40 Drafts as reference material or to cite them other than as "work 41 in progress." 43 This Internet-Draft will expire on January 15,2013. 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 55 respect to this document. Code Components extracted from this 56 document must include Simplified BSD License text as described 57 in Section 4.e of the Trust Legal Provisions and are provided 58 without warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Specification of Requirements ...................... 3 63 2. Introduction ....................................... 3 64 2.1. Reference Model and Defect Location............... 5 65 2.2. Abstract Defect States............................ 5 66 3. Terminology ........................................ 8 67 4. PW Status and Defects .............................. 9 68 4.1. Use of Native Service (NS) Notification........... 9 69 4.2. Use of PW Status Notification for MPLS PSNs...... 10 70 4.3. Use of BFD Diagnostic Codes ..................... 11 71 5. Ethernet AC Defect States Entry or Exit Criteria... 11 72 5.1. AC Receive Defect State Entry or Exit............ 11 73 5.2. AC Transmit Defect State Entry or Exit........... 13 74 6. Ethernet AC and PW Defect States Interworking...... 13 75 6.1. PW Receive Defect Entry Procedures............... 13 76 6.2. PW Receive Defect Exit Procedures................ 15 77 6.3. PW Transmit Defect Entry Procedures.............. 16 78 6.4. PW Transmit Defect Exit Procedures .............. 17 79 6.5. AC Receive Defect Entry Procedures............... 17 80 6.6. AC Receive Defect Exit Procedures................ 18 81 6.7. AC Transmit Defect Entry Procedures.............. 19 82 6.8. AC Transmit Defect Exit Procedures............... 19 83 7. Security Considerations............................ 20 84 8. IANA Considerations................................ 20 85 9. Acknowledgments.................................... 20 86 10. References........................................ 21 87 10.1. Normative References............................ 21 88 10.2. Informative References.......................... 22 89 11. Appendix A: Ethernet Native Service Management.... 22 91 1. Specification of Requirements 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 95 this document are to be interpreted as described in [RFC2119]. 97 2. Introduction 99 This document specifies the mapping of defect states between 100 Ethernet Attachment Circuits (ACs) and associated Ethernet 101 Pseudowires (PWs) connected in accordance to the PWE3 architecture 102 [RFC3985] to realize an end-to-end emulated Ethernet service. This 103 document augments the mapping of defect states between a PW and 104 associated AC of the end-to-end emulated service in [RFC6310]. It 105 covers the following Ethernet OAM (Opertaions, Administration and 106 Maintenance) mechanisms and their interworking with PW OAM 107 mechanisms: 109 - Ethernet Continuity Check (CC) [802.1ag][Y.1731] 110 - Ethernet Alarm Indication Signaling (AIS) and Remote Defect 111 Indication (RDI) [Y.1731] 112 - Ethernet Link OAM [802.3] 113 - Ethernet Local Management Interface {E-LMI} [MEF16] 115 Ethernet Link OAM [802.3] allows some Link defect states to be 116 detected and communicated across an Ethernet Link. When an Ethernet 117 AC is an Ethernet physical port, there may be some application of 118 Ethernet Link OAM [802.3]. Further, E-LMI [MEF16] also allows for 119 some Ethernet Virtual Circuit (EVC) defect states to be 120 communicated across an Ethernet UNI where Ethernet UNI constitutes 121 a single hop Ethernet Link (i.e. without any 802.1Q/.1ad compliant 122 bridges in between). There may be some application of E-LMI [MEF16] 123 for failure notification across single hop Ethernet AC in certain 124 deployments that specifically do not support [802.1ag] and/or 125 [Y.1731]. [Y.1731] and [802.1ag] based mechanisms are applicable in 126 all types of Ethernet ACs. Ethernet Link OAM [802.3] and E-LMI 127 [MEF16] are optional and their applicability is called out, where 128 applicable. 130 Native Service (NS) OAM may be transported transparently over the 131 corresponding PW as user data. This is referred to as "the single 132 emulated OAM loop" mode per [RFC6310]. For Ethernet, as an example, 133 802.1ag continuity check messages (CCMs) between two Maintenance 134 End Points (MEPs) can be transported transparently as user data 135 over the corresponding PW. At MEP locations, service failure is 136 detected when CCMs are not received over an interval that is 3.5 137 times the local CCM transmission interval. This is one of the 138 failure conditions detected via CC. MEP peers can exist between 139 Customer Equipment (CE) pairs (MEPs of a given Maintenance Entity 140 Group (MEG) reside on the CEs), PE pairs (the MEPs of a given MEG 141 reside on the PEs), or between the CE and PE (the MEPs of a given 142 MEG reside on the PE and CE), as long as the MEG domain nesting 143 rules are maintained. It should be noted that Ethernet allows the 144 definition of up to 8 MEG domains, each compromising of MEPs (down 145 MEPs and UP MEPs) and Maintenance Intermediate Points (MIPs). These 146 domains can be nested or touching. MEPs and MIPs generate and 147 process messages in the same domain level. Thus, whenever in this 148 document we refer to messages sent by a MEP or a MIP to a peer MEP 149 or MIP, these MEPs and MIPs are in the same MEG domain level. 151 When interworking two networking domains, such as native Ethernet 152 and PWs to provide an end-to-end emulated service, there is need to 153 identify the failure domain and location even when a PE supports 154 both the NS OAM mechanisms and the PW OAM mechanisms. In addition, 155 scalability constraints may not allow running proactive monitoring, 156 such as CCMs with transmission enabled, at a PE to detect the 157 failure of an EVC across the PW domain. Thus, network-driven alarms 158 generated upon failure detection in the NS or PW domain and their 159 mappings to the other domain are needed. There are also cases where 160 a PE may not be able to process NS OAM messages received on the PW 161 even when such messages are defined, as in Ethernet case, 162 necessitating the need for fault notification message mapping 163 between the PW domain and the NS domain. 165 For Multi-Segment PWs (MS-PWs) [RFC5659], Switching PEs (S-PEs) are 166 not aware of the NS. Thus, failure detection and notification at S- 167 PEs will be based on PW OAM mechanisms. Mapping between PW OAM and 168 NS OAM will be required at the Terminating PEs (T-PEs) to propagate 169 the failure notification to the EVC endpoints. 171 Similar to [RFC6310], the intent of this document is to standardize 172 the behavior of PEs with respect to failures on Ethernet ACs and 173 PWs, so that there is no ambiguity about the alarms generated and 174 consequent actions undertaken by PEs in response to specific 175 failure conditions. 177 2.1. Reference Model and Defect Locations 179 Figure 1 is the same as used in [RFC6310] and is reproduced in this 180 document as a reference to highlight defect locations. 182 ACs PSN tunnel ACs 183 +----+ +----+ 184 +----+ | PE1|==================| PE2| +----+ 185 | |---(a)---(b)..(c)......PW1..(d)..(e)..(f)---(g)---| | 186 | CE1| (N1) | | | | (N2) |CE2 | 187 | |----------|............PW2.............|----------| | 188 +----+ | |==================| | +----+ 189 ^ +----+ +----+ ^ 190 | Provider Edge 1 Provider Edge 2 | 191 | | 192 |<-------------- Emulated Service ---------------->| 194 Customer Customer 195 Edge 1 Edge 2 197 Figure 1: PWE3 Network Defect Locations 199 2.2. Abstract Defect States 201 Abstract Defect States are also introduced in [RFC6310]. This 202 document uses the same conventions, as shown in Figure 2, from 203 [RFC6310]. It may be noted however that CE devices, shown in Figure 204 2, do not necessarily have to be end customer devices. These are 205 essentially devices in client network segments that are connecting 206 to the Packet Switched Network (PSN) for the emulated services. 208 +-----+ 209 ----AC receive ----->| |-----PW transmit----> 210 CE1 | PE1 | PE2/CE2 211 <---AC transmit------| |<----PW receive----- 212 +-----+ 214 (arrows indicate direction of user traffic impacted by a defect) 216 Figure 2: Transmit and Receive Defect States and Notifications 218 PE1 may detect a receive defect in a local Ethernet AC via one of 219 the following mechanisms: 221 - An AIS alarm generated at an upstream node in the client 222 domain (CE1 in Figure 2) and received by a local MEP. 224 - Failure of the local link on which the AC is configured. Link 225 failure may be detected via physical failures (e.g., loss of signal 226 (LoS)), via Ethernet Link OAM [802.3] critical link event 227 notifications generated at an upstream node CE1 with "Dying Gasp" 228 or "Critical Event" indication, or via a client Signal Fail message 229 [Y.1731]. 231 - Failure to receive CCMs on the AC if a local MEP is configured 232 for the AC with CCM transmission enabled. 234 - A CCM from CE1 with interface status TLV indicating interface 235 down. Other CCM interface status TLVs will not be used to indicate 236 failure or recovery from failure. 238 It should be noted when a MEP at a PE or a CE receives a CCM with 239 the wrong MEG ID, MEP ID, or MEP level, the receiving PE or CE 240 SHOULD treat such an event as an AC receive defect. In any case, if 241 such events persist for 3.5 times the MEP local CCM transmission 242 time, loss of continuity will be declared at the receiving end. 244 An AC receive defect at PE1 impacts the ability of PE1 to receive 245 user traffic from the Client domain attached to PE1 via that AC. 247 PE1 may detect a receive defect in the PW via one of the following 248 mechanisms: 250 - A Forward Defect notification received from PE2. This defect 251 notification could point to problems associated with PE2's 252 inability to transmit traffic on the PW or PE2's inability to 253 receive traffic on its local AC from CE2. 255 - Unavailability of a PSN path in the PW domain to PE2. 257 A PW forward defect indication received on PE1 impacts the ability 258 of PE1 to receive traffic on the PW. 260 PE1 may be notified of an AC transmit defect via one of the 261 following mechanisms: 263 - CCMs with RDI (Remote Defect Indication) bit set. 265 - In case when the AC is associated with a physical port, 266 failure of the local link on which the AC is configured (e.g., LOS 267 or via Ethernet Link OAM [802.3] critical link event notifications 268 generated at an upstream node CE1 with "Link Fault" indication). 270 An AC transmit defect impacts the ability of PE1 to send user 271 traffic on the local AC. 273 Similarly, PE1 may be notified of a PW transmit defect via Reverse 274 Defect indication from PE2, which could point to problems 275 associated with PE2's inability to receive traffic on the PW or 276 PE2's inability to transmit traffic on its local AC. 278 PW transmit defect impacts PE1 ability to send user traffic toward 279 CE2. The procedures outlined in this document define the entry and 280 exit criteria for each of the four defect states with respect to 281 Ethernet ACs and corresponding PWs, and the consequent actions that 282 PE1 must support to properly interwork these defect states and 283 corresponding notification messages between the PW domain and the 284 Native Service (NS) domain. Receive Defect state SHOULD have 285 precedence over Transmit Defect state in terms of handling, when 286 both transmit and receive defect states are identified 287 simultaneously. 289 3. Terminology 291 This document uses the following terms: 293 - AIS: Alarm Indication Signal 295 - MD Level: Maintenance Domain (MD) Level which identifies a 296 value in the range of 0-7 associated with Ethernet OAM frame. 297 MD Level identifies the span of the Ethernet OAM frame. 299 - MEP: Maintenance End Point is responsible for 300 origination and termination of OAM frames for a given MEG. 302 - MIP: Maintenance Intermediate Point is located between 303 peer MEPs and can process OAM frames but does not initiate or 304 terminate them. 306 - RDI: Remote Defect Indication. 308 Further, this document also uses the terminology and conventions 309 used in [RFC6310]. 311 4. PW Status and Defects 313 [RFC6310] introduces a range of defects that impact PW status. All 314 these defect conditions are applicable for Ethernet PWs. 316 Similarly, there are different mechanisms described in [RFC6310] to 317 detect PW defects, depending on the PSN type (e.g. MPLS PSN, MPLS- 318 IP PSN). Any of these mechanisms can be used when monitoring the 319 state of Ethernet PWs. [RFC6310] also discusses the applicability 320 of these failure detection mechanisms. 322 4.1. Use of Native Service (NS) Notification 324 When a MEP is defined on the PE and associated with an Ethernet 325 PW, the PE can use native service OAM capabilities for failure 326 notifications. Options include: 328 - Sending of AIS frames from the local MEP to the MEP on the 329 remote PE when the MEP needs to convey PE receive defects, and when 330 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, when 334 CCM transmission is enabled. 336 - Setting the RDI bit in transmitted CCM frames, when loss of 337 CCMs from the peer MEP is detected or the PE needs to convey PW 338 reverse defects. 340 These NS OAM notifications are inserted into the corresponding PW. 342 Similarly, when the defect conditions are cleared, a PE can take 343 one of the following actions, depending on the mechanism that was 344 used for failure notification, to clear the defect sate on the peer 345 PE: 347 - Stopping AIS frame transmission from the local MEP to the 348 MEP on the remote PE to clear PW receive defects. 350 - Resuming CCM frames transmission from the local MEP to the 351 peer MEP on the remote PE to clear PW forward defects notification, 352 when CCM transmission is enabled. 354 - Clearing the RDI bit in transmitted CCM frames, to clear PW 355 transmit defects notification, when CCM transmission is enabled. 357 4.2. Use of PW Status notification for MPLS PSNs 359 When PWs are established using LDP, LDP status notification 360 signaling MUST be used as the default mechanism to signal AC and PW 361 status and defects [RFC4447]. That is known as the "coupled loop 362 mode". For PWs established over an MPLS or MPLS-IP PSN using other 363 mechanisms (e.g. static configuration), inband signaling using 364 VCCV-BFD [RFC5885] SHOULD be used to convey AC and PW status and 365 defects. 367 [RFC6310] identifies the following PW defect status codepoints: 369 - Forward defect: corresponds to a logical OR of local AC 370 (ingress) Receive fault, local PSN-facing PW (egress) transmit 371 fault, and PW not forwarding fault. 373 - Reverse defect: corresponds to a logical OR of local AC 374 (egress) transmit fault and local PW PSN-facing (ingress) 375 receive fault. 377 There are also scenarios where a PE carries out PW label withdrawal 378 instead of PW status notification. These include administrative 379 disablement of the PW or loss of Target LDP session with the peer 380 PE. 382 4.3. Use of BFD Diagnostic Codes 384 When using VCCV, the control channel (CC) type and Connectivity 385 Verification (CV) Type are agreed on between the peer PEs using the 386 OAM capability sub-TLV signaled as part of the interface parameter 387 TLV when using FEC 129 and the interface parameter sub-TLV when 388 using FEC 128. 390 As defined in [RFC6310], when CV type of 0x04 0r 0x10 is used to 391 indicate that BFD is used for PW fault detection only, PW defect is 392 detected via the BFD session while other defects, such as AC defect 393 or PE internal defects preventing it from forwarding traffic, are 394 communicated via LDP Status notification message in MPLS and MPLS- 395 IP PSNs or other mechanisms in L2TP-IP PSN. 397 Similarly, when CV type of 0x08 or 0x20 is used to indicate that 398 BFD is used for both PW fault detection and AC/PW Fault 399 Notification, all defects are signaled via BFD. 401 5. Ethernet AC Defect States Entry or Exit Criteria 403 5.1. AC Receive Defect State Entry or Exit 405 PE1 enters the AC Receive Defect state if any of the following 406 conditions is met: 408 - It detects or is notified of a physical layer fault on the 409 Ethernet interface. Ethernet link failure can be detected based on 410 loss of signal (LoS) or via Ethernet Link OAM [802.3] critical link 411 event notifications generated at an upstream node CE1 with "Dying 412 Gasp" or "Critical Event" indication. 414 - A MEP associated with the local AC receives an Ethernet AIS 415 frame. 417 - A MEP associated with the local AC does not receive CCM frames 418 from the peer MEP in the client domain (e.g. CE1) within an 419 interval equal to 3.5 times the CCM transmission period configured 420 for the MEP. This is the case when CCM transmission is enabled. 422 - A CCM with interface status TLV indicating interface down. Other 423 CCM interface status TLVs will not be used to indicate failure or 424 recovery from failure. 426 PE1 exits the AC Receive Defect state if all of the conditions that 427 resulted in entering the defect state are cleared. This includes 428 all of the following conditions: 430 - Any physical layer fault on the Ethernet interface, if detected 431 or notified previously is removed (e.g., loss of signal(LoS) 432 cleared, or Ethernet Link OAM [802.3] critical link event 433 notifications with "Dying Gasp" or "Critical Event" indication 434 cleared at an upstream node CE1). 436 - A MEP associated with the local AC does not receive any Ethernet 437 AIS frame within a period indicated by previously received AIS, if 438 AIS resulted in entering the defect state. 440 - A MEP associated with the local AC and configured with CCM 441 enabled receives a configured number (e.g., 3 or more) of 442 consecutive CCM frames from the peer MEP on CE1 within an interval 443 equal to a multiple (3.5) of the CCM transmission period configured 444 for the MEP. 446 - CCM indicates interface status up. 448 5.2. AC Transmit Defect State Entry or Exit 450 PE1 enters the AC Transmit Defect state if any of the following 451 conditions is met: 453 - It detects or is notified of a physical layer fault on the 454 Ethernet interface (e.g., via loss of signal (LoS) or Ethernet Link 455 OAM [802.3] critical link event notifications generated at an 456 upstream node CE1 with "Link Fault" indication). 458 - A MEP configured with CCM transmission enabled and associated 459 with the local AC receives a CCM frame, with its RDI bit set, from 460 the peer MEP in the client domain (e.g., CE1). 462 PE1 exits the AC Transmit Defect state if all of the conditions 463 that resulted in entering the defect state are cleared. This 464 includes all of the following conditions: 466 - Any physical layer fault on the Ethernet interface, if detected 467 or notified previously is removed (e.g., LOS cleared, Ethernet Link 468 OAM [802.3] critical link event notifications with "Link Fault" 469 indication cleared at an upstream node CE1). 471 - A MEP configured with CCM transmission enabled and associated 472 with the local AC does not receive a CCM frame with RDI bit set, 473 having received a previous CCM frame with RDI bit set from the peer 474 MEP in the client domain (e.g. CE1). 476 6. Ethernet AC and PW Defect States Interworking 478 6.1. PW Receive Defect Entry Procedures 480 When the PW status on PE1 transitions from working to PW Receive 481 Defect state, PE1's ability to receive user traffic from CE2 is 482 impacted. As a result, PE1 needs to notify CE1 about this problem. 484 Upon entry to the PW Receive Defect state, the following must be 485 done: 487 - If PE1 is configured with a down MEP associated with the local AC 488 and CCM transmission is not enabled, the MEP associated with the AC 489 must transmit AIS frames periodically to the peer MEP in the client 490 domain (e.g., on CE1) based on configured AIS transmission period. 492 - If PE1 is configured with a down MEP associated with the local AC 493 and CCM transmission is enabled, and the MEP associated with the AC 494 is configured to support Interface Status TLV in CCM messages, the 495 MEP associated with the AC must transmit CCM frames with Interface 496 Status TLV as being down to the peer MEP in the client domain 497 (e.g., on CE1). 499 - If PE1 is configured with a down MEP associated with the local AC 500 and CCM transmission is enabled, and the MEP associated with the AC 501 is configured to not support Interface Status TLV in CCM messages, 502 the MEP associated with the AC must stop transmitting CCM frames to 503 the peer MEP in the client domain (e.g., on CE1). 505 - If PE1 is configured to run E-LMI [MEF16] with CE1 and if E-LMI 506 is used for failure notification, PE1 must transmit E-LMI 507 asynchronous STATUS message with report type Single EVC 508 Asynchronous Status indicating that PW is Not Active. 510 Further, when PE1 enters the Receive Defect state, it must assume 511 that PE2 has no knowledge of the defect and must send reverse 512 defect failure notification to PE2. For MPLS PSN or MPLS-IP PSN, 513 this is done via either a PW Status notification message indicating 514 a reverse defect; or via VCCV-BFD diagnostic code of reverse defect 515 if VCCV CV type of 0x08 had been negotiated. When Native Service 516 OAM mechanism is supported on PE1, it can also use the NS OAM 517 notification as specified in Section 4.1. 519 If PW receive defect is entered as a result of a forward defect 520 notification from PE2 or via loss of control adjacency, no 521 additional action is needed since PE2 is expected to be aware of 522 the defect. 524 6.2. PW Receive Defect Exit Procedures 526 When the PW status transitions from PW Receive Defect state to 527 working, PE1's ability to receive user traffic from CE2 is 528 restored. As a result, PE1 needs to cease defect notification to 529 CE1 by performing the following: 531 - If PE1 is configured with a down MEP associated with the local AC 532 and CCM transmission is not enabled, the MEP associated with the AC 533 must stop transmitting AIS frames towards the peer MEP in the 534 client domain (e.g., on CE1). 536 - If PE1 is configured with a down MEP associated with the local AC 537 and CCM transmission is enabled, and the MEP associated with the AC 538 is configured to support Interface Status TLV in CCM messages, the 539 MEP associated with the AC must transmit CCM frames with Interface 540 Status TLV as being Up to the peer MEP in the client domain (e.g., 541 on CE1). 543 - If PE1 is configured with a down MEP associated with the local AC 544 and CCM transmission is enabled, and the MEP associated with the AC 545 is configured to not support Interface Status TLV in CCM messages, 546 the MEP associated with the AC must resume transmitting CCM frames 547 to the peer MEP in the client domain (e.g., on CE1). 549 - If PE1 is configured to run E-LMI [MEF16] with CE1 and E-LMI is 550 used for fault notification, PE1 must transmit E-LMI asynchronous 551 STATUS message with report type Single EVC Asynchronous Status 552 indicating that PW is Active. 554 Further, if the PW receive defect was explicitly detected by PE1, 555 it must now notify PE2 about clearing of Receive Defect state by 556 clearing reverse defect notification. For PWs over MPLS PSN or 557 MPLS-IP PSN, this is either done via PW Status message indicating 558 working; or via VCCV-BFD diagnostic code if VCCV CV type of 559 0x08/0x20 had been negotiated. When Native Service OAM mechanism is 560 supported on PE, it can also clear the NS OAM notification 561 specified in Section 4.1. 563 If PW receive defect was established via notification from PE2 or 564 via loss of control adjacency, no additional action is needed, 565 since PE2 is expected to be aware of the defect clearing. 567 6.3. PW Transmit Defect Entry Procedures 569 When the PW status transitions from working to PW Transmit Defect 570 state, PE1's ability to transmit user traffic to CE2 is impacted. 571 As a result, PE1 needs to notify CE1 about this problem which has 572 been detected by PE1. 574 Upon entry to the PW Transmit Defect state, the following must be 575 done: 577 - If PE1 is configured with a down MEP associated with the local AC 578 and CCM transmission is enabled, the MEP associated with the AC 579 MUST set the RDI bit in transmitted CCM frames or send status TLV 580 with interface down to the peer MEP in the client domain (e.g., on 581 CE1). 583 - If PE1 is configured to run E-LMI [MEF16] with CE1 and E-LMI is 584 used for fault notification, PE1 must transmit E-LMI asynchronous 585 STATUS message with report type Single EVC Asynchronous Status 586 indicating that PW is Not Active. 588 6.4. PW Transmit Defect Exit Procedures 590 When the PW status transitions from PW Transmit Defect state to 591 working, PE1's ability to transmit user traffic to CE2 is restored. 592 As a result, PE1 needs to cease defect notifications to CE1 and 593 perform the following: 595 - If PE1 is configured with a down MEP associated with the local AC 596 and CCM transmission is enabled, the MEP associated with the AC 597 must clear the RDI bit in the transmitted CCM frames to the peer 598 MEP (e.g., on CE1). 600 - If PE1 is configured to run E-LMI [MEF16] with CE1, PE1 must 601 transmit E-LMI asynchronous STATUS message with report type Single 602 EVC Asynchronous Status indicating that PW is Active. 604 6.5. AC Receive Defect Entry Procedures 606 When AC status transitions from working to AC Receive Defect state, 607 PE1's ability to receive user traffic from CE1 is impacted. As a 608 result, PE1 needs to notify PE2 and CE1 about this problem. 610 If the AC receive defect is detected by PE1, it must notify PE2 in 611 the form of a forward defect notification. 613 When NS OAM is not supported on PE1, and for PW over MPLS PSN or 614 MPLS-IP PSN, forward defect notification is done via either PW 615 Status message indicating a forward defect or via VCCV-BFD 616 diagnostic code of forward defect if VCCV CV type of 0x08/0x20 had 617 been negotiated. 619 When Native Service OAM mechanism is supported on PE1, it can also 620 use the NS OAM notification as specified in Section 4.1. 622 In addition to the above actions, PE1 must perform the following: 624 - If PE1 is configured with a down MEP associated with the local AC 625 and CCM transmission is enabled, the MEP associated with the AC 626 must set the RDI bit in transmitted CCM frames. 628 6.6. AC Receive Defect Exit Procedures 630 When AC status transitions from AC Receive Defect to working, PE1's 631 ability to receive user traffic from CE1 is restored. As a result, 632 PE1 needs to cease defect notifications to PE2 and CE1 and perform 633 the following: 635 - When NS OAM is not supported on PE1 and for PW over MPLS PSN or 636 MPLS-IP PSN, forward defect notification is cleared via PW Status 637 message indicating a working state; or via VCCV-BFD diagnostic code 638 if VCCV CV type of 0x08 or 0x20 had been negotiated. 640 - When Native Service OAM mechanism is supported on PE1, PE1 clears 641 the NS OAM notification as specified in Section 4.1. 643 - If PE1 is configured with a down MEP associated with the local AC 644 and CCM transmission is enabled, the MEP associated with the AC 645 must clear the RDI bit in transmitted CCM frames to the peer MEP in 646 the client domain (e.g., on CE1). 648 6.7. AC Transmit Defect Entry Procedures 650 When AC status transitions from working to AC Transmit Defect, 651 PE1's ability to transmit user traffic to CE1 is impacted. As a 652 result, PE1 needs to notify PE2 about this problem. 654 If the AC transmit defect is detected by PE1, it must notify PE2 in 655 the form of a reverse defect notification. 657 When NS OAM is not supported on PE1, in PW over MPLS PSN or MPLS-IP 658 PSN, reverse defect notification is either done via PW Status 659 message indicating a reverse defect; or via VCCV-BFD diagnostic 660 code of reverse defect if VCCV CV type of 0x08 or 0x20 had been 661 negotiated. 663 When Native Service OAM mechanism is supported on PE1, it can also 664 use the NS OAM notification as specified in Section 4.1. 666 6.8. AC Transmit Defect Exit Procedures 668 When AC status transitions from AC Transmit defect to working, 669 PE1's ability to transmit user traffic to CE1 is restored. As a 670 result, PE1 must clear reverse defect notification to PE2. 672 When NS OAM is not supported on PE1 and for PW over MPLS PSN or 673 MPLS-IP PSN, reverse defect notification is cleared via either a PW 674 Status message indicating a working state or via VCCV-BFD 675 diagnostic code if VCCV CV type of 0x08 had been negotiated. 677 When Native Service OAM mechanism is supported on PE1, PE1 can 678 clear NS OAM notification as specified in Section 4.1. 680 7. Security Considerations 682 The OAM interworking mechanisms described in this document do not 683 change the security functions inherent in the actual messages. All 684 generic security considerations applicable to PW traffic specified 685 in Section 10 of [RFC3985] are applicable to NS OAM messages 686 transferred inside the PW. 688 Security considerations in Section 10 of [RFC5085] for VCCV apply 689 to the OAM messages thus transferred. Security considerations 690 applicable to the PWE3 control protocol of [RFC4447] Section 8.2 691 apply to OAM indications transferred using the LDP status message. 693 Since the mechanisms of this document enable propagation of OAM 694 messages and fault conditions between native service networks and 695 PSNs, continuity of the end-to-end service depends on a trust 696 relationship between the operators of these networks. Security 697 considerations for such scenarios are discussed in Section 7 of 698 [RFC5254]. 700 8. IANA Considerations 702 This document has no actions for IANA. 704 9. Acknowledgments 706 The authors are thankful to Samer Salam, Matthew Bocci and Yaakov 707 Stein for their valuable comments. 709 10. References 711 10.1. Normative References 713 [RFC6310] "Pseudowire (PW) Operations, Administration, and 714 Maintenance (OAM) Message Mapping", RFC 6310, July 2011. 716 [Y.1731] "OAM Functions and mechanisms for Ethernet based 717 networks", ITU-T Y.1731, May 2006. 719 [802.1ag] "Connectivity Fault Management", IEEE 802.1ag, December 720 2007. 722 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 723 Requirement Levels", BCP 14, RFC 2119, March 1997. 725 [RFC4447] "Pseudowire Setup and Maintenance using LDP", RFC4447, 726 April 2006. 728 [RFC5885] "Bidirectional Forwarding Detection (BFD) for the 729 Pseudowire Virtual Circuit Connectivity Verification (VCCV)", 730 RFC5885, June 2010. 732 [802.3] "CDMA/CD access method and physical layer specifications", 733 Clause 57 for Operations, Administration and Maintenance, 2005. 735 [MEF16] "Ethernet Local Management Interface", MEF16, January 2006. 737 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 738 Connectivity Verification (VCCV): A Control Channel for 739 Pseudowires", RFC 5085, December 2007. 741 10.2. Informative References 743 [RFC3985] "Pseudo Wire Emulation Edge-to-Edge(PWE3) Architecture", 744 RFC 3985, April 2005. 746 [RFC5659] "An Architecture for Multi-Segment Pseudo Wire Emulation 747 Edge-to-Edge", RFC5659, October 2009. 749 [RFC5254] Bitar, N., Bocci, M., and L. Martini, "Requirements for 750 Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", RFC 5254, 751 October 2008. 753 11. Appendix A: Ethernet Native Service Management 755 Ethernet OAM mechanisms are broadly classified into two categories: 756 Fault Management (FM) and Performance Monitoring (PM). ITU-T Y.1731 757 provides coverage for both FM and PM while IEEE 802.1ag provides 758 coverage for a sub-set of FM functions. 760 Ethernet OAM also introduces the concept of Maintenance Entity (ME) 761 which is used to identify the entity that needs to be managed. An 762 ME is inherently a point-to-point association. However, in case of 763 a multipoint association, Maintenance Entity Group (MEG) consisting 764 of different MEs is used. IEEE 802.1 uses the concept of 765 Maintenance Association (MA) which is used to identify both point- 766 to-point and multipoint associations. Each MA consists of 767 Maintenance End Points (MEPs) which are responsible for originating 768 OAM frames. In between the MEPs, there can also be Maintenance 769 Intermediate Points (MIPs) which do not originate OAM frames 770 however do respond to OAM frames from MEPs. 772 Ethernet OAM allows for hierarchical maintenance entities to allow 773 for simultaneous end-to-end and segment monitoring. This is 774 achieved by having a provision of up to 8 Maintenance Domain Levels 775 (MD Levels) where each MEP or MIP is associated with a specific MD 776 Level. 778 It is important to note that the common set of FM mechanisms 779 between IEEE 802.1ag and ITU-T Y.1731 are completely compatible. 781 The common FM mechanisms include: 783 1) Continuity Check Messages (CCM) 785 2) Loopback Message (LBM) and Loopback Reply (LBR) 787 3) Linktrace Message (LTM) and Linktrace Reply (LTR) 789 CCM messages are used for fault detection including misconnections 790 and mis-configurations. Typically CCM messages are sent as 791 multicast frames or Unicast frames and also allow RDI 792 notifications. LBM/LBR are used to perform fault verification, 793 while also allow for MTU verification and CIR/EIR measurements. 794 LTM/LTR can be used for discovering the path traversed between a 795 MEP and another target MIP/MEP in the same MA. LTM/LTR also allow 796 for fault localization. 798 In addition, ITU-T Y.1731 also specifies the following FM 799 functions: 801 4) Alarm Indication Signal (AIS) 803 AIS allows for fault notification to downstream and upstream nodes. 805 Further, ITU-T Y.1731 also specifies the following PM functions: 807 5) Loss Measurement Message (LMM) and Reply (LMR) 808 6) Delay Measurement Message (DMR) and Reply (DMR) 810 7) 1-way Delay Message (1DM) 812 While LMM/LMR is used to measure Frame Loss Ratio (FLR), DMM/DMR is 813 used to measure single-ended (aka two-way) Frame Delay (FD) and 814 Frame Delay Variation (FDV, also known as Jitter). 1DM can be used 815 for dual-ended (aka one-way) FD and FDV measurements. 817 Authors' Addresses 819 Dinesh Mohan 820 Nortel 821 3500 Carling Ave 822 Ottawa, ON K2H8E9 823 Email: dinmohan@hotmail.com 825 Nabil Bitar 826 Verizon 827 60 Sylvan Road 828 Waltham, MA 02145 829 Email: nabil.n.bitar@verizon.com 831 Ali Sajassi 832 Cisco 833 170 West Tasman Drive 834 San Jose, CA 95134, US 835 Email: sajassi@cisco.com 837 Simon Delord 838 Alcatel-Lucent 839 215 Spring Street 840 Melbourne, Australia 841 E-mail: simon.delord@gmail.com 843 Philippe Niger 844 France Telecom 845 2 av. Pierre Marzin 846 22300 LANNION, France 847 E-mail: philippe.niger@francetelecom.com 849 Ray Qiu 850 Huawei 851 330 Central Expressway 852 Santa Clara, CA 95050, US 853 Email: ray@huawei.com