idnits 2.17.1 draft-ietf-pwe3-mpls-eth-oam-iwk-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 1 longer page, the longest (page 5) being 59 lines 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) == Unused Reference: 'RFC5085' is defined on line 665, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) -- Possible downref: Non-RFC (?) normative reference: ref. 'VCCV-BFD' -- Possible downref: Non-RFC (?) normative reference: ref. 'MEF16' == Outdated reference: A later version (-16) exists of draft-ietf-pwe3-oam-msg-map-11 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 4 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: October 24, 2009 S. Delord, Uecomm 5 Expiration Date: March 24, 2010 A. Sajassi (Editor), Cisco 6 R. Qiu, Alcatel-Lucent 8 MPLS and Ethernet OAM Interworking 9 draft-ietf-pwe3-mpls-eth-oam-iwk-01.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire in August 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 Abstract 48 This document specifies the mapping of defect states between 49 Ethernet Attachment Circuits (ACs) and associated Ethernet 50 Pseudowires (PWs) connected in accordance to the PWE3 architecture 51 [RFC3985] to realize an end-to-end emulated Ethernet service. This 52 document augments the mapping of defect states between a PW and 53 associated AC of the end-to-end emulated service in [PW-OAM-MSG- 54 MAP]. In [PW-OAM-MSG-MAP], Ethernet OAM was not covered due to lack 55 of Ethernet OAM maturity. However, since then, [Y.1731] and 56 [802.1ag] have been completed, and this document specifies the 57 mapping of defect states between Ethernet ACs and corresponding 58 Ethernet PWs. 60 Conventions used in this document 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in RFC 2119. 66 Table of Contents 68 Status of this Memo................................................1 69 Conventions used in this document..................................2 70 1. Introduction....................................................3 71 1.1. Reference Model and Defect Locations..........................4 72 1.2. Abstract Defect States........................................4 73 2. Terminology.....................................................6 74 3. PW Status and Defects...........................................6 75 3.1 Use of Native Service notification.............................6 76 3.2 Use of PW Status notification for MPLS PSNs....................7 77 3.3 Use of BFD Diagnostic Codes....................................7 78 4. Ethernet AC Defect States Entry or Exit Criteria................8 79 4.1 AC Receive Defect State Entry or Exit..........................8 80 4.2 AC Transmit Defect State Entry or Exit.........................8 81 5. Ethernet AC and PW Defect States Interworking...................9 82 5.1 PW Receive Defect Entry Procedures.............................9 83 5.2 PW Receive Defect Exit Procedures.............................10 84 5.3 PW Transmit Defect Entry Procedures...........................11 85 5.4 PW Transmit Defect Exit Procedures............................11 86 5.5 AC Receive Defect Entry Procedures............................12 87 5.6 AC Receive Defect Exit Procedures.............................12 88 5.7 AC Transmit Defect Entry Procedures...........................12 89 5.8 AC Transmit Defect Exit Procedures............................13 90 6. Acknowledgments................................................13 91 7. IANA Considerations............................................13 92 8. Security Considerations........................................13 93 9. References.....................................................13 94 9.1 Normative References..........................................13 95 9.2 Informative References........................................14 96 Appendix A: Ethernet Native Service Management....................14 97 Intellectual Property Statement...................................15 98 Authors' Addresses................................................16 99 1. Introduction 101 This document specifies the mapping of defect states between 102 Ethernet Attachment Circuits (ACs) and associated Ethernet 103 Pseudowires (PWs) connected in accordance to the PWE3 architecture 104 [RFC3985] to realize an end-to-end emulated Ethernet service. This 105 document augments the mapping of defect states between a PW and 106 associated AC of the end-to-end emulated service in [PW-OAM-MSG- 107 MAP]. In [PW-OAM-MSG-MAP], Ethernet OAM was not covered due to lack 108 of Ethernet OAM maturity. However, since then, [Y.1731] and 109 [802.1ag] have been completed, and this document specifies the 110 mapping of defect states between Ethernet ACs and corresponding 111 Ethernet PWs. 113 Ethernet Link OAM [802.3] allows some Link defect states to be 114 detected and communicated across an Ethernet Link. When an Ethernet 115 AC is an Ethernet PHY, there may be some application of Ethernet 116 Link OAM [802.3]. Further, E-LMI [MEF16] also allows for some EVC 117 defect states to be communicated across an Ethernet UNI where 118 Ethernet UNI constitutes a single hop Ethernet Link (i.e. without 119 any 802.1Q/.1ad compliant bridges in between). There may be some 120 application of E-LMI [MEF16] for failure notification across single 121 hop Ethernet AC in certain deployments that specifically do not 122 support [802.1ag] and/or [Y.1731]. [Y.1731] and [802.1ag] based 123 mechanisms are applicable in all types of Ethernet ACs. Ethernet 124 Link OAM [802.3] and E-LMI [MEF16] are optional and their 125 applicability is called out, where applicable. 127 Native Service (NS) OAM may be transported transparently over the 128 corresponding PW as user data. For Ethernet, as an example, 802.1ag 129 continuity check messages (CCMs) between two Maintenance End Points 130 (MEPs) can be transported transparently as user data over the 131 corresponding PW. At MEP locations, service failure is detected when 132 a number of consecutive CCMs are missed. MEP locations can be the 133 PE, the CE or both with different Maintenance Domain Levels. 134 However, when interworking two networking domains, such as native 135 Ethernet and PWs to provide an end-to-end emulated service, there is 136 need to identify the failure domain and location even when a PE 137 supports both the NS OAM mechanisms and the PW OAM mechanisms. In 138 addition, scalability constraints may not allow running proactive 139 monitoring, such as CCMs with transmission on, at a PE to detect the 140 failure of an Ethernet Virtual circuit (EVC) across the PW domain. 141 Thus, network driven alarms generated upon failure detection in the 142 NS or PW domain and their mappings to the other domain are needed. 143 There are also cases where a PE may not be able to process NS OAM 144 messages received on the PW even when such messages are defined, as 145 in Ethernet case, necessitating the need for fault notification 146 message mapping between the PW domain and the Client domain. 148 For Multi-Segment PWs (MS-PWs) [MS-PW-ARCH], Switching PEs (S-PEs) 149 are not aware of the NS. Thus failure detection and notification at 150 S-PEs will be based on PW OAM mechanisms. Mapping between PW OAM and 151 NS OAM will be required at the Terminating PEs (T-PEs) to propagate 152 the failure notification to the EVC endpoints. 154 Similar to [PW-OAM-MSG-MAP], the intent of this document is to 155 standardize the behavior of PEs with respect to failures on Ethernet 156 ACs and PWs, so that there is no ambiguity about the alarms 157 generated and consequent actions undertaken by PEs in response to 158 specific failure conditions. 160 1.1. Reference Model and Defect Locations 162 Figure 1 is the same as used in [PW-OAM-MSG-MAP] and is reproduced 163 in this document as a reference to highlight defect locations. 165 ACs PSN tunnel ACs 166 +----+ +----+ 167 +----+ | PE1|==================| PE2| +----+ 168 | |---(a)---(b)..(c)......PW1..(d)..(c)..(f)---(e)---| | 169 | CE1| (N1) | | | | (N2) |CE2 | 170 | |----------|............PW2.............|----------| | 171 +----+ | |==================| | +----+ 172 ^ +----+ +----+ ^ 173 | Provider Edge 1 Provider Edge 2 | 174 | | 175 |<-------------- Emulated Service ---------------->| 177 Customer Customer 178 Edge 1 Edge 2 180 Figure 1: PWE3 Network Defect Locations 182 1.2. Abstract Defect States 184 Abstract Defect States are also introduced in [PW-OAM-MSG-MAP]. This 185 document uses the same conventions, as shown in Figure 2 from [PW- 186 OAM-MSG-MAP]. It may be noted however that CE devices, shown in 187 Figure 2, do not necessarily have to be end customer devices; these 188 are essentially devices in client network segments that are 189 connecting to PSN network for the emulated services. 191 +-----+ 192 ----AC receive ----->| |-----PW transmit----> 193 CE1 | PE1 | PE2/CE2 194 <---AC transmit------| |<----PW receive----- 195 +-----+ 197 (arrows indicate direction of user traffic impacted by a defect) 199 Figure 2: Transmit and Receive Defect States and Notifications 200 PE1 may detect a receive defect in local Ethernet AC via one of the 201 following mechanisms: 202 - An AIS alarm generated at an upstream node in the client domain 203 (CE1 in Figure 2) and received by a local MEP associated with the 204 local AC. 205 - Failure of the local link on which the AC is configured. Link 206 failure may be detected via physical failures (e.g., loss of signal 207 (LoS)), or via Ethernet Link OAM [802.3] critical link event 208 notifications generated at an upstream node CE1 with "Dying Gasp" 209 or "Critical Event" indication. 210 - Failure to receive CCMs on the AC if a local MEP is configured for 211 the AC. 212 - A CCM from CE1 with interface status TLV indicating interface down 214 AC receive defect impacts the ability of PE1 to receive user traffic 215 from the Client domain. 217 Similarly, PE1 may detect a receive defect in the PW via one of the 218 following mechanisms: 219 - Forward Defect indication received from PE2. This defect 220 indication could point to problems associated with PE2's inability 221 to transmit traffic on the PW or PE2's inability to receive traffic 222 on its local AC. 223 - Unavailability of a PSN path in the PW domain to PE2. 225 PW forward defect indication received on PE1 impacts the ability of PE1 226 to receive traffic on the PW. 228 PE1 may be notified of an AC transmit defect via one of the following 229 mechanisms: 230 - CCMs with RDI (Remote Defect Indication) bit set. 231 - In case when the AC is associated with a physical port, failure of 232 the local link on which the AC is configured (e.g., LOS or via Ethernet 233 Link OAM [802.3] critical link event notifications generated at an 234 upstream node CE1 with "Link Fault" indication). 236 AC transmit defect impacts the ability of PE1 to send user traffic on 237 the local AC. 239 Similarly, PE1 may be notified of a PW transmit defect via Reverse 240 Defect indication from PE2, which could point to problems associated 241 with PE2's inability to receive traffic on the PW or PE2's inability 242 to transmit traffic on its local AC. PW transmit defect impacts PE1 243 ability to send user traffic toward CE2. 245 The procedures outlined in this document define the entry and exit 246 criteria for each of the four defect states with respect to Ethernet 247 ACs and corresponding PWs, and the consequent actions that PE1 must 248 support to properly interwork these defect states and corresponding 249 notification messages between the PW domain and the Native Service 250 (NS) domain. Receive defect state should have precedence over 251 transmit defect state in terms of handling, when both transmit and 252 receive defect states are identified simultaneously. 254 2. Terminology 256 This document uses the following terms. 258 AIS Alarm Indication Signal 259 MD Level Maintenance Domain (MD) Level which identifies a value 260 in the range of 0-7 associated with Ethernet OAM frame. 261 MD Level identifies the span of the Ethernet OAM frame. 262 MEP Maintenance End Point is responsible for origination 263 and termination of OAM frames for a given MEG 264 MIP Maintenance Intermediate Point is located between peer 265 MEPs and can process OAM frames but does not initiate 266 or terminate them 267 RDI Remote Defect Indication 269 Further, this document also uses the terminology and conventions 270 used in [PW-OAM-MSG-MAP]. 272 3. PW Status and Defects 274 [PW-OAM-MSG-MAP] introduces a range of defects that impact PW 275 status. All these defect conditions are applicable for Ethernet PWs. 277 Similarly, there are different mechanisms described in [PW-OAM-MSG- 278 MAP] to detect PW defects, depending on the PSN type (e.g. MPLS PSN, 279 MPLS-IP PSN). Any of these mechanisms can be used when monitoring 280 the state of Ethernet PWs. [PW-OAM-MSG-MAP] also discusses the 281 applicability of these failure detection mechanisms. 283 3.1 Use of Native Service notification 285 There is no NS fault notification capability currently specified for 286 Ethernet PWs. However, with the completion of Ethernet OAM work, 287 this capability should be added. This includes the ability to create 288 a MEP associated with the Ethernet PW on the PE. The native service 289 notification options include: 291 - AIS Frames sent by the local MEP to the MEP on the remote PE when 292 the MEP needs to convey PE receive defects, and when CCM 293 transmission is configured not to be turned ON. 294 - Suspension of CCM frames transmission from the MEP to the peer MEP 295 on the other PE to convey PE receive defects, when CCM 296 transmission is configured to be turned ON. 297 - RDI bit set in transmitted CCM frames, when loss of CCMs from the 298 peer MEP is detected or PE needs to convey PW reverse defects. 300 These NS OAM notifications are inserted into the corresponding PW. 302 Similarly, when the defect conditions are cleared, a PE can take one 303 of the following actions, depending on the mechanism that was used 304 for failure notification, to clear the defect sate on the peer PE: 306 - Stop AIS Frame transmission from the local MEP to the MEP on the 307 remote PE to clear PW receive defects; 308 - Resuming CCM frames transmission from the MEP to the peer MEP to 309 clear PW forward defects notification, when CCM transmission is 310 configured to be turned ON. 311 - Clearing RDI indication in transmitted CCM frames, to clear PW 312 transmit defects notification. 314 3.2 Use of PW Status notification for MPLS PSNs 316 When PWs are established using LDP, LDP status notification 317 signaling SHOULD be used as the default mechanism to signal AC and 318 PW status and defects [RFC4447]. For PWs established over an MPLS or 319 MPLS-IP PSN using other mechanisms (e.g. static configuration), 320 inband signaling using VCCV-BFD [VCCV-BFD] SHOULD be used to convey AC 321 and PW status and defects. 323 [PW-OAM-MSG-MAP] identifies the following PW defect status 324 codepoints: 325 - Forward defect: corresponds to a logical OR of local AC (ingress) 326 Receive fault, local PSN-facing PW (egress) transmit fault, and PW 327 not forwarding fault 328 - Reverse defect: corresponds to a logical OR of local AC (egress) 329 transmit fault and local PW PSN-facing (ingress) receive fault. 331 There are also scenarios where a PE carries out PW label withdrawal 332 instead of PW status notification. These include administrative 333 disablement of the PW or loss of Target LDP session with the peer 334 PE. 336 3.3 Use of BFD Diagnostic Codes 338 When using VCCV, the control channel (CC) type and Connectivity 339 Verification (CV) Type are agreed on between the peer PEs using the 340 OAM capability sub-TLV signaled as part of the interface parameter 341 TLV when using FEC 129 and the interface parameter sub-TLV when 342 using FEC 128. 344 As defined in [PW-OAM-MSG-MAP], when CV type of 0x04 is used to 345 indicate that BFD is used for PW fault detection only, PW defect is 346 detected via the BFD session while other defects, such as AC defects 347 or PE internal defects preventing it from forwarding traffic, are 348 communicated via LDP Status notification message in MPLS and MPLS-IP 349 PSN or other mechanisms in L2TP-IP PSN. 351 Similarly, when CV type of 0x08 is used to indicate that BFD is used 352 for both PW fault detection and AC/PW Fault Notification, all 353 defects are signaled via BFD. 355 4. Ethernet AC Defect States Entry or Exit Criteria 357 4.1 AC Receive Defect State Entry or Exit 359 PE1 enters the AC receive defect state if any of the following 360 conditions are met: 362 - It detects or is notified of a physical layer fault on the 363 Ethernet interface. Ethernet link failure can be detected based on 364 loss of signal (LoS) or via Ethernet Link OAM [802.3] critical 365 link event notifications generated at an upstream node CE1 with 366 "Dying Gasp" or "Critical Event" indication. 367 - A MEP associated with the local AC receives an Ethernet AIS frame. 368 - A MEP associated with the local AC does not receive CCM frames 369 from the peer MEP in the client domain (e.g. CE1) within a 370 configurable interval equal to a multiple (e.g. 3.5) of the CCM 371 transmission period configured for the MEP. This is the case when 372 CCM transmission is configured to be turned ON. 373 - A CCM with interface status TLV indicating interface down 375 PE1 exits the AC receive defect state if all of the conditions that 376 resulted in entering the defect state are cleared. This includes all 377 of the following conditions: 379 - Any physical layer fault on the Ethernet interface, if detected or 380 notified previously, iss removed (e.g. via loss of signal (LoS), or 381 Ethernet Link OAM [802.3] critical link event notifications with 382 "Dying Gasp" or "Critical Event" indication cleared at an upstream 383 node CE1). 384 - A MEP associated with the local AC does not receive any Ethernet 385 AIS frame within a period indicated by previously received AIS, if 386 AIS was resulted in entering the defect state. 387 - A MEP associated with the local AC and configured with CCM 388 transmission on receives a configured number (e.g. 3 or more) of 389 consecutive CCM frames from the peer MEP on CE1 within an interval 390 equal to a multiple (e.g. 3.5) of the CCM transmission period 391 configured for the MEP. 392 - CCM indicates interface status up 394 4.2 AC Transmit Defect State Entry or Exit 396 PE1 enters the AC transmit defect state if any of the following 397 conditions is met: 399 - It detects or is notified of a physical layer fault on the 400 Ethernet interface (e.g. via loss of signal (LoS) or Ethernet Link 401 OAM [802.3] critical link event notifications generated at an 402 upstream node CE1 with "Link Fault" indication). 403 - A MEP configured with CCM transmission turned ON and associated 404 with the local AC receives a CCM frame, with its RDI bit set, from 405 peer MEP in the client domain (e.g. CE1). 407 PE1 exits the AC transmit defect state if all of the conditions that 408 resulted in entering the defect state are cleared. This includes all 409 of the following conditions: 411 - Any physical layer fault on the Ethernet interface, if detected or 412 notified previously, is removed (e.g. via Ethernet Link OAM 413 [802.3] critical link event notifications with "Link Fault" 414 indication cleared at an upstream node CE1). 415 - A MEP configured with CCM transmission turned ON and associated 416 with the local AC does not receive a CCM frame with RDI bit set, 417 having received a previous CCM frame with RDI bit set from the 418 peer MEP in the client domain (e.g. CE1). 420 5. Ethernet AC and PW Defect States Interworking 422 5.1 PW Receive Defect Entry Procedures 424 When the PW status on PE1 transitions from working to PW receive 425 defect state, PE1's ability to receive user traffic from CE2 is 426 impacted. As a result, PE1 needs to notify CE1 about this problem. 428 Upon entry to the PW Forward Defect State, the following must be 429 done: 431 - If PE1 is configured with a MEP associated with the local AC and 432 CCM transmission is not configured to be turned ON, the MEP 433 associated with the AC must transmit AIS frames periodically to the 434 MEP in the client domain (e.g. on CE1) based on configured AIS 435 transmission period. 437 - If PE1 is configured with a MEP associated with the local AC and 438 CCM transmission is configured to be turned ON, and the MEP 439 associated with the AC is configured to support Interface Status TLV 440 in CCM messages, the MEP associated with the AC must transmit CCM 441 frames with Interface Status TLV as being down to the peer MEP in 442 the client domain (e.g. on CE1). 444 - If PE1 is configured with a MEP associated with the local AC and 445 CCM transmission is configured to be turned ON, and the MEP 446 associated with the AC is configured to not support Interface Status 447 TLV in CCM messages, the MEP associated with the AC must stop 448 transmitting CCM frames to the peer MEP in the client domain (e.g. 449 on CE1). 451 - If PE1 is configured to run E-LMI [MEF16] with CE1 and if E-LMI 452 is used for failure notification, PE1 must transmit E-LMI 453 asynchronous STATUS message with report type Single EVC Asynchronous 454 Status indicating that PW is Not Active. 456 Further, when PE1 enters the receive defect state, it must assume 457 that PE2 has no knowledge of the defect and must send reverse defect 458 failure notification to PE2. For MPLS PSN or MPLS-IP PSN, this is 459 done via either a PW Status notification message indicating a 460 reverse defect; or via VCCV-BFD diagnostic code of reverse defect if 461 VCCV CV type of 0x08 had been negotiated. When Native Service OAM 462 mechanism is supported on PE, it can also use the NS OAM 463 notification as specified in Section 3.1. 465 If PW receive defect is entered as a result of a forward defect 466 notification from PE2 or via loss of control adjacency, no 467 additional action is needed since PE2 is expected to be aware of the 468 defect. 470 Note: The location of the MEP associated with the local AC within a 471 PE can be a down MEP on the port associated with the AC or an Up MEP 472 associated with an emulated LAN interface within the PE, as defined 473 in L2VPN framework for a VPLS PE. Though for the purposes of VPWS 474 service, VPLS PE architecture is not mandatory, the VPLS PE 475 architecture serves as a generic case where the PE can support both 476 VPWS and VPLS services. 478 5.2 PW Receive Defect Exit Procedures 480 When the PW status transitions from PW receive defect state to 481 working, PE1's ability to receive user traffic from CE2 is restored. 482 As a result, PE1 needs to cease defect notification to CE1 by 483 performing the following: 485 - If PE1 is configured with a a MEP associated with the local AC and 486 CCM transmission is not configured to be turned ON, the MEP 487 associated with the AC must stop transmitting AIS frames towards the 488 peer MEP in the client domain (e.g. on CE1). 490 - If PE1 is configured with a MEP associated with the local AC and 491 CCM transmission is configured to be turned ON, and the MEP 492 associated with the AC is configured to support Interface Status TLV 493 in CCM messages, the MEP associated with the AC must transmit CCM 494 frames with Interface Status TLV as being Up to the peer MEP in the 495 client domain (e.g. on CE1). 497 - If PE1 is configured with a MEP associated with the local AC and 498 CCM transmission is configured to be turned ON, and the MEP 499 associated with the AC is configured to not support Interface Status 500 TLV in CCM messages, the MEP associated with the AC must resume 501 transmitting CCM frames to the peer MEP in the client domain (e.g. 502 on CE1). 504 - If PE1 is configured to run E-LMI [MEF16] with CE1 and E-LMI is 505 used for fault notification, PE1 must transmit E-LMI asynchronous 506 STATUS message with report type Single EVC Asynchronous Status 507 indicating that PW is Active. 509 Further, if the PW receive defect was explicitly detected by PE1, it 510 must now notify PE2 about clearing of forward defect state by 511 clearing reverse defect notification. For PWs over MPLS PSN or MPLS- 512 IP PSN, this is either done via PW Status message indicating 513 working; or via VCCV-BFD diagnostic code if VCCV CV type of 0x08 had 514 been negotiated. When Native Service OAM mechanism is supported on 515 PE, it can also clear the NS OAM notification specified in Section 516 3.1. 518 If PW receive defect was established via notification from PE2 or 519 via loss of control adjacency, no additional action is needed, since 520 PE2 is expected to be aware of the defect clearing. 522 5.3 PW Transmit Defect Entry Procedures 524 When the PW status transitions from working to PW reverse defect 525 state, PE1's ability to transmit user traffic to CE2 is impacted. As 526 a result, PE needs to notify CE1 about this problem which has been 527 detected by PE1. 529 Upon entry to the PW Transmit Defect State, the following must be 530 done: 532 - If PE1 is configured with a MEP associated with the local AC and 533 CCM transmission is configured to be turned ON, the MEP associated 534 with the AC must set the RDI bit in transmitted CCM frames sent to 535 the peer MEP in the client domain (e.g. on CE1). 537 - If PE1 is configured to run E-LMI [MEF16] with CE1 and E-LMI is 538 used for fault notification, PE1 must transmit E-LMI asynchronous 539 STATUS message with report type Single EVC Asynchronous Status 540 indicating that PW is Not Active. 542 5.4 PW Transmit Defect Exit Procedures 544 When the PW status transitions from PW transmit defect state to 545 working, PE1's ability to transmit user traffic to CE2 is restored. 546 As a result, PE1 needs to cease defect notifications to CE1 and 547 perform the following 549 - If PE1 is configured with a MEP associated with the local AC and 550 CCM transmission is configured to be turned ON, the MEP associated 551 with the AC must clear the RDI bit in the transmitted CCM frames to 552 the peer MEP (e.g. on CE1). 554 - If PE1 is configured to run E-LMI [MEF16] with CE1, PE1 must 555 transmit E-LMI asynchronous STATUS message with report type Single 556 EVC Asynchronous Status indicating that PW is Active. 558 5.5 AC Receive Defect Entry Procedures 560 When AC status transitions from working to AC Receive defect state, 561 PE1's ability to receive user traffic from CE1 is impacted. As a 562 result, PE1 needs to notify PE2 and CE1 about this problem. 564 If the AC Forward defect is detected by PE1, it must notify PE2 in 565 the form of a forward defect notification. 567 When NS OAM is not supported on PE1, and for PW over MPLS PSN or 568 MPLS-IP PSN, forward defect notification is done via either PW 569 Status message indicating a forward defect or via VCCV-BFD 570 diagnostic code of forward defect if VCCV CV type of 0x08 had been 571 negotiated. 573 When Native Service OAM mechanism is supported on PE1, it can also 574 use the NS OAM notification as specified in Section 3.1. 576 In addition to above actions, PE1 must perform the following: 578 - If PE1 is configured with a MEP associated with the local AC and 579 CCM transmission is configured to be turned ON, the MEP associated 580 with AC must set the RDI bit in transmitted CCM frames. 582 5.6 AC Receive Defect Exit Procedures 584 When AC status transitions from AC Receive defect to working, PE1's 585 ability to receive user traffic from CE1 is restored. As a result, 586 PE1 needs to cease defect notifications to PE2 and CE1 and perform 587 the following: 589 - When NS OAM is not supported on PE1 and for PW over MPLS PSN or 590 MPLS-IP PSN, forward defect notification is cleared via PW Status 591 message indicating a working state; or via VCCV-BFD diagnostic code 592 if VCCV CV type of 0x08 had been negotiated. 594 - When Native Service OAM mechanism is supported on PE1, PE1 clears 595 the NS OAM notification as specified in Section 3.1. 597 - If PE1 is configured with a MEP associated with the local AC and 598 CCM transmission is configured to be turned ON, the MEP associated 599 with the AC must clear the RDI bit in transmitted CCM frames to the 600 peer MEP in the client domain (e.g. on CE1). 602 5.7 AC Transmit Defect Entry Procedures 604 When AC status transitions from working to AC Transmit defect, PE1's 605 ability to transmit user traffic to CE1 is impacted. As a result, 606 PE1 needs to notify PE2 about this problem. 608 If the AC Transmit defect is detected by PE1, it must notify PE2 in 609 the form of a reverse defect notification. 611 When NS OAM is not supported on PE, in PW over MPLS PSN or MPLS-IP 612 PSN, reverse defect notification is either done via PW Status 613 message indicating a reverse defect; or via VCCV-BFD diagnostic code 614 of reverse defect if VCCV CV type of 0x08 had been negotiated. 616 When Native Service OAM mechanism is supported on PE, it can also 617 use the NS OAM notification as specified in Section 3.1. 619 5.8 AC Transmit Defect Exit Procedures 621 When AC status transitions from AC Transmit defect to working, PE1's 622 ability to transmit user traffic to CE1 is restored. As a result, 623 PE1 needs to clear notification to PE2. 625 If the AC Transmit defect is cleared, PE1 must clear reverse defect 626 notification to PE2. 628 When NS OAM is not supported on PE1 and for PW over MPLS PSN or 629 MPLS-IP PSN, reverse defect notification is cleared via either a PW 630 Status message indicating a working state or via VCCV-BFD diagnostic 631 code of if VCCV CV type of 0x08 had been negotiated. 633 When Native Service OAM mechanism is supported on PE1, PE1 can clear 634 NS OAM notification as specified in Section 3.1. 636 6. Acknowledgments 638 The authors are thankful to Samer Salam for his valuable 639 comments. 641 7. IANA Considerations 643 This document has no actions for IANA. 645 8. Security Considerations 647 This document does not impose any security concerns since it makes 648 use of existing OAM mechanisms and mapping of these messages does 649 not change inherent security features. 651 9. References 653 9.1 Normative References 654 [Y.1731] "OAM Functions and mechanisms for Ethernet based networks", 655 ITU-T Y.1731, May 2006 657 [802.1ag] "Connectivity Fault Management", IEEE 802.1ag/D8.1, Jul 658 2007 660 [RFC4447] "Pseudowire Setup and Maintenance using LDP", RFC4447, 661 April 2006 663 [VCCV-BFD] "Bidirectional Forwarding Detection (BFD) for the 664 Pseudowire Virtual Circuit Connectivity Verification (VCCV)", 665 [RFC5085] "Pseudowire Virtual Circuit Connectivity Verification 666 (VCCV): A Control Channel for Pseudowires", RFC5085, December 2007 668 [802.3] "CDMA/CD access method and physical layer specifications", 669 Clause 57 for Operations, Administration and Maintenance, 2005 671 [MEF16] "Ethernet Local Management Interface", MEF16, January 2006 673 9.2 Informative References 675 [RFC3985] "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", 676 RFC 3985, March 2005 678 [PW-OAM-MSG-MAP] "Pseudo Wire (PW) OAM Message Mapping", draft-ietf- 679 pwe3-oam-msg-map-11.txt, Work in progress, June 2009 681 [MS-PW-ARCH] "An Architecture for Multi-Segment Pseudo Wire 682 Emulation Edge-to-Edge", draft-ietf-pwe3-ms-pw-arch-07.txt, Work in 683 progress, July 2009 685 Appendix A: Ethernet Native Service Management 687 Ethernet OAM mechanisms are broadly classified into two categories: 688 Fault Management (FM) and Performance Monitoring (PM). ITU-T Y.1731 689 provides coverage for both FM and PM while IEEE 802.1ag provides 690 coverage for a sub-set of FM functions. 692 Ethernet OAM also introduces the concept of Maintenance Entity (ME) 693 which is used to identify the entity that needs to be managed. A ME 694 is inherently a point-to-point association. However, in case of a 695 multipoint association, Maintenance Entity Group (MEG) consisting of 696 different MEs is used. IEEE 802.1 uses the concept of Maintenance 697 Association (MA) which is used to identify both point-to-point and 698 multipoint associations. Each MA consists of Maintenance End Points 699 (MEPs) which are responsible for originating OAM frames. In between 700 the MEPs, there can also be Maintenance Intermediate Points (MIPs) 701 which do not originate OAM frames however do respond to OAM frames 702 from MEPs. 704 Ethernet OAM allows for hierarchical maintenance entities to allow 705 for simultaneous end-to-end and segment monitoring. This is achieved 706 by having a provision of up to 8 Maintenance Domain Levels (MD 707 Levels) where each MEP or MIP is associated with a specific MD 708 Level. 710 It is important to note that the common set of FM mechanisms between 711 IEEE 802.1ag and ITU-T Y.1731 are completely compatible. 713 The common FM mechanisms include: 715 1) Continuity Check Messages (CCM) 716 2) Loopback Message (LBM) and Loopback Reply (LBR) 717 3) Linktrace Message (LTM) and Linktrace Reply (LTR) 719 CCM messages are used for fault detection including misconnections 720 and mis-configurations. Typically CCM messages are sent as multicast 721 frames or Unicast frames and also allow RDI notifications. LBM/LBR 722 are used to perform fault verification, while also allow for MTU 723 verification and CIR/EIR measurements. LTM/LTR can be used for 724 discovering the path traversed between a MEP and another target 725 MIP/MEP in the same MA. LTM/LTR also allow for fault localization. 727 In addition, ITU-T Y.1731 also specifies the following FM functions: 729 4) Alarm Indication Signal (AIS) 731 AIS allows for fault notification to downstream and upstream nodes. 733 Further, ITU-T Y.1731 also specifies the following PM functions: 735 5) Loss Measurement Message (LMM) and Reply (LMR) 736 6) Delay Measurement Message (DMR) and Reply (DMR) 737 7) 1-way Delay Message (1DM) 738 While LMM/LMR is used to measure Frame Loss Ratio (FLR), DMM/DMR is 739 used to measure single-ended (aka two-way) Frame Delay (FD) and 740 Frame Delay Variation (FDV, also known as Jitter). 1DM can be used 741 for dual-ended (aka one-way) FD and FDV measurements. 743 Authors' Addresses 745 Dinesh Mohan 746 Nortel 747 3500 Carling Ave 748 Ottawa, ON K2H8E9 749 Email: mohand@nortel.com 751 Nabil Bitar 752 Verizon Communications 753 117 West Street 754 Waltham, MA 02451 755 Email : nabil.n.bitar@verizon.com 757 Simon Delord 758 Uecomm 759 658 Church St 760 Richmond, VIC, 3121, Australia 761 E-mail: sdelord@uecomm.com.au 763 Philippe Niger 764 France Telecom 765 2 av. Pierre Marzin 766 22300 LANNION, France 767 E-mail: philippe.niger@francetelecom.com 769 Ali Sajassi 770 Cisco 771 170 West Tasman Drive 772 San Jose, CA 95134, US 773 Email: sajassi@cisco.com 775 Ray Qiu 776 Alcatel-Lucent 777 701 East Middlefield Rd 778 Mountain View, CA 94043 779 Email: ray.qiu@alcatel-lucent.com