idnits 2.17.1 draft-ietf-pwe3-mpls-eth-oam-iwk-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 1) being 60 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 15, 2013) is 3931 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) == Missing Reference: 'RFC4023' is mentioned on line 332, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'MEF16' ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) 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: January 2014 Nabil Bitar (Ed.) 6 Verizon 8 Ali Sajassi (Ed.) 9 Cisco 11 Simon Delord 12 Alcatel-Lucent 14 Philipe Niger 15 France Telecom 17 Ray Qiu 18 Juniper 20 July 15, 2013 22 MPLS and Ethernet OAM Interworking 23 draft-ietf-pwe3-mpls-eth-oam-iwk-08.txt 25 Abstract 27 This document specifies the mapping of defect states between 28 Ethernet Attachment Circuits (ACs) and associated Ethernet 29 Pseudowires (PWs) connected in accordance to the PWE3 architecture 30 to realize an end-to-end emulated Ethernet service. It standardizes 31 the behavior of Provider Edges (PEs) with respect to Ethernet PW 32 and AC defects. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet 40 Engineering Task Force (IETF). Note that other groups may also 41 distribute working documents as Internet-Drafts. The list of 42 current Internet-Drafts is at 43 http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six 46 months and may be updated, replaced, or obsoleted by other 47 documents at any time. It is inappropriate to use Internet- 48 Drafts as reference material or to cite them other than as "work 49 in progress." 51 This Internet-Draft will expire on January 14, 2014. 53 Copyright Notice 55 Copyright (c) 2013 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with 63 respect to this document. Code Components extracted from this 64 document must include Simplified BSD License text as described in 65 Section 4.e of the Trust Legal Provisions and are provided without 66 warranty as described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction............................................. 3 71 1.1. Specification of Requirements....................... 3 72 2. Overview................................................. 3 73 2.1. Reference Model and Defect Locations................ 5 74 2.2. Abstract Defect States.............................. 5 75 3. Abbreviations and Terminology............................ 7 76 3.1. Abbreviations....................................... 7 77 3.2. Terminology......................................... 7 78 4. PW Status and Defects.................................... 8 79 4.1. Use of Native Service (NS) Notification............. 8 80 4.2. Use of PW Status Notification for MPLS PSNs......... 9 81 4.3. Use of BFD Diagnostic Codes......................... 9 82 4.4. PW Defect States Entry and Exit Criteria........... 10 83 4.4.1. PW Receive Defect State Entry and Exit........ 10 84 4.4.2. PW Transmit Defect State Entry and Exit....... 10 85 5. Ethernet AC Defect States Entry and Exit Criteria11..... 11 86 5.1. AC Receive Defect State Entry and Exit............. 11 87 5.2. AC Transmit Defect State Entry and Exit............ 12 88 6. Ethernet AC and PW Defect States Interworking........... 12 89 6.1. PW Receive Defect Entry Procedures................. 12 90 6.2. PW Receive Defect Exit Procedures.................. 13 91 6.3. PW Transmit Defect Entry Procedures................ 14 92 6.4. PW Transmit Defect Exit Procedures................. 15 93 6.5. AC Receive Defect Entry Procedures................. 15 94 6.6. AC Receive Defect Exit Procedures.................. 16 95 6.7. AC Transmit Defect Entry Procedures................ 16 96 6.8. AC Transmit Defect Exit Procedures................. 16 97 7. Security Considerations................................. 17 98 8. IANA Considerations..................................... 17 99 9. Acknowledgments......................................... 17 100 10. References............................................. 17 101 10.1. Normative References...............................17 102 10.2. Informative References.............................18 103 11. Appendix A: Ethernet Native Service Management......... 19 105 1. Introduction 107 RFC 6310 [RFC6310] specifies the mapping and notification of defect 108 states between a pseudowire (PW) and the Attachment Circuit (AC) of 109 the end-to-end emulated service. It standardizes the behavior of 110 Provider Edges (PEs) with respect to PW and AC defects for a number 111 of technologies (e.g., Asynchronous Transfer Mode (ATM), Frame 112 Relay (FR)) emulated over PWs in MPLS and MPLS/IP Packet Switched 113 Networks (PSNs). However, RFC 6310 does not describe this function 114 for the Ethernet PW service owing to its unique characteristics. 116 This document specifies the mapping of defect states between ACs 117 and associated Ethernet PWs connected in accordance to the PWE3 118 architecture [RFC3985] to realize an end-to-end emulated Ethernet 119 service. This document augments the mapping of defect states 120 between a PW and associated AC of the end-to-end emulated service 121 in RFC 6310. Similar to RFC 6310, the intent of this document is to 122 standardize the behavior of PEs with respect to failures on 123 Ethernet ACs and PWs, so that there is no ambiguity about the 124 alarms generated and consequent actions undertaken by PEs in 125 response to specific failure conditions. 127 1.1. Specification of Requirements 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 131 this document are to be interpreted as described in [RFC2119]. 133 2. Overview 135 There are a number of Operations, Administration and Maintenance 136 (OAM) technologies defined for Ethernet, providing various 137 functionalities. This document covers the following Ethernet OAM 138 mechanisms and their interworking with PW OAM mechanisms: 140 - Ethernet Link OAM [802.3] 141 - Ethernet Local Management Interface {E-LMI} [MEF16] 142 - Ethernet Continuity Check (CC) [802.1ag][Y.1731] 143 - Ethernet Alarm Indication Signaling (AIS) and Remote Defect 144 Indication (RDI) [Y.1731] 146 Ethernet Link OAM [802.3] allows some Link defect states to be 147 detected and communicated across an Ethernet Link. When an Ethernet 148 AC is an Ethernet physical port, there may be some application of 149 Ethernet Link OAM [802.3]. Further, E-LMI [MEF16] also allows for 150 some Ethernet Virtual Circuit (EVC) defect states to be 151 communicated across an Ethernet User Network Interface (UNI) where 152 Ethernet UNI constitutes a single hop Ethernet Link (i.e., without 153 any IEEE 802.1Q/.1ad compliant bridges in between). There may be 154 some application of E-LMI [MEF16] for failure notification across 155 single hop Ethernet AC in certain deployments that specifically do 156 not support IEEE 802.1ag [802.1ag] and/or ITU-T Y.1731 [Y.1731], 157 simply referred to as 802.1ag and Y.1731, respectively, in this 158 document. Y.1731 and 802.1ag based mechanisms are applicable in all 159 types of Ethernet ACs. Ethernet Link OAM and E-LMI are optional and 160 their applicability is called out, where applicable. 162 Native Service (NS) OAM may be transported transparently over the 163 corresponding PW as user data. This is referred to as "the single 164 emulated OAM loop" mode per [RFC6310]. For Ethernet, as an example, 165 802.1ag continuity check messages (CCMs) between two Maintenance 166 Group End Points (MEPs) can be transported transparently as user 167 data over the corresponding PW. At MEP locations, service failure 168 is detected when CCMs are not received over an interval that is 3.5 169 times the local CCM transmission interval. This is one of the 170 failure conditions detected via continuity check. MEP peers can 171 exist between customer equipment (CE) pairs (MEPs of a given 172 Maintenance Entity Group (MEG) reside on the CEs), PE pairs (the 173 MEPs of a given MEG reside on the PEs), or between the CE and PE 174 (the MEPs of a given MEG reside on the PE and CE), as long as the 175 MEG level nesting rules are maintained. It should be noted that 176 Ethernet allows the definition of up to 8 MEG levels, each 177 compromising of MEPs (Down MEPs and Up MEPs) and Maintenance Group 178 Intermediate Points (MIPs). These levels can be nested or touching. 179 MEPs and MIPs generate and process messages in the same MEG level. 180 Thus, whenever in this document we refer to messages sent by a MEP 181 or a MIP to a peer MEP or MIP, these MEPs and MIPs are in the same 182 MEG level. 184 When interworking two networking domains, such as native Ethernet 185 and PWs to provide an end-to-end emulated service, there is need to 186 identify the failure domain and location even when a PE supports 187 both the NS OAM mechanisms and the PW OAM mechanisms. In addition, 188 scalability constraints may not allow running proactive monitoring, 189 such as CCMs with transmission enabled, at a PE to detect the 190 failure of an EVC across the PW domain. Thus, network-driven alarms 191 generated upon failure detection in the NS or PW domain and their 192 mappings to the other domain are needed. There are also cases where 193 a PE MAY not be able to process NS OAM messages received on the PW 194 even when such messages are defined, as in Ethernet case, 195 necessitating the need for fault notification message mapping 196 between the PW domain and the NS domain. 198 For Multi-Segment PWs (MS-PWs) [RFC5659], Switching PEs (S-PEs) are 199 not aware of the NS. Thus, failure detection and notification at S- 200 PEs will be based on PW OAM mechanisms. Mapping between PW OAM and 201 NS OAM will be required at the Terminating PEs (T-PEs) to propagate 202 the failure notification to the EVC endpoints. 204 2.1. Reference Model and Defect Locations 206 Figure 1 is the same as used in [RFC6310] and is reproduced in this 207 document as a reference to highlight defect locations. 209 ACs PSN tunnel ACs 210 +----+ +----+ 211 +----+ | PE1|==================| PE2| +----+ 212 | |---(a)---(b)..(c)......PW1..(d)..(e)..(f)---(g)---| | 213 | CE1| (N1) | | | | (N2) |CE2 | 214 | |----------|............PW2.............|----------| | 215 +----+ | |==================| | +----+ 216 ^ +----+ +----+ ^ 217 | Provider Edge 1 Provider Edge 2 | 218 | | 219 |<-------------- Emulated Service ---------------->| 221 Customer Customer 222 Edge 1 Edge 2 224 Figure 1: PWE3 Network Defect Locations 226 2.2. Abstract Defect States 228 Abstract Defect States are also introduced in [RFC6310]. This 229 document uses the same conventions, as shown in Figure 2, from 230 [RFC6310]. It may be noted however that CE devices, shown in Figure 231 2, do not necessarily have to be end customer devices. These are 232 essentially devices in client network segments that are connecting 233 to the Packet Switched Network (PSN) for the emulated services. 235 +-----+ 236 ----AC receive ----->| |-----PW transmit----> 237 CE1 | PE1 | PE2/CE2 238 <---AC transmit------| |<----PW receive----- 239 +-----+ 240 (arrows indicate direction of user traffic impacted by a defect) 242 Figure 2: Transmit and Receive Defect States and Notifications 244 The procedures outlined in this document define the entry and exit 245 criteria for each of the four defect states with respect to 246 Ethernet ACs and corresponding PWs, and the consequent actions that 247 PE1 MUST support to properly interwork these defect states and 248 corresponding notification messages between the PW domain and the 249 Native Service (NS) domain. Receive Defect state SHOULD have 250 precedence over Transmit Defect state in terms of handling, when 251 both transmit and receive defect states are identified 252 simultaneously. 254 Following is a summary of the defect states from the viewpoint of 255 PE1 in Figure 2: 257 - A PW receive defect at PE1 impacts PE1 ability to receive traffic 258 on the PW. PW defect state entry and exit criteria are described in 259 section 4.4.1. 261 - A PW transmit defect at PE1 impacts PE1 ability to send user 262 traffic toward CE2. PE1 MAY be notified of a PW transmit defect via 263 Reverse Defect Indication from PE2, which could point to problems 264 associated with PE2's inability to receive traffic on the PW or 265 PE2's inability to transmit traffic on its local AC. PW transmit 266 state defect entry and exit criteria are described in section 267 4.4.2. 269 - An AC receive defect at PE1 impacts PE1 ability to receive user 270 traffic from the Client domain attached to PE1 via that AC. AC 271 receive state entry and exit criteria are described in section 5.1 273 - An AC transmit defect at PE1 impacts PE1 ability to send user 274 traffic on the local AC. AC transmit defect state entry and exit 275 criteria are described in section 5.2. 277 3. Abbreviations and Terminology 279 3.1. Abbreviations 281 AIS Alarm Indication Signal 282 AC Attachment Circuit 283 BFD Bidirectional Forwarding Detection 284 CC Continuity Check 285 CCM Continuity Check Message 286 CE Customer Equipment 287 CV Connectivity Verification 288 E-LMI Ethernet Local Management Interface 289 EVC Ethernet Virtual Circuit 290 LDP Label Distribution Protocol 291 LoS Loss of Signal 292 MA Maintenance Association 293 MD Maintenance Domain 294 ME Maintenance Entity 295 MEG Maintenance Entity Group 296 MEP MEG End Point 297 MIP MEG Intermediate Point 298 MPLS Multiprotocol Label Switching 299 MS-PW Multi-Segment Pseudowire 300 NS Native Service 301 OAM Operations, Administration, and Maintenance 302 PE Provider Edge 303 PSN Packet Switched Network 304 PW Pseudowire 305 RDI means Remote Defect Indication when used in the context of 306 CCM 307 RDI Reverse Defect Indication when used to semantically refer 308 to defect indication in the reverse direction 309 S-PE Switching Provider Edge 310 TLV Type Length Value 311 T-PE Terminating Provider Edge 313 3.2. Terminology 315 This document uses the following terms with corresponding 316 definitions: 318 - MEG Level: identifies a value in the range of 0-7 associated 319 with Ethernet OAM frame. MEG Level identifies the span of the 320 Ethernet OAM frame. 322 - MEP: MEG End Point is responsible for origination and 323 termination of OAM frames for a given MEG. 325 - MIP: MEG Intermediate Point is located between peer 326 MEPs and can process OAM frames but does not initiate them. 328 - MPLS PSN: A PSN that makes use of MPLS label Switched Paths 329 [RFC3031] as the tunneling technology to forward PW packets. 331 -MPLS/IP PSN: A PSN that makes use of MPLS-in-IP tunneling 332 [RFC4023] to tunnel MPLS-labeled PW packets over IP tunnels. 334 Further, this document also uses the terminology and conventions 335 used in [RFC6310]. 337 4. PW Status and Defects 339 [RFC6310] introduces a range of defects that impact PW status. All 340 these defect conditions are applicable for Ethernet PWs. 342 Similarly, there are different mechanisms described in [RFC6310] to 343 detect PW defects, depending on the PSN type (e.g., MPLS PSN, 344 MPLS/IP PSN). Any of these mechanisms can be used when monitoring 345 the state of Ethernet PWs. [RFC6310] also discusses the 346 applicability of these failure detection mechanisms. 348 4.1. Use of Native Service (NS) Notification 350 When two PEs terminate am Ethernet PW with associated MEPs, each PE 351 can use native service (NS) OAM capabilities for failure 352 notifications by transmitting appropriate NS OAM messages over the 353 corresponding PW to the remote PE. Options include: 355 - Sending of AIS frames from the local MEP to the MEP on the 356 remote PE when the MEP needs to convey PE receive defects, and when 357 CCM transmission is disabled. 359 - Suspension of CCM frames transmission from the local MEP to 360 the peer MEP on the remote PE to convey PE receive defects, when 361 CCM transmission is enabled. 363 - Setting the RDI bit in transmitted CCM frames, when loss of 364 CCMs from the peer MEP is detected or the PE needs to convey PW 365 reverse defects. 367 Similarly, when the defect conditions are cleared, a PE can take 368 one of the following actions, depending on the mechanism that was 369 used for failure notification, to clear the defect sate on the peer 370 PE: 371 - Stopping AIS frame transmission from the local MEP to the 372 MEP on the remote PE to clear PW receive defects. 374 - Resuming CCM frames transmission from the local MEP to the 375 peer MEP on the remote PE to clear PW forward defects notification, 376 when CCM transmission is enabled. 378 - Clearing the RDI bit in transmitted CCM frames, to clear PW 379 transmit defects notification, when CCM transmission is enabled. 381 4.2. Use of PW Status Notification for MPLS PSNs 383 RFC 4447 [RFC4447] specifies that for PWs that have been set up 384 using the Label Distribution Protocol (LDP), the default mechanism 385 to signal status and defects for ACs and PWs is the LDP Status 386 Notification message. That is known as the "coupled loop mode". For 387 PWs established over an MPLS or MPLS/IP PSN using other mechanisms 388 (e.g. static configuration), inband signaling using VCCV-BFD 389 [RFC5885] SHOULD be used to convey AC and PW status and defects. 390 Alternatively, the mechanisms defined in [RFC6478] MAY be used. 392 [RFC6310] identifies the following PW defect status codepoints: 394 - Forward defect: corresponds to a logical OR of local AC 395 (ingress) Receive fault, local PSN-facing PW (egress) transmit 396 fault, and PW not forwarding fault. 398 - Reverse defect: corresponds to a logical OR of local AC 399 (egress) transmit fault and local PW PSN-facing (ingress) 400 receive fault. 402 There are also scenarios where a PE carries out PW label withdrawal 403 instead of PW status notification. These include administrative 404 disablement of the PW or loss of Target LDP session with the peer 405 PE. 407 4.3. Use of BFD Diagnostic Codes 409 When using VCCV, the control channel (CC) type and Connectivity 410 Verification (CV) Type are agreed on between the peer PEs using the 411 VCC parameter field signaled as a sub-TLV of the interface 412 parameters TLV when using FEC 129 and the interface parameter sub- 413 TLV when using FEC 128 [RFC5085]. 415 As defined in [RFC6310], when CV type of 0x04 or 0x10 is used to 416 indicate that BFD is used for PW fault detection only, PW defect is 417 detected via the BFD session while other defects, such as AC defect 418 or PE internal defects preventing it from forwarding traffic, are 419 communicated via LDP Status notification message in MPLS and 420 MPLS/IP PSNs or other mechanisms in L2TP-IP PSN. 422 Similarly, when CV type of 0x08 or 0x20 is used to indicate that 423 BFD is used for both PW fault detection and AC/PW Fault 424 Notification, all defects are signaled via BFD. 426 4.4. PW Defect States Entry and Exit Criteria 428 4.4.1. PW Receive Defect State Entry and Exit 430 As described in [RFC6310] section 6.2.1, PE1 will enter the PW 431 receive defect state if one or more of the following occurs: 433 - It receives a forward defect indication (FDI) from PE2 434 indicating either a receive defect on the remote AC or that PE2 435 detected or was notified of downstream PW fault. 437 - It detects loss of connectivity on the PSN tunnel upstream of 438 PE1, which affects the traffic it receives from PE2. 440 - It detects a loss of PW connectivity through VCCV-BFD, VCCV- 441 PING, or NS OAM mechanisms (i.e., CC) when enabled, which affects 442 the traffic it receives from PE2. 444 Note that if the PW LDP control session between the PEs fails, the 445 PW is torn down and needs to be re-established. However, the 446 consequent actions towards the ACs are the same as if the PW 447 entered the receive defect state. 449 PE1 will exit the PW receive defect state when the following 450 conditions are met. Note that this may result in a transition to 451 the PW operational state or the PW transmit defect state. 453 - All previously detected defects have disappeared 454 - PE2 cleared the FDI, if applicable 456 4.4.2. PW Transmit Defect State Entry and Exit 458 PE1 will enter the PW transmit defect state if the following 459 conditions occur: 461 - It receives a Reverse Defect Indication (RDI) from PE2 462 indicating either a transmit fault on the remote AC or that PE2 463 detected or was notified of an upstream PW fault. 465 - It is not already in the PW receive defect state. 467 PE1 will exit the transmit defect state if it receives an OAM 468 message from PE2 clearing the RDI, or it has entered the PW 469 receive defect state. 471 5. Ethernet AC Defect States Entry and Exit Criteria 473 5.1. AC Receive Defect State Entry and Exit 475 PE1 enters the AC Receive Defect state if any of the following 476 conditions is met: 478 - It detects or is notified of a physical layer fault on the 479 Ethernet interface. Ethernet link failure can be detected based on 480 loss of signal (LoS) or via Ethernet Link OAM [802.3] critical link 481 event notifications generated at an upstream node CE1 with "Dying 482 Gasp" or "Critical Event" indication, or via a client Signal Fail 483 message [Y.1731]. 485 - A MEP associated with the local AC receives an Ethernet AIS frame 486 from CE1. 488 - A MEP associated with the local AC does not receive CCM frames 489 from the peer MEP in the client domain (e.g. CE1) within an 490 interval equal to 3.5 times the CCM transmission period configured 491 for the MEP. This is the case when CCM transmission is enabled. 493 - A CCM with interface status TLV indicating interface down. Other 494 CCM interface status TLVs will not be used to indicate failure or 495 recovery from failure. 497 It should be noted when a MEP at a PE or a CE receives a CCM with 498 the wrong MEG ID, MEP ID, or MEP level, the receiving PE or CE 499 SHOULD treat such an event as an AC receive defect. In any case, if 500 such events persist for 3.5 times the MEP local CCM transmission 501 time, loss of continuity will be declared at the receiving end. 503 PE1 exits the AC Receive Defect state if all of the conditions that 504 resulted in entering the defect state are cleared. This includes 505 all of the following conditions: 507 - Any physical layer fault on the Ethernet interface, if detected 508 or notified previously is removed (e.g., loss of signal (LoS) 509 cleared, or Ethernet Link OAM [802.3] critical link event 510 notifications with "Dying Gasp" or "Critical Event" indication 511 cleared at an upstream node CE1). 513 - A MEP associated with the local AC does not receive any Ethernet 514 AIS frame within a period indicated by previously received AIS, if 515 AIS resulted in entering the defect state. 517 - A MEP associated with the local AC and configured with CCM 518 enabled receives a configured number (e.g., 3 or more) of 519 consecutive CCM frames from the peer MEP on CE1 within an interval 520 equal to a multiple (3.5) of the CCM transmission period configured 521 for the MEP. 523 - CCM indicates interface status up. 525 5.2. AC Transmit Defect State Entry and Exit 527 PE1 enters the AC Transmit Defect state if any of the following 528 conditions is met: 530 - It detects or is notified of a physical layer fault on the 531 Ethernet interface where the AC is configured (e.g., via loss of 532 signal (LoS) or Ethernet Link OAM [802.3] critical link event 533 notifications generated at an upstream node CE1 with "Link Fault" 534 indication). 536 - A MEP configured with CCM transmission enabled and associated 537 with the local AC receives a CCM frame, with its RDI (Remote Defect 538 Indication) bit set, from the peer MEP in the client domain (e.g., 539 CE1). 541 PE1 exits the AC Transmit Defect state if all of the conditions 542 that resulted in entering the defect state are cleared. This 543 includes all of the following conditions: 545 - Any physical layer fault on the Ethernet interface, if detected 546 or notified previously is removed (e.g., LOS cleared, Ethernet Link 547 OAM [802.3] critical link event notifications with "Link Fault" 548 indication cleared at an upstream node CE1). 550 - A MEP configured with CCM transmission enabled and associated 551 with the local AC does not receive a CCM frame with RDI bit set, 552 having received a previous CCM frame with RDI bit set from the peer 553 MEP in the client domain (e.g. CE1). 555 6. Ethernet AC and PW Defect States Interworking 557 6.1. PW Receive Defect Entry Procedures 559 When the PW status on PE1 transitions from working to PW Receive 560 Defect state, PE1's ability to receive user traffic from CE2 is 561 impacted. As a result, PE1 needs to notify CE1 about this problem. 563 Upon entry to the PW Receive Defect state, the following MUST be 564 done: 566 - If PE1 is configured with a down MEP associated with the local AC 567 and CCM transmission is not enabled, the MEP associated with the AC 568 MUST transmit AIS frames periodically to the peer MEP in the client 569 domain (e.g., on CE1) based on configured AIS transmission period. 571 - If PE1 is configured with a down MEP associated with the local AC 572 and CCM transmission is enabled, and the MEP associated with the AC 573 is configured to support Interface Status TLV in CCM messages, the 574 MEP associated with the AC MUST transmit CCM frames with Interface 575 Status TLV as being down to the peer MEP in the client domain 576 (e.g., on CE1). 578 - If PE1 is configured with a down MEP associated with the local AC 579 and CCM transmission is enabled, and the MEP associated with the AC 580 is configured to not support Interface Status TLV in CCM messages, 581 the MEP associated with the AC MUST stop transmitting CCM frames to 582 the peer MEP in the client domain (e.g., on CE1). 584 - If PE1 is configured to run E-LMI [MEF16] with CE1 and if E-LMI 585 is used for failure notification, PE1 MUST transmit E-LMI 586 asynchronous STATUS message with report type Single EVC 587 Asynchronous Status indicating that PW is Not Active. 589 Further, when PE1 enters the Receive Defect state, it MUST assume 590 that PE2 has no knowledge of the defect and MUST send reverse 591 defect failure notification to PE2. For MPLS PSN or MPLS/IP PSN, 592 this is done via either a PW Status notification message indicating 593 a reverse defect; or via VCCV-BFD diagnostic code of reverse defect 594 if VCCV CV type of 0x08 or 0x20 had been negotiated. When Native 595 Service OAM mechanism is supported on PE1, it can also use the NS 596 OAM notification as specified in Section 4.1. 598 If PW receive defect is entered as a result of a forward defect 599 notification from PE2 or via loss of control adjacency, no 600 additional action is needed since PE2 is expected to be aware of 601 the defect. 603 6.2. PW Receive Defect Exit Procedures 605 When the PW status transitions from PW Receive Defect state to 606 working, PE1's ability to receive user traffic from CE2 is 607 restored. As a result, PE1 needs to cease defect notification to 608 CE1 by performing the following: 610 - If PE1 is configured with a down MEP associated with the local AC 611 and CCM transmission is not enabled, the MEP associated with the AC 612 MUST stop transmitting AIS frames towards the peer MEP in the 613 client domain (e.g., on CE1). 615 - If PE1 is configured with a down MEP associated with the local AC 616 and CCM transmission is enabled, and the MEP associated with the AC 617 is configured to support Interface Status TLV in CCM messages, the 618 MEP associated with the AC MUST transmit CCM frames with Interface 619 Status TLV as being Up to the peer MEP in the client domain (e.g., 620 on CE1). 622 - If PE1 is configured with a down MEP associated with the local AC 623 and CCM transmission is enabled, and the MEP associated with the AC 624 is configured to not support Interface Status TLV in CCM messages, 625 the MEP associated with the AC MUST resume transmitting CCM frames 626 to the peer MEP in the client domain (e.g., on CE1). 628 - If PE1 is configured to run E-LMI [MEF16] with CE1 and E-LMI is 629 used for fault notification, PE1 MUST transmit E-LMI asynchronous 630 STATUS message with report type Single EVC Asynchronous Status 631 indicating that PW is Active. 633 Further, if the PW receive defect was explicitly detected by PE1, 634 it MUST now notify PE2 about clearing of Receive Defect state by 635 clearing reverse defect notification. For PWs over MPLS PSN or 636 MPLS/IP PSN, this is either done via PW Status message indicating 637 working; or via VCCV-BFD diagnostic code if VCCV CV type of 638 0x08/0x20 had been negotiated. When Native Service OAM mechanism is 639 supported on PE, it can also clear the NS OAM notification as 640 specified in Section 4.1. 642 If PW receive defect was established via notification from PE2 or 643 via loss of control adjacency, no additional action is needed, 644 since PE2 is expected to be aware of the defect clearing. 646 6.3. PW Transmit Defect Entry Procedures 648 When the PW status transitions from working to PW Transmit Defect 649 state, PE1's ability to transmit user traffic to CE2 is impacted. 650 As a result, PE1 needs to notify CE1 about this problem which has 651 been detected by PE1. 653 Upon entry to the PW Transmit Defect state, the following MUST be 654 done: 656 - If PE1 is configured with a down MEP associated with the local AC 657 and CCM transmission is enabled, the MEP associated with the AC 658 MUST set the RDI bit in transmitted CCM frames or send status TLV 659 with interface down to the peer MEP in the client domain (e.g., on 660 CE1). 662 - If PE1 is configured to run E-LMI [MEF16] with CE1 and E-LMI is 663 used for fault notification, PE1 MUST transmit E-LMI asynchronous 664 STATUS message with report type Single EVC Asynchronous Status 665 indicating that PW is Not Active. 667 - If the PW failure was detected by PE1 without receiving reverse 668 defect notification from PE2, PE1 MUST assume PE2 has no knowledge 669 of the defect and MUST notify PE2 by sending FDI." 671 6.4. PW Transmit Defect Exit Procedures 673 When the PW status transitions from PW Transmit Defect state to 674 working, PE1's ability to transmit user traffic to CE2 is restored. 675 As a result, PE1 needs to cease defect notifications to CE1 and 676 perform the following: 678 - If PE1 is configured with a down MEP associated with the local AC 679 and CCM transmission is enabled, the MEP associated with the AC 680 MUST clear the RDI bit in the transmitted CCM frames to the peer 681 MEP or send status TLV with interface up to the peer MEP in the 682 client domain (e.g., on CE1). 684 - If PE1 is configured to run E-LMI [MEF16] with CE1, PE1 MUST 685 transmit E-LMI asynchronous STATUS message with report type Single 686 EVC Asynchronous Status indicating that PW is Active. 688 - PE1 MUST clear the FDI to PE2, if applicable. 690 6.5. AC Receive Defect Entry Procedures 692 When AC status transitions from working to AC Receive Defect state, 693 PE1's ability to receive user traffic from CE1 is impacted. As a 694 result, PE1 needs to notify PE2 and CE1 about this problem. 696 If the AC receive defect is detected by PE1, it MUST notify PE2 in 697 the form of a forward defect notification. 699 When NS OAM is not supported on PE1, and for PW over MPLS PSN or 700 MPLS/IP PSN, forward defect notification is done via either PW 701 Status message indicating a forward defect or via VCCV-BFD 702 diagnostic code of forward defect if VCCV CV type of 0x08/0x20 had 703 been negotiated. 705 When Native Service OAM mechanism is supported on PE1, it can also 706 use the NS OAM notification as specified in Section 4.1. 708 In addition to the above actions, PE1 MUST perform the following: 710 - If PE1 is configured with a down MEP associated with the local AC 711 and CCM transmission is enabled, the MEP associated with the AC 712 MUST set the RDI bit in transmitted CCM frames. 714 6.6. AC Receive Defect Exit Procedures 716 When AC status transitions from AC Receive Defect to working, PE1's 717 ability to receive user traffic from CE1 is restored. As a result, 718 PE1 needs to cease defect notifications to PE2 and CE1 and perform 719 the following: 721 - When NS OAM is not supported on PE1 and for PW over MPLS PSN or 722 MPLS/IP PSN, forward defect notification is cleared via PW Status 723 message indicating a working state; or via VCCV-BFD diagnostic code 724 if VCCV CV type of 0x08 or 0x20 had been negotiated. 726 - When Native Service OAM mechanism is supported on PE1, PE1 clears 727 the NS OAM notification as specified in Section 4.1. 729 - If PE1 is configured with a down MEP associated with the local AC 730 and CCM transmission is enabled, the MEP associated with the AC 731 MUST clear the RDI bit in transmitted CCM frames to the peer MEP in 732 the client domain (e.g., on CE1). 734 6.7. AC Transmit Defect Entry Procedures 736 When AC status transitions from working to AC Transmit Defect, 737 PE1's ability to transmit user traffic to CE1 is impacted. As a 738 result, PE1 needs to notify PE2 about this problem. 740 If the AC transmit defect is detected by PE1, it MUST notify PE2 in 741 the form of a reverse defect notification. 743 When NS OAM is not supported on PE1, in PW over MPLS PSN or MPLS/IP 744 PSN, reverse defect notification is either done via PW Status 745 message indicating a reverse defect; or via VCCV-BFD diagnostic 746 code of reverse defect if VCCV CV type of 0x08 or 0x20 had been 747 negotiated. 749 When Native Service OAM mechanism is supported on PE1, it can also 750 use the NS OAM notification as specified in Section 4.1. 752 6.8. AC Transmit Defect Exit Procedures 754 When AC status transitions from AC Transmit defect to working, 755 PE1's ability to transmit user traffic to CE1 is restored. As a 756 result, PE1 MUST clear reverse defect notification to PE2. 758 When NS OAM is not supported on PE1 and for PW over MPLS PSN or 759 MPLS/IP PSN, reverse defect notification is cleared via either a PW 760 Status message indicating a working state or via VCCV-BFD 761 diagnostic code if VCCV CV type of 0x08 or 0x20 had been 762 negotiated. 764 When Native Service OAM mechanism is supported on PE1, PE1 can 765 clear NS OAM notification as specified in Section 4.1. 767 7. Security Considerations 769 The OAM interworking mechanisms described in this document do not 770 change the security functions inherent in the actual messages. All 771 generic security considerations applicable to PW traffic specified 772 in Section 10 of [RFC3985] are applicable to NS OAM messages 773 transferred inside the PW. 775 Security considerations in Section 10 of [RFC5085] for VCCV apply 776 to the OAM messages thus transferred. Security considerations 777 applicable to the PWE3 control protocol of [RFC4447] Section 8.2 778 apply to OAM indications transferred using the LDP status message. 780 Since the mechanisms of this document enable propagation of OAM 781 messages and fault conditions between native service networks and 782 PSNs, continuity of the end-to-end service depends on a trust 783 relationship between the operators of these networks. Security 784 considerations for such scenarios are discussed in Section 7 of 785 [RFC5254]. 787 8. IANA Considerations 789 This document has no actions for IANA. 791 9. Acknowledgments 793 The authors are thankful to Samer Salam, Matthew Bocci, Yaakov 794 Stein, David Black, Lizhong Jin, Greg Mirsky, Huub van Helvoort, 795 and Adrian Farrel for their valuable input and comments. 797 10. References 799 10.1. Normative References 801 [RFC6310] "Pseudowire (PW) Operations, Administration, and 802 Maintenance (OAM) Message Mapping", RFC 6310, July 2011. 804 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 805 Requirement Levels", BCP 14, RFC 2119, March 1997. 807 [802.3] "CDMA/CD access method and physical layer specifications", 808 Clause 57 for Operations, Administration and Maintenance, 2005. 810 [MEF16] "Ethernet Local Management Interface", Metro Ethernet Forum 811 Technical Specification MEF16, January 2006. 813 [802.1ag] "Connectivity Fault Management", IEEE 802.1ag, December 814 2007. 816 [Y.1731] "OAM Functions and mechanisms for Ethernet based 817 networks", ITU-T Y.1731, May 2006. 819 [RFC4447] "Pseudowire Setup and Maintenance using LDP", RFC4447, 820 April 2006. 822 [RFC5885] "Bidirectional Forwarding Detection (BFD) for the 823 Pseudowire Virtual Circuit Connectivity Verification (VCCV)", 824 RFC5885, June 2010. 826 [RFC6478] Martini, L., Swallow, G., Heron, G., and Bocci, M., 827 "Pseudowire Status for Static Pseudowires", RFC 6478, May 2012. 829 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual 830 Circuit Connectivity Verification (VCCV): A Control 831 Channel for Pseudowires", RFC 5085, December 2007. 833 10.2. Informative References 835 [RFC3985] "Pseudo Wire Emulation Edge-to-Edge(PWE3) Architecture", 836 RFC 3985, April 2005. 838 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon,"Multiprotocol 839 Label Switching Architecture", RFC 3031, January 2001. 841 RFC4023] Worster, T., Rekhter, Y., and E. Rosen"Encapsulating MPLS 842 in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 843 2005. 845 [RFC5659] "An Architecture for Multi-Segment Pseudo Wire Emulation 846 Edge-to-Edge", RFC5659, October 2009. 848 [RFC5254] Bitar, N., Bocci, M., and L. Martini, "Requirements for 849 Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", RFC 5254, 850 October 2008. 852 11. Appendix A: Ethernet Native Service Management 854 Ethernet OAM mechanisms are broadly classified into two categories: 855 Fault Management (FM) and Performance Monitoring (PM). ITU-T Y.1731 856 provides coverage for both FM and PM while IEEE 802.1ag provides 857 coverage for a sub-set of FM functions. 859 Ethernet OAM also introduces the concept of Maintenance Entity (ME) 860 which is used to identify the entity that needs to be managed. An 861 ME is inherently a point-to-point association. However, in case of 862 a multipoint association, Maintenance Entity Group (MEG) consisting 863 of different MEs is used. IEEE 802.1 uses the concept of 864 Maintenance Association (MA) which is used to identify both point- 865 to-point and multipoint associations. Each MEG/MA consists of MEG 866 End Points (MEPs) which are responsible for originating OAM frames. 867 In between the MEPs, there can also be MEG Intermediate Points 868 (MIPs) which do not originate OAM frames however do respond to OAM 869 frames from MEPs. 871 Ethernet OAM allows for hierarchical maintenance entities to allow 872 for simultaneous end-to-end and segment monitoring. This is 873 achieved by having a provision of up to 8 MEG Levels (MD Levels) 874 where each MEP or MIP is associated with a specific MEG Level. 876 It is important to note that the common set of FM mechanisms 877 between IEEE 802.1ag and ITU-T Y.1731 are completely compatible. 879 The common FM mechanisms include: 881 1) Continuity Check Messages (CCM) 883 2) Loopback Message (LBM) and Loopback Reply (LBR) 885 3) Linktrace Message (LTM) and Linktrace Reply (LTR) 887 CCM messages are used for fault detection including misconnections 888 and mis-configurations. Typically CCM messages are sent as 889 multicast frames or Unicast frames and also allow RDI 890 notifications. LBM/LBR are used to perform fault verification, 891 while also allow for MTU verification and CIR/EIR measurements. 892 LTM/LTR can be used for discovering the path traversed between a 893 MEP and another target MIP/MEP in the same MEG. LTM/LTR also allow 894 for fault localization. 896 In addition, ITU-T Y.1731 also specifies the following FM 897 functions: 899 4) Alarm Indication Signal (AIS) 901 AIS allows for fault notification to downstream and upstream nodes. 903 Further, ITU-T Y.1731 also specifies the following PM functions: 905 5) Loss Measurement Message (LMM) and Reply (LMR) 907 6) Delay Measurement Message (DMN) and Reply (DMR) 909 7) 1-way Delay Message (1DM) 911 While LMM/LMR is used to measure Frame Loss Ratio (FLR), DMM/DMR is 912 used to measure single-ended (aka two-way) Frame Delay (FD) and 913 Frame Delay Variation (FDV, also known as Jitter). 1DM can be used 914 for dual-ended (aka one-way) FD and FDV measurements. 916 Authors' Addresses 918 Dinesh Mohan 919 Nortel 920 Email: dinmohan@hotmail.com 922 Nabil Bitar 923 Verizon 924 60 Sylvan Road 925 Waltham, MA 02145 926 Email: nabil.n.bitar@verizon.com 928 Ali Sajassi 929 Cisco 930 170 West Tasman Drive 931 San Jose, CA 95134, US 932 Email: sajassi@cisco.com 934 Simon Delord 935 Alcatel-Lucent 936 215 Spring Street 937 Melbourne, Australia 938 E-mail: simon.delord@gmail.com 940 Philippe Niger 941 France Telecom 942 2 av. Pierre Marzin 943 22300 LANNION, France 944 E-mail: philippe.niger@francetelecom.com 945 Ray Qiu 946 Juniper 947 1194 North Mathilda Avenue 948 Sunnyvale, CA 94089, US 949 Email: rqiu@juniper.net