idnits 2.17.1 draft-ietf-pwe3-mpls-eth-oam-iwk-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 30, 2013) is 4098 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 (~~), 1 warning (==), 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: Proposed Standard 5 Expires: June 2013 Nabil Bitar (Ed.) 6 Verizon 8 Ali Sajassi (Ed.) 9 Cisco 11 January 30, 2013 13 MPLS and Ethernet OAM Interworking 14 draft-ietf-pwe3-mpls-eth-oam-iwk-07.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 Internet-Drafts are draft documents valid for a maximum of six 37 months and may be updated, replaced, or obsoleted by other 38 documents at any time. It is inappropriate to use Internet- 39 Drafts as reference material or to cite them other than as "work 40 in progress." 42 This Internet-Draft will expire on June 30, 2013. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with 54 respect to this document. Code Components extracted from this 55 document must include Simplified BSD License text as described 56 in Section 4.e of the Trust Legal Provisions and are provided 57 without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Specification of Requirements........................ 3 62 2. Introduction......................................... 3 63 2.1. Reference Model and Defect Locations............ 5 64 2.2. Abstract Defect States.......................... 5 65 3. Abbreviation and Terminology......................... 6 66 3.1. Abbreviations................................... 6 67 3.2. Terminology..................................... 7 68 4. PW Status and Defects................................ 7 69 4.1. Use of Native Service (NS) Notification......... 8 70 4.2. Use of PW Status Notification for MPLS PSNs..... 8 71 4.3. Use of BFD Diagnostic Codes..................... 9 72 4.4. PW Defect States Entry and Exit Criteria........ 9 73 4.4.1. PW Receive Defect State Entry and Exit..... 9 74 4.4.2. PW Transmit Defect State Entry and Exit... 10 75 5. Ethernet AC Defect States Entry and Exit Criteria .. 10 76 5.1. AC Receive Defect State Entry and Exit......... 10 77 5.2. AC Transmit Defect State Entry and Exit........ 12 78 6. Ethernet AC and PW Defect States Interworking....... 12 79 6.1. PW Receive Defect Entry Procedures............. 12 80 6.2. PW Receive Defect Exit Procedures.............. 13 81 6.3. PW Transmit Defect Entry Procedures............ 14 82 6.4. PW Transmit Defect Exit Procedures............. 15 83 6.5. AC Receive Defect Entry Procedures............. 15 84 6.6. AC Receive Defect Exit Procedures.............. 16 85 6.7. AC Transmit Defect Entry Procedures............ 16 86 6.8. AC Transmit Defect Exit Procedures............. 17 87 7. Security Considerations............................. 17 88 8. IANA Considerations................................. 17 89 9. Acknowledgments..................................... 17 90 10. References......................................... 18 91 10.1. Normative References.......................... 18 92 10.2. Informative References........................ 18 93 11. Appendix A: Ethernet Native Service Management..... 19 95 1. Specification of Requirements 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 99 this document are to be interpreted as described in [RFC2119]. 101 2. Introduction 103 This document specifies the mapping of defect states between 104 Ethernet Attachment Circuits (ACs) and associated Ethernet 105 Pseudowires (PWs) connected in accordance to the PWE3 architecture 106 [RFC3985] to realize an end-to-end emulated Ethernet service. This 107 document augments the mapping of defect states between a PW and 108 associated AC of the end-to-end emulated service in [RFC6310]. It 109 covers the following Ethernet OAM (Operations, Administration and 110 Maintenance) mechanisms and their interworking with PW OAM 111 mechanisms: 113 - Ethernet Continuity Check (CC) [802.1ag][Y.1731] 114 - Ethernet Alarm Indication Signaling (AIS) and Remote Defect 115 Indication (RDI) [Y.1731] 116 - Ethernet Link OAM [802.3] 117 - Ethernet Local Management Interface {E-LMI} [MEF16] 119 Ethernet Link OAM [802.3] allows some Link defect states to be 120 detected and communicated across an Ethernet Link. When an Ethernet 121 AC is an Ethernet physical port, there MAY be some application of 122 Ethernet Link OAM [802.3]. Further, E-LMI [MEF16] also allows for 123 some Ethernet Virtual Circuit (EVC) defect states to be 124 communicated across an Ethernet UNI where Ethernet UNI constitutes 125 a single hop Ethernet Link (i.e. without any 802.1Q/.1ad compliant 126 bridges in between). There may be some application of E-LMI [MEF16] 127 for failure notification across single hop Ethernet AC in certain 128 deployments that specifically do not support [802.1ag] and/or 129 [Y.1731]. [Y.1731] and [802.1ag] based mechanisms are applicable in 130 all types of Ethernet ACs. Ethernet Link OAM [802.3] and E-LMI 131 [MEF16] are optional and their applicability is called out, where 132 applicable. 134 Native Service (NS) OAM MAY be transported transparently over the 135 corresponding PW as user data. This is referred to as "the single 136 emulated OAM loop" mode per [RFC6310]. For Ethernet, as an example, 137 802.1ag continuity check messages (CCMs) between two Maintenance 138 End Points (MEPs) can be transported transparently as user data 139 over the corresponding PW. At MEP locations, service failure is 140 detected when CCMs are not received over an interval that is 3.5 141 times the local CCM transmission interval. This is one of the 142 failure conditions detected via CC. MEP peers can exist between 143 Customer Equipment (CE) pairs (MEPs of a given Maintenance Entity 144 Group (MEG) reside on the CEs), PE pairs (the MEPs of a given MEG 145 reside on the PEs), or between the CE and PE (the MEPs of a given 146 MEG reside on the PE and CE), as long as the MEG level nesting 147 rules are maintained. It should be noted that Ethernet allows the 148 definition of up to 8 MEG levels, each compromising of MEPs (Down 149 MEPs and Up MEPs) and Maintenance Intermediate Points (MIPs). These 150 levels can be nested or touching. MEPs and MIPs generate and 151 process messages in the same MEG level. Thus, whenever in this 152 document we refer to messages sent by a MEP or a MIP to a peer MEP 153 or MIP, these MEPs and MIPs are in the same MEG level. 155 When interworking two networking domains, such as native Ethernet 156 and PWs to provide an end-to-end emulated service, there is need to 157 identify the failure domain and location even when a PE supports 158 both the NS OAM mechanisms and the PW OAM mechanisms. In addition, 159 scalability constraints may not allow running proactive monitoring, 160 such as CCMs with transmission enabled, at a PE to detect the 161 failure of an EVC across the PW domain. Thus, network-driven alarms 162 generated upon failure detection in the NS or PW domain and their 163 mappings to the other domain are needed. There are also cases where 164 a PE MAY not be able to process NS OAM messages received on the PW 165 even when such messages are defined, as in Ethernet case, 166 necessitating the need for fault notification message mapping 167 between the PW domain and the NS domain. 169 For Multi-Segment PWs (MS-PWs) [RFC5659], Switching PEs (S-PEs) are 170 not aware of the NS. Thus, failure detection and notification at S- 171 PEs will be based on PW OAM mechanisms. Mapping between PW OAM and 172 NS OAM will be required at the Terminating PEs (T-PEs) to propagate 173 the failure notification to the EVC endpoints. 175 Similar to [RFC6310], the intent of this document is to standardize 176 the behavior of PEs with respect to failures on Ethernet ACs and 177 PWs, so that there is no ambiguity about the alarms generated and 178 consequent actions undertaken by PEs in response to specific 179 failure conditions. 181 2.1. Reference Model and Defect Locations 183 Figure 1 is the same as used in [RFC6310] and is reproduced in this 184 document as a reference to highlight defect locations. 186 ACs PSN tunnel ACs 187 +----+ +----+ 188 +----+ | PE1|==================| PE2| +----+ 189 | |---(a)---(b)..(c)......PW1..(d)..(e)..(f)---(g)---| | 190 | CE1| (N1) | | | | (N2) |CE2 | 191 | |----------|............PW2.............|----------| | 192 +----+ | |==================| | +----+ 193 ^ +----+ +----+ ^ 194 | Provider Edge 1 Provider Edge 2 | 195 | | 196 |<-------------- Emulated Service ---------------->| 197 Customer Customer 198 Edge 1 Edge 2 199 Figure 1: PWE3 Network Defect Locations 201 2.2. Abstract Defect States 203 Abstract Defect States are also introduced in [RFC6310]. This 204 document uses the same conventions, as shown in Figure 2, from 205 [RFC6310]. It may be noted however that CE devices, shown in Figure 206 2, do not necessarily have to be end customer devices. These are 207 essentially devices in client network segments that are connecting 208 to the Packet Switched Network (PSN) for the emulated services. 210 +-----+ 211 ----AC receive ----->| |-----PW transmit----> 212 CE1 | PE1 | PE2/CE2 213 <---AC transmit------| |<----PW receive----- 214 +-----+ 215 (arrows indicate direction of user traffic impacted by a defect) 217 Figure 2: Transmit and Receive Defect States and Notifications 219 The procedures outlined in this document define the entry and exit 220 criteria for each of the four defect states with respect to 221 Ethernet ACs and corresponding PWs, and the consequent actions that 222 PE1 MUST support to properly interwork these defect states and 223 corresponding notification messages between the PW domain and the 224 Native Service (NS) domain. Receive Defect state SHOULD have 225 precedence over Transmit Defect state in terms of handling, when 226 both transmit and receive defect states are identified 227 simultaneously. 229 Following is a summary of the defect states from the viewpoint of 230 PE1 in Figure 2: 232 - A PW receive defect at PE1 impacts PE1 ability to receive traffic 233 on the PW. PW defect state entry and exit criteria are described in 234 section 4.4.1. 236 - A PW transmit defect at PE1 impacts PE1 ability to send user 237 traffic toward CE2. PE1 MAY be notified of a PW transmit defect via 238 Reverse Defect Indication from PE2, which could point to problems 239 associated with PE2's inability to receive traffic on the PW or 240 PE2's inability to transmit traffic on its local AC. PW transmit 241 state defect entry and exit criteria are described in section 242 4.4.2. 244 - An AC receive defect at PE1 impacts PE1 ability to receive user 245 traffic from the Client domain attached to PE1 via that AC. AC 246 receive state entry and exit criteria are described in section 5.1 248 - An AC transmit defect at PE1 impacts PE1 ability to send user 249 traffic on the local AC. AC transmit defect state entry and exit 250 criteria are described in section 5.2. 252 3. Abbreviation and Terminology 254 3.1. Abbreviations 256 AIS Alarm Indication Signal 257 AC Attachment Circuit 258 BFD Bidirectional Forwarding Detection 259 CC Continuity Check 260 CCM Continuity Check Message 261 CE Customer Equipment 262 CV Connectivity Verification 263 E-LMI Ethernet Local Management Interface 264 EVC Ethernet Virtual Circuit 265 LDP Label Distribution Protocol 266 LoS Loss of Signal 267 MA Maintenance Association 268 MD Maintenance Domain 269 ME Maintenance Entity 270 MEG Maintenance Entity Group 271 MEP MEG End Point 272 MIP MEG End Point 273 MPLS Multiprotocol Label Switching 274 MS-PW Multi-Segment Pseudowire 275 NS Native Service 276 OAM Operations, Administration, and Maintenance 277 PE Provider Edge 278 PSN Packet Switched Network 279 PW Pseudowire 280 RDI means Remote Defect Indication when used in the context of 281 CCM 282 RDI Reverse Defect Indication when used to semantically refer 283 to defect indication in the reverse direction 284 S-PE Switching Provider Edge 285 TLV Type Length Value 286 T-PE Terminating Provider Edge 288 3.2. Terminology 290 This document uses the following terms with corresponding 291 definitions: 293 - MEG Level: identifies a value in the range of 0-7 associated 294 with Ethernet OAM frame. MEG Level identifies the span of the 295 Ethernet OAM frame. 297 - MEP: MEG End Point is responsible for origination and 298 termination of OAM frames for a given MEG. 300 - MIP: MEG Intermediate Point is located between peer 301 MEPs and can process OAM frames but does not initiate or 302 terminate them. 304 Further, this document also uses the terminology and conventions 305 used in [RFC6310]. 307 4. PW Status and Defects 309 [RFC6310] introduces a range of defects that impact PW status. All 310 these defect conditions are applicable for Ethernet PWs. 312 Similarly, there are different mechanisms described in [RFC6310] to 313 detect PW defects, depending on the PSN type (e.g., MPLS PSN, MPLS- 314 IP PSN). Any of these mechanisms can be used when monitoring the 315 state of Ethernet PWs. [RFC6310] also discusses the applicability 316 of these failure detection mechanisms. 318 4.1. Use of Native Service (NS) Notification 320 When a MEP is defined on the PE and associated with an Ethernet 321 PW, the PE can use native service OAM capabilities for failure 322 notifications. Options include: 324 - Sending of AIS frames from the local MEP to the MEP on the 325 remote PE when the MEP needs to convey PE receive defects, and when 326 CCM transmission is disabled. 328 - Suspension of CCM frames transmission from the local MEP to 329 the peer MEP on the remote PE to convey PE receive defects, when 330 CCM transmission is enabled. 332 - Setting the RDI bit in transmitted CCM frames, when loss of 333 CCMs from the peer MEP is detected or the PE needs to convey PW 334 reverse defects. 336 These NS OAM notifications are inserted into the corresponding PW. 338 Similarly, when the defect conditions are cleared, a PE can take 339 one of the following actions, depending on the mechanism that was 340 used for failure notification, to clear the defect sate on the peer 341 PE: 342 - Stopping AIS frame transmission from the local MEP to the 343 MEP on the remote PE to clear PW receive defects. 345 - Resuming CCM frames transmission from the local MEP to the 346 peer MEP on the remote PE to clear PW forward defects notification, 347 when CCM transmission is enabled. 349 - Clearing the RDI bit in transmitted CCM frames, to clear PW 350 transmit defects notification, when CCM transmission is enabled. 352 4.2. Use of PW Status Notification for MPLS PSNs 354 When PWs are established using the Label Distribution Protocol 355 (LDP), LDP status notification signaling MUST be used as the 356 default mechanism to signal AC and PW status and defects [RFC4447]. 357 That is known as the "coupled loop mode". For PWs established over 358 an MPLS or MPLS-IP PSN using other mechanisms (e.g. static 359 configuration), inband signaling using VCCV-BFD [RFC5885] SHOULD be 360 used to convey AC and PW status and defects. 362 [RFC6310] identifies the following PW defect status codepoints: 364 - Forward defect: corresponds to a logical OR of local AC 365 (ingress) Receive fault, local PSN-facing PW (egress) transmit 366 fault, and PW not forwarding fault. 368 - Reverse defect: corresponds to a logical OR of local AC 369 (egress) transmit fault and local PW PSN-facing (ingress) 370 receive fault. 372 There are also scenarios where a PE carries out PW label withdrawal 373 instead of PW status notification. These include administrative 374 disablement of the PW or loss of Target LDP session with the peer 375 PE. 377 4.3. Use of BFD Diagnostic Codes 379 When using VCCV, the control channel (CC) type and Connectivity 380 Verification (CV) Type are agreed on between the peer PEs using the 381 VCC parameter field signaled as a sub-TLV of the interface 382 parameters TLV when using FEC 129 and the interface parameter sub- 383 TLV when using FEC 128. 385 As defined in [RFC6310], when CV type of 0x04 0r 0x10 is used to 386 indicate that BFD is used for PW fault detection only, PW defect is 387 detected via the BFD session while other defects, such as AC defect 388 or PE internal defects preventing it from forwarding traffic, are 389 communicated via LDP Status notification message in MPLS and MPLS- 390 IP PSNs or other mechanisms in L2TP-IP PSN. 392 Similarly, when CV type of 0x08 or 0x20 is used to indicate that 393 BFD is used for both PW fault detection and AC/PW Fault 394 Notification, all defects are signaled via BFD. 396 4.4. PW Defect States Entry and Exit Criteria 398 4.4.1. PW Receive Defect State Entry and Exit 400 As described in [RFC6310] section 6.2.1, PE1 will enter the PW 401 receive defect state if one or more of the following occurs: 403 - It receives a forward defect indication (FDI) from PE2 404 indicating either a receive defect on the remote AC or that PE2 405 detected or was notified of downstream PW fault. 407 - It detects loss of connectivity on the PSN tunnel upstream of 408 PE1, which affects the traffic it receives from PE2. 410 - It detects a loss of PW connectivity through VCCV-BFD, VCCV- 411 PING, or NS OAM mechanisms (i.e., CC) when enabled, which affects 412 the traffic it receives from PE2. 414 Note that if the PW LDP control session between the PEs fails, the 415 PW is torn down and needs to be re-established. However, the 416 consequent actions towards the ACs are the same as if the PW 417 entered the receive defect state. 419 PE1 will exit the PW receive defect state when the following 420 conditions are met. Note that this may result in a transition to 421 the PW operational state or the PW transmit defect state. 423 - All previously detected defects have disappeared 424 - PE2 cleared the FDI, if applicable 426 4.4.2. PW Transmit Defect State Entry and Exit 428 PE1 will enter the PW transmit defect state if the following 429 conditions occur: 431 - It receives a Reverse Defect Indication (RDI) from PE2 432 indicating either a transmit fault on the remote AC or that PE2 433 detected or was notified of an upstream PW fault. 435 - It is not already in the PW receive defect state. 437 PE1 will exit the transmit defect state if it receives an OAM 438 message from PE2 clearing the RDI, or it has entered the PW 439 receive defect state. 441 5. Ethernet AC Defect States Entry and Exit Criteria 443 5.1. AC Receive Defect State Entry and Exit 445 PE1 enters the AC Receive Defect state if any of the following 446 conditions is met: 448 - It detects or is notified of a physical layer fault on the 449 Ethernet interface. Ethernet link failure can be detected based on 450 loss of signal (LoS) or via Ethernet Link OAM [802.3] critical link 451 event notifications generated at an upstream node CE1 with "Dying 452 Gasp" or "Critical Event" indication, or via a client Signal Fail 453 message [Y.1731]. 455 - A MEP associated with the local AC receives an Ethernet AIS frame 456 from CE1. 458 - A MEP associated with the local AC does not receive CCM frames 459 from the peer MEP in the client domain (e.g. CE1) within an 460 interval equal to 3.5 times the CCM transmission period configured 461 for the MEP. This is the case when CCM transmission is enabled. 463 - A CCM with interface status TLV indicating interface down. Other 464 CCM interface status TLVs will not be used to indicate failure or 465 recovery from failure. 467 It should be noted when a MEP at a PE or a CE receives a CCM with 468 the wrong MEG ID, MEP ID, or MEP level, the receiving PE or CE 469 SHOULD treat such an event as an AC receive defect. In any case, if 470 such events persist for 3.5 times the MEP local CCM transmission 471 time, loss of continuity will be declared at the receiving end. 473 PE1 exits the AC Receive Defect state if all of the conditions that 474 resulted in entering the defect state are cleared. This includes 475 all of the following conditions: 477 - Any physical layer fault on the Ethernet interface, if detected 478 or notified previously is removed (e.g., loss of signal (LoS) 479 cleared, or Ethernet Link OAM [802.3] critical link event 480 notifications with "Dying Gasp" or "Critical Event" indication 481 cleared at an upstream node CE1). 483 - A MEP associated with the local AC does not receive any Ethernet 484 AIS frame within a period indicated by previously received AIS, if 485 AIS resulted in entering the defect state. 487 - A MEP associated with the local AC and configured with CCM 488 enabled receives a configured number (e.g., 3 or more) of 489 consecutive CCM frames from the peer MEP on CE1 within an interval 490 equal to a multiple (3.5) of the CCM transmission period configured 491 for the MEP. 493 - CCM indicates interface status up. 495 5.2. AC Transmit Defect State Entry and Exit 497 PE1 enters the AC Transmit Defect state if any of the following 498 conditions is met: 500 - It detects or is notified of a physical layer fault on the 501 Ethernet interface where the AC is configured (e.g., via loss of 502 signal (LoS) or Ethernet Link OAM [802.3] critical link event 503 notifications generated at an upstream node CE1 with "Link Fault" 504 indication). 506 - A MEP configured with CCM transmission enabled and associated 507 with the local AC receives a CCM frame, with its RDI (Remote Defect 508 Indication) bit set, from the peer MEP in the client domain (e.g., 509 CE1). 511 PE1 exits the AC Transmit Defect state if all of the conditions 512 that resulted in entering the defect state are cleared. This 513 includes all of the following conditions: 515 - Any physical layer fault on the Ethernet interface, if detected 516 or notified previously is removed (e.g., LOS cleared, Ethernet Link 517 OAM [802.3] critical link event notifications with "Link Fault" 518 indication cleared at an upstream node CE1). 520 - A MEP configured with CCM transmission enabled and associated 521 with the local AC does not receive a CCM frame with RDI bit set, 522 having received a previous CCM frame with RDI bit set from the peer 523 MEP in the client domain (e.g. CE1). 525 6. Ethernet AC and PW Defect States Interworking 527 6.1. PW Receive Defect Entry Procedures 529 When the PW status on PE1 transitions from working to PW Receive 530 Defect state, PE1's ability to receive user traffic from CE2 is 531 impacted. As a result, PE1 needs to notify CE1 about this problem. 533 Upon entry to the PW Receive Defect state, the following MUST be 534 done: 536 - If PE1 is configured with a down MEP associated with the local AC 537 and CCM transmission is not enabled, the MEP associated with the AC 538 MUST transmit AIS frames periodically to the peer MEP in the client 539 domain (e.g., on CE1) based on configured AIS transmission period. 541 - If PE1 is configured with a down MEP associated with the local AC 542 and CCM transmission is enabled, and the MEP associated with the AC 543 is configured to support Interface Status TLV in CCM messages, the 544 MEP associated with the AC MUST transmit CCM frames with Interface 545 Status TLV as being down to the peer MEP in the client domain 546 (e.g., on CE1). 548 - If PE1 is configured with a down MEP associated with the local AC 549 and CCM transmission is enabled, and the MEP associated with the AC 550 is configured to not support Interface Status TLV in CCM messages, 551 the MEP associated with the AC MUST stop transmitting CCM frames to 552 the peer MEP in the client domain (e.g., on CE1). 554 - If PE1 is configured to run E-LMI [MEF16] with CE1 and if E-LMI 555 is used for failure notification, PE1 MUST transmit E-LMI 556 asynchronous STATUS message with report type Single EVC 557 Asynchronous Status indicating that PW is Not Active. 559 Further, when PE1 enters the Receive Defect state, it MUST assume 560 that PE2 has no knowledge of the defect and MUST send reverse 561 defect failure notification to PE2. For MPLS PSN or MPLS-IP PSN, 562 this is done via either a PW Status notification message indicating 563 a reverse defect; or via VCCV-BFD diagnostic code of reverse defect 564 if VCCV CV type of 0x08 or 0x20 had been negotiated. When Native 565 Service OAM mechanism is supported on PE1, it can also use the NS 566 OAM notification as specified in Section 4.1. 568 If PW receive defect is entered as a result of a forward defect 569 notification from PE2 or via loss of control adjacency, no 570 additional action is needed since PE2 is expected to be aware of 571 the defect. 573 6.2. PW Receive Defect Exit Procedures 575 When the PW status transitions from PW Receive Defect state to 576 working, PE1's ability to receive user traffic from CE2 is 577 restored. As a result, PE1 needs to cease defect notification to 578 CE1 by performing the following: 580 - If PE1 is configured with a down MEP associated with the local AC 581 and CCM transmission is not enabled, the MEP associated with the AC 582 MUST stop transmitting AIS frames towards the peer MEP in the 583 client domain (e.g., on CE1). 585 - If PE1 is configured with a down MEP associated with the local AC 586 and CCM transmission is enabled, and the MEP associated with the AC 587 is configured to support Interface Status TLV in CCM messages, the 588 MEP associated with the AC MUST transmit CCM frames with Interface 589 Status TLV as being Up to the peer MEP in the client domain (e.g., 590 on CE1). 592 - If PE1 is configured with a down MEP associated with the local AC 593 and CCM transmission is enabled, and the MEP associated with the AC 594 is configured to not support Interface Status TLV in CCM messages, 595 the MEP associated with the AC MUST resume transmitting CCM frames 596 to the peer MEP in the client domain (e.g., on CE1). 598 - If PE1 is configured to run E-LMI [MEF16] with CE1 and E-LMI is 599 used for fault notification, PE1 MUST transmit E-LMI asynchronous 600 STATUS message with report type Single EVC Asynchronous Status 601 indicating that PW is Active. 603 Further, if the PW receive defect was explicitly detected by PE1, 604 it MUST now notify PE2 about clearing of Receive Defect state by 605 clearing reverse defect notification. For PWs over MPLS PSN or 606 MPLS-IP PSN, this is either done via PW Status message indicating 607 working; or via VCCV-BFD diagnostic code if VCCV CV type of 608 0x08/0x20 had been negotiated. When Native Service OAM mechanism is 609 supported on PE, it can also clear the NS OAM notification as 610 specified in Section 4.1. 612 If PW receive defect was established via notification from PE2 or 613 via loss of control adjacency, no additional action is needed, 614 since PE2 is expected to be aware of the defect clearing. 616 6.3. PW Transmit Defect Entry Procedures 618 When the PW status transitions from working to PW Transmit Defect 619 state, PE1's ability to transmit user traffic to CE2 is impacted. 620 As a result, PE1 needs to notify CE1 about this problem which has 621 been detected by PE1. 623 Upon entry to the PW Transmit Defect state, the following MUST be 624 done: 626 - If PE1 is configured with a down MEP associated with the local AC 627 and CCM transmission is enabled, the MEP associated with the AC 628 MUST set the RDI bit in transmitted CCM frames or send status TLV 629 with interface down to the peer MEP in the client domain (e.g., on 630 CE1). 632 - If PE1 is configured to run E-LMI [MEF16] with CE1 and E-LMI is 633 used for fault notification, PE1 MUST transmit E-LMI asynchronous 634 STATUS message with report type Single EVC Asynchronous Status 635 indicating that PW is Not Active. 637 - If the PW failure was detected by PE1 without receiving reverse 638 defect notification from PE2, PE1 MUST assume PE2 has no knowledge 639 of the defect and MUST notify PE2 by sending FDI." 641 6.4. PW Transmit Defect Exit Procedures 643 When the PW status transitions from PW Transmit Defect state to 644 working, PE1's ability to transmit user traffic to CE2 is restored. 645 As a result, PE1 needs to cease defect notifications to CE1 and 646 perform the following: 648 - If PE1 is configured with a down MEP associated with the local AC 649 and CCM transmission is enabled, the MEP associated with the AC 650 MUST clear the RDI bit in the transmitted CCM frames to the peer 651 MEP or send status TLV with interface up to the peer MEP in the 652 client domain (e.g., on CE1). 654 - If PE1 is configured to run E-LMI [MEF16] with CE1, PE1 MUST 655 transmit E-LMI asynchronous STATUS message with report type Single 656 EVC Asynchronous Status indicating that PW is Active. 658 - PE1 MUST clear the FDI to PE2, if applicable. 660 6.5. AC Receive Defect Entry Procedures 662 When AC status transitions from working to AC Receive Defect state, 663 PE1's ability to receive user traffic from CE1 is impacted. As a 664 result, PE1 needs to notify PE2 and CE1 about this problem. 666 If the AC receive defect is detected by PE1, it MUST notify PE2 in 667 the form of a forward defect notification. 669 When NS OAM is not supported on PE1, and for PW over MPLS PSN or 670 MPLS-IP PSN, forward defect notification is done via either PW 671 Status message indicating a forward defect or via VCCV-BFD 672 diagnostic code of forward defect if VCCV CV type of 0x08/0x20 had 673 been negotiated. 675 When Native Service OAM mechanism is supported on PE1, it can also 676 use the NS OAM notification as specified in Section 4.1. 678 In addition to the above actions, PE1 MUST perform the following: 680 - If PE1 is configured with a down MEP associated with the local AC 681 and CCM transmission is enabled, the MEP associated with the AC 682 MUST set the RDI bit in transmitted CCM frames. 684 6.6. AC Receive Defect Exit Procedures 686 When AC status transitions from AC Receive Defect to working, PE1's 687 ability to receive user traffic from CE1 is restored. As a result, 688 PE1 needs to cease defect notifications to PE2 and CE1 and perform 689 the following: 691 - When NS OAM is not supported on PE1 and for PW over MPLS PSN or 692 MPLS-IP PSN, forward defect notification is cleared via PW Status 693 message indicating a working state; or via VCCV-BFD diagnostic code 694 if VCCV CV type of 0x08 or 0x20 had been negotiated. 696 - When Native Service OAM mechanism is supported on PE1, PE1 clears 697 the NS OAM notification as specified in Section 4.1. 699 - If PE1 is configured with a down MEP associated with the local AC 700 and CCM transmission is enabled, the MEP associated with the AC 701 MUST clear the RDI bit in transmitted CCM frames to the peer MEP in 702 the client domain (e.g., on CE1). 704 6.7. AC Transmit Defect Entry Procedures 706 When AC status transitions from working to AC Transmit Defect, 707 PE1's ability to transmit user traffic to CE1 is impacted. As a 708 result, PE1 needs to notify PE2 about this problem. 710 If the AC transmit defect is detected by PE1, it MUST notify PE2 in 711 the form of a reverse defect notification. 713 When NS OAM is not supported on PE1, in PW over MPLS PSN or MPLS-IP 714 PSN, reverse defect notification is either done via PW Status 715 message indicating a reverse defect; or via VCCV-BFD diagnostic 716 code of reverse defect if VCCV CV type of 0x08 or 0x20 had been 717 negotiated. 719 When Native Service OAM mechanism is supported on PE1, it can also 720 use the NS OAM notification as specified in Section 4.1. 722 6.8. AC Transmit Defect Exit Procedures 724 When AC status transitions from AC Transmit defect to working, 725 PE1's ability to transmit user traffic to CE1 is restored. As a 726 result, PE1 MUST clear reverse defect notification to PE2. 728 When NS OAM is not supported on PE1 and for PW over MPLS PSN or 729 MPLS-IP PSN, reverse defect notification is cleared via either a PW 730 Status message indicating a working state or via VCCV-BFD 731 diagnostic code if VCCV CV type of 0x08 or 0x20 had been 732 negotiated. 734 When Native Service OAM mechanism is supported on PE1, PE1 can 735 clear NS OAM notification as specified in Section 4.1. 737 7. Security Considerations 739 The OAM interworking mechanisms described in this document do not 740 change the security functions inherent in the actual messages. All 741 generic security considerations applicable to PW traffic specified 742 in Section 10 of [RFC3985] are applicable to NS OAM messages 743 transferred inside the PW. 745 Security considerations in Section 10 of [RFC5085] for VCCV apply 746 to the OAM messages thus transferred. Security considerations 747 applicable to the PWE3 control protocol of [RFC4447] Section 8.2 748 apply to OAM indications transferred using the LDP status message. 750 Since the mechanisms of this document enable propagation of OAM 751 messages and fault conditions between native service networks and 752 PSNs, continuity of the end-to-end service depends on a trust 753 relationship between the operators of these networks. Security 754 considerations for such scenarios are discussed in Section 7 of 755 [RFC5254]. 757 8. IANA Considerations 759 This document has no actions for IANA. 761 9. Acknowledgments 763 The authors are thankful to Samer Salam, Matthew Bocci and Yaakov 764 Stein for their valuable comments. 766 10. References 768 10.1. Normative References 770 [RFC6310] "Pseudowire (PW) Operations, Administration, and 771 Maintenance (OAM) Message Mapping", RFC 6310, July 2011. 773 [Y.1731] "OAM Functions and mechanisms for Ethernet based 774 networks", ITU-T Y.1731, May 2006. 776 [802.1ag] "Connectivity Fault Management", IEEE 802.1ag, December 777 2007. 779 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 780 Requirement Levels", BCP 14, RFC 2119, March 1997. 782 [RFC4447] "Pseudowire Setup and Maintenance using LDP", RFC4447, 783 April 2006. 785 [RFC5885] "Bidirectional Forwarding Detection (BFD) for the 786 Pseudowire Virtual Circuit Connectivity Verification (VCCV)", 787 RFC5885, June 2010. 789 [802.3] "CDMA/CD access method and physical layer specifications", 790 Clause 57 for Operations, Administration and Maintenance, 2005. 792 [MEF16] "Ethernet Local Management Interface", Metro Ethernet Forum 793 Technical Specification MEF16, January 2006. 795 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 796 Connectivity Verification (VCCV): A Control Channel for 797 Pseudowires", RFC 5085, December 2007. 799 10.2. Informative References 801 [RFC3985] "Pseudo Wire Emulation Edge-to-Edge(PWE3) Architecture", 802 RFC 3985, April 2005. 804 [RFC5659] "An Architecture for Multi-Segment Pseudo Wire Emulation 805 Edge-to-Edge", RFC5659, October 2009. 807 [RFC5254] Bitar, N., Bocci, M., and L. Martini, "Requirements for 808 Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", RFC 5254, 809 October 2008. 811 11. Appendix A: Ethernet Native Service Management 813 Ethernet OAM mechanisms are broadly classified into two categories: 814 Fault Management (FM) and Performance Monitoring (PM). ITU-T Y.1731 815 provides coverage for both FM and PM while IEEE 802.1ag provides 816 coverage for a sub-set of FM functions. 818 Ethernet OAM also introduces the concept of Maintenance Entity (ME) 819 which is used to identify the entity that needs to be managed. An 820 ME is inherently a point-to-point association. However, in case of 821 a multipoint association, Maintenance Entity Group (MEG) consisting 822 of different MEs is used. IEEE 802.1 uses the concept of 823 Maintenance Association (MA) which is used to identify both point- 824 to-point and multipoint associations. Each MEG/MA consists of MEG 825 End Points (MEPs) which are responsible for originating OAM frames. 826 In between the MEPs, there can also be MEG Intermediate Points 827 (MIPs) which do not originate OAM frames however do respond to OAM 828 frames from MEPs. 830 Ethernet OAM allows for hierarchical maintenance entities to allow 831 for simultaneous end-to-end and segment monitoring. This is 832 achieved by having a provision of up to 8 MEG Levels (MD Levels) 833 where each MEP or MIP is associated with a specific MEG Level. 835 It is important to note that the common set of FM mechanisms 836 between IEEE 802.1ag and ITU-T Y.1731 are completely compatible. 838 The common FM mechanisms include: 840 1) Continuity Check Messages (CCM) 842 2) Loopback Message (LBM) and Loopback Reply (LBR) 844 3) Linktrace Message (LTM) and Linktrace Reply (LTR) 846 CCM messages are used for fault detection including misconnections 847 and mis-configurations. Typically CCM messages are sent as 848 multicast frames or Unicast frames and also allow RDI 849 notifications. LBM/LBR are used to perform fault verification, 850 while also allow for MTU verification and CIR/EIR measurements. 851 LTM/LTR can be used for discovering the path traversed between a 852 MEP and another target MIP/MEP in the same MEG. LTM/LTR also allow 853 for fault localization. 855 In addition, ITU-T Y.1731 also specifies the following FM 856 functions: 858 4) Alarm Indication Signal (AIS) 860 AIS allows for fault notification to downstream and upstream nodes. 862 Further, ITU-T Y.1731 also specifies the following PM functions: 864 5) Loss Measurement Message (LMM) and Reply (LMR) 866 6) Delay Measurement Message (DMN) and Reply (DMR) 868 7) 1-way Delay Message (1DM) 870 While LMM/LMR is used to measure Frame Loss Ratio (FLR), DMM/DMR is 871 used to measure single-ended (aka two-way) Frame Delay (FD) and 872 Frame Delay Variation (FDV, also known as Jitter). 1DM can be used 873 for dual-ended (aka one-way) FD and FDV measurements. 875 Authors' Addresses 877 Dinesh Mohan 878 Nortel 879 3500 Carling Ave 880 Ottawa, ON K2H8E9 881 Email: dinmohan@hotmail.com 883 Nabil Bitar 884 Verizon 885 60 Sylvan Road 886 Waltham, MA 02145 887 Email: nabil.n.bitar@verizon.com 889 Ali Sajassi 890 Cisco 891 170 West Tasman Drive 892 San Jose, CA 95134, US 893 Email: sajassi@cisco.com 895 Simon Delord 896 Alcatel-Lucent 897 215 Spring Street 898 Melbourne, Australia 899 E-mail: simon.delord@gmail.com 901 Philippe Niger 902 France Telecom 903 2 av. Pierre Marzin 904 22300 LANNION, France 905 E-mail: philippe.niger@francetelecom.com 907 Ray Qiu 908 Juniper 909 1194 North Mathilda Avenue 910 Sunnyvale, CA 94089, US 911 Email: rqiu@juniper.net