idnits 2.17.1 draft-ietf-pwe3-mpls-eth-oam-iwk-04.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([PW-OAM-MSG-MAP], [RFC3985]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) -- Possible downref: Non-RFC (?) normative reference: ref. 'MEF16' == Outdated reference: A later version (-16) exists of draft-ietf-pwe3-oam-msg-map-14 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft D. Mohan (Editor), Nortel 2 PWE3 Working Group N. Bitar (Editor), Verizon 3 Intended status: Standards Track P. Niger, France Telecom 4 Date Created: March 02, 2011 S. Delord, Telstra 5 Expiration Date: September 02, 2011 A. Sajassi (Editor), Cisco 6 R. Qiu, Huawei 8 MPLS and Ethernet OAM Interworking 9 draft-ietf-pwe3-mpls-eth-oam-iwk-04.txt 11 Abstract 13 This document specifies the mapping of defect states between 14 Ethernet Attachment Circuits (ACs) and associated Ethernet 15 Pseudowires (PWs) connected in accordance to the PWE3 architecture 16 [RFC3985] to realize an end-to-end emulated Ethernet service. This 17 document augments the mapping of defect states between a PW and 18 associated AC of the end-to-end emulated service in [PW-OAM-MSG- 19 MAP]. In [PW-OAM-MSG-MAP], Ethernet OAM was not covered due to lack 20 of Ethernet OAM maturity. However, since then, [Y.1731] and 21 [802.1ag] have been completed, and this document specifies the 22 mapping of defect states between Ethernet ACs and corresponding 23 Ethernet PWs. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire in September 2011. 48 Copyright Notice 50 Copyright (c) 2011 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Conventions used in this document 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in RFC 2119. 69 Table of Contents 71 Status of this Memo................................................1 72 Conventions used in this document..................................2 73 1. Introduction....................................................3 74 1.1. Reference Model and Defect Locations..........................4 75 1.2. Abstract Defect States........................................4 76 2. Terminology.....................................................6 77 3. PW Status and Defects...........................................6 78 3.1 Use of Native Service notification.............................6 79 3.2 Use of PW Status notification for MPLS PSNs....................7 80 3.3 Use of BFD Diagnostic Codes....................................7 81 4. Ethernet AC Defect States Entry or Exit Criteria................8 82 4.1 AC Receive Defect State Entry or Exit..........................8 83 4.2 AC Transmit Defect State Entry or Exit.........................8 84 5. Ethernet AC and PW Defect States Interworking...................9 85 5.1 PW Receive Defect Entry Procedures.............................9 86 5.2 PW Receive Defect Exit Procedures.............................10 87 5.3 PW Transmit Defect Entry Procedures...........................11 88 5.4 PW Transmit Defect Exit Procedures............................11 89 5.5 AC Receive Defect Entry Procedures............................12 90 5.6 AC Receive Defect Exit Procedures.............................12 91 5.7 AC Transmit Defect Entry Procedures...........................12 92 5.8 AC Transmit Defect Exit Procedures............................13 93 6. Acknowledgments................................................13 94 7. IANA Considerations............................................13 95 8. Security Considerations........................................13 96 9. References.....................................................13 97 9.1 Normative References..........................................13 98 9.2 Informative References........................................14 99 Appendix A: Ethernet Native Service Management....................14 100 Intellectual Property Statement...................................15 101 Authors' Addresses................................................16 102 1. Introduction 104 This document specifies the mapping of defect states between 105 Ethernet Attachment Circuits (ACs) and associated Ethernet 106 Pseudowires (PWs) connected in accordance to the PWE3 architecture 107 [RFC3985] to realize an end-to-end emulated Ethernet service. This 108 document augments the mapping of defect states between a PW and 109 associated AC of the end-to-end emulated service in [PW-OAM-MSG- 110 MAP]. In [PW-OAM-MSG-MAP], Ethernet OAM was not covered due to lack 111 of Ethernet OAM maturity. However, since then, [Y.1731] and 112 [802.1ag] have been completed, and this document specifies the 113 mapping of defect states between Ethernet ACs and corresponding 114 Ethernet PWs. 116 Ethernet Link OAM [802.3] allows some Link defect states to be 117 detected and communicated across an Ethernet Link. When an Ethernet 118 AC is an Ethernet PHY, there may be some application of Ethernet 119 Link OAM [802.3]. Further, E-LMI [MEF16] also allows for some EVC 120 defect states to be communicated across an Ethernet UNI where 121 Ethernet UNI constitutes a single hop Ethernet Link (i.e. without 122 any 802.1Q/.1ad compliant bridges in between). There may be some 123 application of E-LMI [MEF16] for failure notification across single 124 hop Ethernet AC in certain deployments that specifically do not 125 support [802.1ag] and/or [Y.1731]. [Y.1731] and [802.1ag] based 126 mechanisms are applicable in all types of Ethernet ACs. Ethernet 127 Link OAM [802.3] and E-LMI [MEF16] are optional and their 128 applicability is called out, where applicable. 130 Native Service (NS) OAM may be transported transparently over the 131 corresponding PW as user data. For Ethernet, as an example, 802.1ag 132 continuity check messages (CCMs) between two Maintenance End Points 133 (MEPs) can be transported transparently as user data over the 134 corresponding PW. At MEP locations, service failure is detected when 135 a number of consecutive CCMs are missed. MEP locations can be the 136 PE, the CE or both with different Maintenance Domain Levels. 137 However, when interworking two networking domains, such as native 138 Ethernet and PWs to provide an end-to-end emulated service, there is 139 need to identify the failure domain and location even when a PE 140 supports both the NS OAM mechanisms and the PW OAM mechanisms. In 141 addition, scalability constraints may not allow running proactive 142 monitoring, such as CCMs with transmission on, at a PE to detect the 143 failure of an Ethernet Virtual circuit (EVC) across the PW domain. 144 Thus, network driven alarms generated upon failure detection in the 145 NS or PW domain and their mappings to the other domain are needed. 146 There are also cases where a PE may not be able to process NS OAM 147 messages received on the PW even when such messages are defined, as 148 in Ethernet case, necessitating the need for fault notification 149 message mapping between the PW domain and the Client domain. 151 For Multi-Segment PWs (MS-PWs) [RFC5659], Switching PEs (S-PEs) 152 are not aware of the NS. Thus failure detection and notification at 153 S-PEs will be based on PW OAM mechanisms. Mapping between PW OAM and 154 NS OAM will be required at the Terminating PEs (T-PEs) to propagate 155 the failure notification to the EVC endpoints. 157 Similar to [PW-OAM-MSG-MAP], the intent of this document is to 158 standardize the behavior of PEs with respect to failures on Ethernet 159 ACs and PWs, so that there is no ambiguity about the alarms 160 generated and consequent actions undertaken by PEs in response to 161 specific failure conditions. 163 1.1. Reference Model and Defect Locations 165 Figure 1 is the same as used in [PW-OAM-MSG-MAP] and is reproduced 166 in this document as a reference to highlight defect locations. 168 ACs PSN tunnel ACs 169 +----+ +----+ 170 +----+ | PE1|==================| PE2| +----+ 171 | |---(a)---(b)..(c)......PW1..(d)..(c)..(f)---(e)---| | 172 | CE1| (N1) | | | | (N2) |CE2 | 173 | |----------|............PW2.............|----------| | 174 +----+ | |==================| | +----+ 175 ^ +----+ +----+ ^ 176 | Provider Edge 1 Provider Edge 2 | 177 | | 178 |<-------------- Emulated Service ---------------->| 180 Customer Customer 181 Edge 1 Edge 2 183 Figure 1: PWE3 Network Defect Locations 185 1.2. Abstract Defect States 187 Abstract Defect States are also introduced in [PW-OAM-MSG-MAP]. This 188 document uses the same conventions, as shown in Figure 2 from [PW- 189 OAM-MSG-MAP]. It may be noted however that CE devices, shown in 190 Figure 2, do not necessarily have to be end customer devices; these 191 are essentially devices in client network segments that are 192 connecting to PSN network for the emulated services. 194 +-----+ 195 ----AC receive ----->| |-----PW transmit----> 196 CE1 | PE1 | PE2/CE2 197 <---AC transmit------| |<----PW receive----- 198 +-----+ 200 (arrows indicate direction of user traffic impacted by a defect) 202 Figure 2: Transmit and Receive Defect States and Notifications 203 PE1 may detect a receive defect in local Ethernet AC via one of the 204 following mechanisms: 205 - An AIS alarm generated at an upstream node in the client domain 206 (CE1 in Figure 2) and received by a local MEP associated with the 207 local AC. 208 - Failure of the local link on which the AC is configured. Link 209 failure may be detected via physical failures (e.g., loss of signal 210 (LoS)), or via Ethernet Link OAM [802.3] critical link event 211 notifications generated at an upstream node CE1 with "Dying Gasp" 212 or "Critical Event" indication. 213 - Failure to receive CCMs on the AC if a local MEP is configured for 214 the AC. 215 - A CCM from CE1 with interface status TLV indicating interface down. 216 Other CCM interface status TLVs will not be used to indicate 217 failure or recovery from failure. 219 AC receive defect at PE1 impacts the ability of PE1 to receive user 220 traffic from the Client domain attached to PE1 via that AC. 222 Similarly, PE1 may detect a receive defect in the PW via one of the 223 following mechanisms: 224 - Forward Defect indication received from PE2. This defect 225 indication could point to problems associated with PE2's inability 226 to transmit traffic on the PW or PE2's inability to receive traffic 227 on its local AC. 228 - Unavailability of a PSN path in the PW domain to PE2. 230 PW forward defect indication received on PE1 impacts the ability of PE1 231 to receive traffic on the PW. 233 PE1 may be notified of an AC transmit defect via one of the following 234 mechanisms: 235 - CCMs with RDI (Remote Defect Indication) bit set. 236 - In case when the AC is associated with a physical port, failure of 237 the local link on which the AC is configured (e.g., LOS or via Ethernet 238 Link OAM [802.3] critical link event notifications generated at an 239 upstream node CE1 with "Link Fault" indication). 241 AC transmit defect impacts the ability of PE1 to send user traffic on 242 the local AC. 244 Similarly, PE1 may be notified of a PW transmit defect via Reverse 245 Defect indication from PE2, which could point to problems associated 246 with PE2's inability to receive traffic on the PW or PE2's inability 247 to transmit traffic on its local AC. PW transmit defect impacts PE1 248 ability to send user traffic toward CE2. 250 The procedures outlined in this document define the entry and exit 251 criteria for each of the four defect states with respect to Ethernet 252 ACs and corresponding PWs, and the consequent actions that PE1 must 253 support to properly interwork these defect states and corresponding 254 notification messages between the PW domain and the Native Service 255 (NS) domain. Receive Defect state should have precedence over 256 Transmit Defect state in terms of handling, when both transmit and 257 receive defect states are identified simultaneously. 259 2. Terminology 261 This document uses the following terms: 262 AIS Alarm Indication Signal 263 MD Level Maintenance Domain (MD) Level which identifies a value 264 in the range of 0-7 associated with Ethernet OAM frame. 265 MD Level identifies the span of the Ethernet OAM frame. 266 MEP Maintenance End Point is responsible for origination 267 and termination of OAM frames for a given MEG 268 MIP Maintenance Intermediate Point is located between peer 269 MEPs and can process OAM frames but does not initiate 270 or terminate them 271 RDI Remote Defect Indication 273 Further, this document also uses the terminology and conventions 274 used in [PW-OAM-MSG-MAP]. 276 3. PW Status and Defects 278 [PW-OAM-MSG-MAP] introduces a range of defects that impact PW 279 status. All these defect conditions are applicable for Ethernet PWs. 281 Similarly, there are different mechanisms described in [PW-OAM-MSG- 282 MAP] to detect PW defects, depending on the PSN type (e.g. MPLS PSN, 283 MPLS-IP PSN). Any of these mechanisms can be used when monitoring 284 the state of Ethernet PWs. [PW-OAM-MSG-MAP] also discusses the 285 applicability of these failure detection mechanisms. 287 3.1 Use of Native Service (NS) notification 289 There is no NS fault notification capability currently specified for 290 Ethernet PWs. However, with the completion of Ethernet OAM work, 291 this capability should be added. This includes the ability to create 292 a MEP associated with the Ethernet PW on the PE. The native service 293 notification options include: 295 - AIS Frames sent by the local MEP to the MEP on the remote PE when 296 the MEP needs to convey PE receive defects, and when CCM 297 transmission is configured not to be turned ON. 298 - Suspension of CCM frames transmission from the MEP to the peer MEP 299 on the other PE to convey PE receive defects, when CCM 300 transmission is configured to be turned ON. 301 - RDI bit set in transmitted CCM frames, when loss of CCMs from the 302 peer MEP is detected or PE needs to convey PW reverse defects. 304 These NS OAM notifications are inserted into the corresponding PW. 306 Similarly, when the defect conditions are cleared, a PE can take one 307 of the following actions, depending on the mechanism that was used 308 for failure notification, to clear the defect sate on the peer PE: 310 - Stop AIS Frame transmission from the local MEP to the MEP on the 311 remote PE to clear PW receive defects; 312 - Resuming CCM frames transmission from the MEP to the peer MEP to 313 clear PW forward defects notification, when CCM transmission is 314 configured to be turned ON. 315 - Clearing RDI indication in transmitted CCM frames, to clear PW 316 transmit defects notification. 318 3.2 Use of PW Status notification for MPLS PSNs 320 When PWs are established using LDP, LDP status notification 321 signaling SHOULD be used as the default mechanism to signal AC and 322 PW status and defects [RFC4447]. For PWs established over an MPLS or 323 MPLS-IP PSN using other mechanisms (e.g. static configuration), 324 inband signaling using VCCV-BFD [RFC5885] SHOULD be used to convey AC 325 and PW status and defects. 327 [PW-OAM-MSG-MAP] identifies the following PW defect status 328 codepoints: 329 - Forward defect: corresponds to a logical OR of local AC (ingress) 330 Receive fault, local PSN-facing PW (egress) transmit fault, and PW 331 not forwarding fault. 332 - Reverse defect: corresponds to a logical OR of local AC (egress) 333 transmit fault and local PW PSN-facing (ingress) receive fault. 335 There are also scenarios where a PE carries out PW label withdrawal 336 instead of PW status notification. These include administrative 337 disablement of the PW or loss of Target LDP session with the peer 338 PE. 340 3.3 Use of BFD Diagnostic Codes 342 When using VCCV, the control channel (CC) type and Connectivity 343 Verification (CV) Type are agreed on between the peer PEs using the 344 OAM capability sub-TLV signaled as part of the interface parameter 345 TLV when using FEC 129 and the interface parameter sub-TLV when 346 using FEC 128. 348 As defined in [PW-OAM-MSG-MAP], when CV type of 0x04 0r 0x1 is used 349 to indicate that BFD is used for PW fault detection only, PW defect 350 is detected via the BFD session while other defects, such as AC 351 detected or PE internal defects preventing it from forwarding traffic, 352 are communicated via LDP Status notification message in MPLS and 353 MPLS-IP PSN or other mechanisms in L2TP-IP PSN. 355 Similarly, when CV type of 0x08 or 0x20 is used to indicate that BFD 356 is used for both PW fault detection and AC/PW Fault Notification, 357 all defects are signaled via BFD. 359 4. Ethernet AC Defect States Entry or Exit Criteria 361 4.1 AC Receive Defect State Entry or Exit 363 PE1 enters the AC Receive Defect state if any of the following 364 conditions are met: 366 - It detects or is notified of a physical layer fault on the 367 Ethernet interface. Ethernet link failure can be detected based on 368 loss of signal (LoS) or via Ethernet Link OAM [802.3] critical 369 link event notifications generated at an upstream node CE1 with 370 "Dying Gasp" or "Critical Event" indication. 371 - A MEP associated with the local AC receives an Ethernet AIS frame. 372 - A MEP associated with the local AC does not receive CCM frames 373 from the peer MEP in the client domain (e.g. CE1) within a 374 configurable interval equal to a multiple (e.g. 3.5) of the CCM 375 transmission period configured for the MEP. This is the case when 376 CCM transmission is configured to be turned ON. 377 - A CCM with interface status TLV indicating interface down. Other 378 CCM interface status TLVs will not be used to indicate 379 failure or recovery from failure. 381 PE1 exits the AC Receive Defect state if all of the conditions that 382 resulted in entering the defect state are cleared. This includes all 383 of the following conditions: 385 - Any physical layer fault on the Ethernet interface, if detected or 386 notified previously, iss removed (e.g. via loss of signal (LoS), or 387 Ethernet Link OAM [802.3] critical link event notifications with 388 "Dying Gasp" or "Critical Event" indication cleared at an upstream 389 node CE1). 390 - A MEP associated with the local AC does not receive any Ethernet 391 AIS frame within a period indicated by previously received AIS, if 392 AIS was resulted in entering the defect state. 393 - A MEP associated with the local AC and configured with CCM 394 transmission on receives a configured number (e.g. 3 or more) of 395 consecutive CCM frames from the peer MEP on CE1 within an interval 396 equal to a multiple (e.g. 3.5) of the CCM transmission period 397 configured for the MEP. 398 - CCM indicates interface status up 400 4.2 AC Transmit Defect State Entry or Exit 402 PE1 enters the AC Transmit Defect state if any of the following 403 conditions is met: 405 - It detects or is notified of a physical layer fault on the 406 Ethernet interface (e.g. via loss of signal (LoS) or Ethernet Link 407 OAM [802.3] critical link event notifications generated at an 408 upstream node CE1 with "Link Fault" indication). 409 - A MEP configured with CCM transmission turned ON and associated 410 with the local AC receives a CCM frame, with its RDI bit set, from 411 peer MEP in the client domain (e.g. CE1). 413 PE1 exits the AC Transmit Defect state if all of the conditions that 414 resulted in entering the defect state are cleared. This includes all 415 of the following conditions: 417 - Any physical layer fault on the Ethernet interface, if detected or 418 notified previously, is removed (e.g. via Ethernet Link OAM 419 [802.3] critical link event notifications with "Link Fault" 420 indication cleared at an upstream node CE1). 421 - A MEP configured with CCM transmission turned ON and associated 422 with the local AC does not receive a CCM frame with RDI bit set, 423 having received a previous CCM frame with RDI bit set from the 424 peer MEP in the client domain (e.g. CE1). 426 5. Ethernet AC and PW Defect States Interworking 428 5.1 PW Receive Defect Entry Procedures 430 When the PW status on PE1 transitions from working to PW Receive 431 Defect state, PE1's ability to receive user traffic from CE2 is 432 impacted. As a result, PE1 needs to notify CE1 about this problem. 434 Upon entry to the PW Receive Defect state, the following must be 435 done: 437 - If PE1 is configured with a MEP associated with the local AC and 438 CCM transmission is not configured to be turned ON, the MEP 439 associated with the AC must transmit AIS frames periodically to the 440 MEP in the client domain (e.g. on CE1) based on configured AIS 441 transmission period. 443 - If PE1 is configured with a MEP associated with the local AC and 444 CCM transmission is configured to be turned ON, and the MEP 445 associated with the AC is configured to support Interface Status TLV 446 in CCM messages, the MEP associated with the AC must transmit CCM 447 frames with Interface Status TLV as being down to the peer MEP in 448 the client domain (e.g. on CE1). 450 - If PE1 is configured with a MEP associated with the local AC and 451 CCM transmission is configured to be turned ON, and the MEP 452 associated with the AC is configured to not support Interface Status 453 TLV in CCM messages, the MEP associated with the AC must stop 454 transmitting CCM frames to the peer MEP in the client domain (e.g. 455 on CE1). 457 - If PE1 is configured to run E-LMI [MEF16] with CE1 and if E-LMI 458 is used for failure notification, PE1 must transmit E-LMI 459 asynchronous STATUS message with report type Single EVC Asynchronous 460 Status indicating that PW is Not Active. 462 Further, when PE1 enters the Receive Defect state, it must assume 463 that PE2 has no knowledge of the defect and must send reverse defect 464 failure notification to PE2. For MPLS PSN or MPLS-IP PSN, this is 465 done via either a PW Status notification message indicating a 466 reverse defect; or via VCCV-BFD diagnostic code of reverse defect if 467 VCCV CV type of 0x08 had been negotiated. When Native Service OAM 468 mechanism is supported on PE, it can also use the NS OAM 469 notification as specified in Section 3.1. 471 If PW receive defect is entered as a result of a forward defect 472 notification from PE2 or via loss of control adjacency, no 473 additional action is needed since PE2 is expected to be aware of the 474 defect. 476 Note: The location of the MEP associated with the local AC within a 477 PE can be a down MEP on the port associated with the AC or an Up MEP 478 associated with an emulated LAN interface within the PE, as defined 479 in L2VPN framework for a VPLS PE. Though for the purposes of VPWS 480 service, VPLS PE architecture is not mandatory, the VPLS PE 481 architecture serves as a generic case where the PE can support both 482 VPWS and VPLS services. 484 5.2 PW Receive Defect Exit Procedures 486 When the PW status transitions from PW Receive Defect state to 487 working, PE1's ability to receive user traffic from CE2 is restored. 488 As a result, PE1 needs to cease defect notification to CE1 by 489 performing the following: 491 - If PE1 is configured with a a MEP associated with the local AC and 492 CCM transmission is not configured to be turned ON, the MEP 493 associated with the AC must stop transmitting AIS frames towards the 494 peer MEP in the client domain (e.g. on CE1). 496 - If PE1 is configured with a MEP associated with the local AC and 497 CCM transmission is configured to be turned ON, and the MEP 498 associated with the AC is configured to support Interface Status TLV 499 in CCM messages, the MEP associated with the AC must transmit CCM 500 frames with Interface Status TLV as being Up to the peer MEP in the 501 client domain (e.g. on CE1). 503 - If PE1 is configured with a MEP associated with the local AC and 504 CCM transmission is configured to be turned ON, and the MEP 505 associated with the AC is configured to not support Interface Status 506 TLV in CCM messages, the MEP associated with the AC must resume 507 transmitting CCM frames to the peer MEP in the client domain (e.g. 508 on CE1). 510 - If PE1 is configured to run E-LMI [MEF16] with CE1 and E-LMI is 511 used for fault notification, PE1 must transmit E-LMI asynchronous 512 STATUS message with report type Single EVC Asynchronous Status 513 indicating that PW is Active. 515 Further, if the PW receive defect was explicitly detected by PE1, it 516 must now notify PE2 about clearing of Receive Defect state by 517 clearing reverse defect notification. For PWs over MPLS PSN or MPLS- 518 IP PSN, this is either done via PW Status message indicating 519 working; or via VCCV-BFD diagnostic code if VCCV CV type of 0x08/0x20 520 had been negotiated. When Native Service OAM mechanism is supported 521 on PE, it can also clear the NS OAM notification specified in Section 522 3.1. 524 If PW receive defect was established via notification from PE2 or 525 via loss of control adjacency, no additional action is needed, since 526 PE2 is expected to be aware of the defect clearing. 528 5.3 PW Transmit Defect Entry Procedures 530 When the PW status transitions from working to PW Transmit Defect 531 state, PE1's ability to transmit user traffic to CE2 is impacted. As 532 a result, PE1 needs to notify CE1 about this problem which has been 533 detected by PE1. 535 Upon entry to the PW Transmit Defect state, the following must be 536 done: 538 - If PE1 is configured with a MEP associated with the local AC and 539 CCM transmission is configured to be turned ON, the MEP associated 540 with the AC must set the RDI bit in transmitted CCM frames sent to 541 the peer MEP in the client domain (e.g. on CE1). 543 - If PE1 is configured to run E-LMI [MEF16] with CE1 and E-LMI is 544 used for fault notification, PE1 must transmit E-LMI asynchronous 545 STATUS message with report type Single EVC Asynchronous Status 546 indicating that PW is Not Active. 548 5.4 PW Transmit Defect Exit Procedures 550 When the PW status transitions from PW Transmit Defect state to 551 working, PE1's ability to transmit user traffic to CE2 is restored. 552 As a result, PE1 needs to cease defect notifications to CE1 and 553 perform the following 555 - If PE1 is configured with a MEP associated with the local AC and 556 CCM transmission is configured to be turned ON, the MEP associated 557 with the AC must clear the RDI bit in the transmitted CCM frames to 558 the peer MEP (e.g. on CE1). 560 - If PE1 is configured to run E-LMI [MEF16] with CE1, PE1 must 561 transmit E-LMI asynchronous STATUS message with report type Single 562 EVC Asynchronous Status indicating that PW is Active. 564 5.5 AC Receive Defect Entry Procedures 566 When AC status transitions from working to AC Receive Defect state, 567 PE1's ability to receive user traffic from CE1 is impacted. As a 568 result, PE1 needs to notify PE2 and CE1 about this problem. 570 If the AC receive defect is detected by PE1, it must notify PE2 in 571 the form of a forward defect notification. 573 When NS OAM is not supported on PE1, and for PW over MPLS PSN or 574 MPLS-IP PSN, forward defect notification is done via either PW 575 Status message indicating a forward defect or via VCCV-BFD 576 diagnostic code of forward defect if VCCV CV type of 0x08/0x20 had 577 been negotiated. 579 When Native Service OAM mechanism is supported on PE1, it can also 580 use the NS OAM notification as specified in Section 3.1. 582 In addition to above actions, PE1 must perform the following: 584 - If PE1 is configured with a MEP associated with the local AC and 585 CCM transmission is configured to be turned ON, the MEP associated 586 with AC must set the RDI bit in transmitted CCM frames. 588 5.6 AC Receive Defect Exit Procedures 590 When AC status transitions from AC Receive Defect to working, PE1's 591 ability to receive user traffic from CE1 is restored. As a result, 592 PE1 needs to cease defect notifications to PE2 and CE1 and perform 593 the following: 595 - When NS OAM is not supported on PE1 and for PW over MPLS PSN or 596 MPLS-IP PSN, forward defect notification is cleared via PW Status 597 message indicating a working state; or via VCCV-BFD diagnostic code 598 if VCCV CV type of 0x08 or 0x20 had been negotiated. 600 - When Native Service OAM mechanism is supported on PE1, PE1 clears 601 the NS OAM notification as specified in Section 3.1. 603 - If PE1 is configured with a MEP associated with the local AC and 604 CCM transmission is configured to be turned ON, the MEP associated 605 with the AC must clear the RDI bit in transmitted CCM frames to the 606 peer MEP in the client domain (e.g. on CE1). 608 5.7 AC Transmit Defect Entry Procedures 610 When AC status transitions from working to AC Transmit Defect, PE1's 611 ability to transmit user traffic to CE1 is impacted. As a result, 612 PE1 needs to notify PE2 about this problem. 614 If the AC transmit defect is detected by PE1, it must notify PE2 in 615 the form of a reverse defect notification. 617 When NS OAM is not supported on PE, in PW over MPLS PSN or MPLS-IP 618 PSN, reverse defect notification is either done via PW Status 619 message indicating a reverse defect; or via VCCV-BFD diagnostic code 620 of reverse defect if VCCV CV type of 0x08 or 0x20 had been negotiated. 622 When Native Service OAM mechanism is supported on PE, it can also 623 use the NS OAM notification as specified in Section 3.1. 625 5.8 AC Transmit Defect Exit Procedures 627 When AC status transitions from AC Transmit defect to working, PE1's 628 ability to transmit user traffic to CE1 is restored. As a result, 629 PE1 needs to clear notification to PE2. 631 If the AC Transmit defect is cleared, PE1 must clear reverse defect 632 notification to PE2. 634 When NS OAM is not supported on PE1 and for PW over MPLS PSN or 635 MPLS-IP PSN, reverse defect notification is cleared via either a PW 636 Status message indicating a working state or via VCCV-BFD diagnostic 637 code of if VCCV CV type of 0x08 had been negotiated. 639 When Native Service OAM mechanism is supported on PE1, PE1 can clear 640 NS OAM notification as specified in Section 3.1. 642 6. Acknowledgments 644 The authors are thankful to Samer Salam for his valuable 645 comments. 647 7. IANA Considerations 649 This document has no actions for IANA. 651 8. Security Considerations 653 This document does not impose any security concerns since it makes 654 use of existing OAM mechanisms and mapping of these messages does 655 not change inherent security features. 657 9. References 659 9.1 Normative References 660 [Y.1731] "OAM Functions and mechanisms for Ethernet based networks", 661 ITU-T Y.1731, May 2006 663 [802.1ag] "Connectivity Fault Management", IEEE 802.1ag/D8.1, Jul 664 2007 666 [RFC4447] "Pseudowire Setup and Maintenance using LDP", RFC4447, 667 April 2006 669 [RFC5885] "Bidirectional Forwarding Detection (BFD) for the 670 Pseudowire Virtual Circuit Connectivity Verification (VCCV)", 671 RFC5885, June 2010 673 [802.3] "CDMA/CD access method and physical layer specifications", 674 Clause 57 for Operations, Administration and Maintenance, 2005 676 [MEF16] "Ethernet Local Management Interface", MEF16, January 2006 678 9.2 Informative References 680 [RFC3985] "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", 681 RFC 3985, March 2005 683 [PW-OAM-MSG-MAP] "Pseudo Wire (PW) OAM Message Mapping", draft-ietf- 684 pwe3-oam-msg-map-14.txt, Work in progress, October 2010 686 [RFC5659] "An Architecture for Multi-Segment Pseudo Wire 687 Emulation Edge-to-Edge", RFC5659, October 2009 689 Appendix A: Ethernet Native Service Management 691 Ethernet OAM mechanisms are broadly classified into two categories: 692 Fault Management (FM) and Performance Monitoring (PM). ITU-T Y.1731 693 provides coverage for both FM and PM while IEEE 802.1ag provides 694 coverage for a sub-set of FM functions. 696 Ethernet OAM also introduces the concept of Maintenance Entity (ME) 697 which is used to identify the entity that needs to be managed. A ME 698 is inherently a point-to-point association. However, in case of a 699 multipoint association, Maintenance Entity Group (MEG) consisting of 700 different MEs is used. IEEE 802.1 uses the concept of Maintenance 701 Association (MA) which is used to identify both point-to-point and 702 multipoint associations. Each MA consists of Maintenance End Points 703 (MEPs) which are responsible for originating OAM frames. In between 704 the MEPs, there can also be Maintenance Intermediate Points (MIPs) 705 which do not originate OAM frames however do respond to OAM frames 706 from MEPs. 708 Ethernet OAM allows for hierarchical maintenance entities to allow 709 for simultaneous end-to-end and segment monitoring. This is achieved 710 by having a provision of up to 8 Maintenance Domain Levels (MD 711 Levels) where each MEP or MIP is associated with a specific MD 712 Level. 714 It is important to note that the common set of FM mechanisms between 715 IEEE 802.1ag and ITU-T Y.1731 are completely compatible. 717 The common FM mechanisms include: 719 1) Continuity Check Messages (CCM) 720 2) Loopback Message (LBM) and Loopback Reply (LBR) 721 3) Linktrace Message (LTM) and Linktrace Reply (LTR) 723 CCM messages are used for fault detection including misconnections 724 and mis-configurations. Typically CCM messages are sent as multicast 725 frames or Unicast frames and also allow RDI notifications. LBM/LBR 726 are used to perform fault verification, while also allow for MTU 727 verification and CIR/EIR measurements. LTM/LTR can be used for 728 discovering the path traversed between a MEP and another target 729 MIP/MEP in the same MA. LTM/LTR also allow for fault localization. 731 In addition, ITU-T Y.1731 also specifies the following FM functions: 733 4) Alarm Indication Signal (AIS) 735 AIS allows for fault notification to downstream and upstream nodes. 737 Further, ITU-T Y.1731 also specifies the following PM functions: 739 5) Loss Measurement Message (LMM) and Reply (LMR) 740 6) Delay Measurement Message (DMR) and Reply (DMR) 741 7) 1-way Delay Message (1DM) 742 While LMM/LMR is used to measure Frame Loss Ratio (FLR), DMM/DMR is 743 used to measure single-ended (aka two-way) Frame Delay (FD) and 744 Frame Delay Variation (FDV, also known as Jitter). 1DM can be used 745 for dual-ended (aka one-way) FD and FDV measurements. 747 Authors' Addresses 749 Dinesh Mohan 750 Nortel 751 3500 Carling Ave 752 Ottawa, ON K2H8E9 753 Email: dinmohan@hotmail.com 755 Nabil Bitar 756 Verizon Communications 757 117 West Street 758 Waltham, MA 02451 759 Email : nabil.n.bitar@verizon.com 761 Simon Delord 762 Telstra 763 242 Exhibition St 764 Melbourne VIC 3000, Australia 765 E-mail: simon.a.delord@team.telstra.com 767 Philippe Niger 768 France Telecom 769 2 av. Pierre Marzin 770 22300 LANNION, France 771 E-mail: philippe.niger@francetelecom.com 773 Ali Sajassi 774 Cisco 775 170 West Tasman Drive 776 San Jose, CA 95134, US 777 Email: sajassi@cisco.com 779 Ray Qiu 780 Email: rayq@huawei.com