idnits 2.17.1 draft-ietf-pwe3-mpls-eth-oam-iwk-00.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: ---------------------------------------------------------------------------- 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) == Unused Reference: 'RFC5085' is defined on line 661, 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-06 == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-ms-pw-arch-03 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft D. Mohan (Editor), Nortel 3 PWE3 Working Group N. Bitar (Editor), Verizon 4 Intended status: Standards Track P. Niger, France Telecom 5 Date Created: February 28, 2009 S. Delord, Uecomm 6 Expiration Date: August 31, 2009 A. Sajassi (Editor), Cisco 8 MPLS and Ethernet OAM Interworking 9 draft-ietf-pwe3-mpls-eth-oam-iwk-00.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 Forward Defect State Entry or Exit..........................8 80 4.2 AC Reverse Defect State Entry or Exit..........................8 81 5. Ethernet AC and PW Defect States Interworking...................9 82 5.1 PW Forward Defect Entry Procedures.............................9 83 5.2 PW Forward Defect Exit Procedures.............................10 84 5.3 PW Reverse Defect Entry Procedures............................11 85 5.4 PW Reverse Defect Exit Procedures.............................11 86 5.5 AC Forward Defect Entry Procedures............................12 87 5.6 AC Forward Defect Exit Procedures.............................12 88 5.7 AC Reverse Defect Entry Procedures............................12 89 5.8 AC Reverse 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 forward---->| |-----PW reverse----> 193 CE1 | PE1 | PE2/CE2 194 <---AC reverse-----| |<----PW forward----- 195 +-----+ 197 (arrows indicate direction of user traffic impacted by a defect) 199 Figure 2: Forward and Reverse Defect States and Notifications 200 PE1 may detect a forward 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. 213 AC forward defect impacts the ability of PE1 to receive user traffic 214 from the Client domain. 216 Similarly, PE1 may detect a forward defect in the PW via one of the 217 following mechanisms: 218 - Forward Defect indication received from PE2. This defect 219 indication could point to problems associated with PE2's inability 220 to transmit traffic on the PW or PE2's inability to receive traffic 221 on its local AC. 222 - Unavailability of a PSN path in the PW domain to PE2. 224 PW forward defect received on PE1 impacts the ability of PE1 to 225 receive traffic on the PW. 227 PE1 may be notified of an AC reverse defect via one of the following 228 mechanisms: 229 - CCMs with RDI (Remote Defect Indication) bit set. 230 - In case when the AC is associated with a physical port, failure of 231 the local link on which the AC is configured (e.g. via Ethernet 232 Link OAM [802.3] critical link event notifications generated at an 233 upstream node CE1 with "Link Fault" indication). 235 AC reverse defect impacts the ability of PE1 to send user traffic on 236 the local AC. 238 Similarly, PE1 may be notified of a PW reverse defect via Reverse 239 Defect indication from PE2, which could point to problems associated 240 with PE2's inability to receive traffic on the PW or PE2's inability 241 to transmit traffic on its local AC. PW reverse defect impacts PE1 242 ability to send user traffic to CE2. 244 The procedures outlined in this document define the entry and exit 245 criteria for each of the four defect states with respect to Ethernet 246 ACs and corresponding PWs, and the consequent actions that PE1 must 247 support to properly interwork these defect states and corresponding 248 notification messages between the PW domain and the Native Service 249 (NS) domain. Forward defect state should have precedence over 250 reverse defect state in terms of handling, when both forward and 251 reverse defect states are identified simultaneously. 253 2. Terminology 255 This document uses the following terms. 257 AIS Alarm Indication Signal 258 MD Level Maintenance Domain (MD) Level which identifies a value 259 in the range of 0-7 associated with Ethernet OAM frame. 260 MD Level identifies the span of the Ethernet OAM frame. 261 MEP Maintenance End Point is responsible for origination 262 and termination of OAM frames for a given MEG 263 MIP Maintenance Intermediate Point is located between peer 264 MEPs and can process OAM frames but does not initiate 265 or terminate them 266 RDI Remote Defect Indication 268 Further, this document also uses the terminology and conventions 269 used in [PW-OAM-MSG-MAP]. 271 3. PW Status and Defects 273 [PW-OAM-MSG-MAP] introduces a range of defects that impact PW 274 status. All these defect conditions are applicable for Ethernet PWs. 276 Similarly, there are different mechanisms described in [PW-OAM-MSG- 277 MAP] to detect PW defects, depending on the PSN type (e.g. MPLS PSN, 278 MPLS-IP PSN). Any of these mechanisms can be used when monitoring 279 the state of Ethernet PWs. [PW-OAM-MSG-MAP] also discusses the 280 applicability of these failure detection mechanisms. 282 3.1 Use of Native Service notification 284 There is no NS fault notification capability currently specified for 285 Ethernet PWs. However, with the completion of Ethernet OAM work, 286 this capability should be added. This includes the ability to create 287 a MEP associated with the Ethernet PW on the PE. The native service 288 notification options include: 290 - AIS Frames sent by the local MEP to the MEP on the remote PE when 291 the MEP needs to convey PE forward defects, and when CCM 292 transmission is configured not to be turned ON. 293 - Suspension of CCM frames transmission from the MEP to the peer MEP 294 on the other PE to convey PE forward defects, when CCM 295 transmission is configured to be turned ON. 296 - RDI in transmitted CCM frames, when loss of CCMs from the peer MEP 297 is detected or PE needs to convey PW reverse defects. 299 These NS OAM notifications are inserted into the corresponding PW. 301 Similarly, when the defect conditions are cleared, a PE can take one 302 of the following actions, depending on the mechanism that was used 303 for failure notification, to clear the defect sate on the peer PE: 305 - Stop AIS Frame transmission from the local MEP to the MEP on the 306 remote PE to clear PW forward defects; 307 - Resuming CCM frames transmission from the MEP to the peer MEP to 308 clear PW forward defects notification, when CCM transmission is 309 configured to be turned ON. 310 - Clearing RDI indication in transmitted CCM frames, to clear PW 311 reverse defects notification. 313 3.2 Use of PW Status notification for MPLS PSNs 315 When PWs are established using LDP, LDP status notification 316 signaling SHOULD be used as the default mechanism to signal AC and 317 PW status and defects [RFC4447]. For PWs established over an MPLS or 318 MPLS-IP PSN using other mechanisms (e.g. static configuration), 319 inband signaling using VCCV-BFD [VCCV-BFD] SHOULD be used to convey AC 320 and PW status and defects. 322 [PW-OAM-MSG-MAP] identifies the following PW defect status 323 codepoints: 324 - Forward defect: corresponds to a logical OR of local AC (ingress) 325 Receive fault AND local PSN-facing PW (egress) transmit fault. 326 - Reverse defect: corresponds to a logical OR of local AC (egress) 327 transmit fault and local PW PSN-facing (ingress) receive fault. 329 There are also scenarios where a PE carries out PW label withdrawal 330 instead of PW status notification. These include administrative 331 disablement of the PW or loss of Target LDP session with the peer 332 PE. 334 3.3 Use of BFD Diagnostic Codes 336 When using VCCV, the control channel (CC) type and Connectivity 337 Verification (CV) Type are agreed on between the peer PEs using the 338 OAM capability sub-TLV signaled as part of the interface parameter 339 TLV when using FEC 129 and the interface parameter sub-TLV when 340 using FEC 128. 342 As defined in [PW-OAM-MSG-MAP], when CV type of 0x04 is used to 343 indicate that BFD is used for PW fault detection only, PW defect is 344 detected via the BFD session while other defects, such as AC defects 345 or PE internal defects preventing it from forwarding traffic, are 346 communicated via LDP Status notification message in MPLS and MPLS-IP 347 PSN or other mechanisms in L2TP-IP PSN. 349 Similarly, when CV type of 0x08 is used to indicate that BFD is used 350 for both PW fault detection and AC/PW Fault Notification, all 351 defects are signaled via BFD. 353 4. Ethernet AC Defect States Entry or Exit Criteria 355 4.1 AC Forward Defect State Entry or Exit 357 PE1 enters the AC forward defect state if any of the following 358 conditions are met: 360 - It detects or is notified of a physical layer fault on the 361 Ethernet interface. Ethernet link failure can be detected based on 362 loss of signal (LoS) or via Ethernet Link OAM [802.3] critical 363 link event notifications generated at an upstream node CE1 with 364 "Dying Gasp" or "Critical Event" indication. 365 - A MEP associated with the local AC receives an Ethernet AIS frame. 366 - A MEP associated with the local AC does not receive CCM frames 367 from the peer MEP in the client domain (e.g. CE1) within a 368 configurable interval equal to a multiple (e.g. 3.5) of the CCM 369 transmission period configured for the MEP. This is the case when 370 CCM transmission is configured to be turned ON. 372 PE1 exits the AC forward defect state if all of the conditions that 373 resulted in entering the defect state are cleared. This includes all 374 of the following conditions: 376 - Any physical layer fault on the Ethernet interface, if detected or 377 notified previously, is removed (e.g. via loss of signal (LoS), or 378 Ethernet Link OAM [802.3] critical link event notifications with 379 "Dying Gasp" or "Critical Event" indication cleared at an upstream 380 node CE1). 381 - A MEP associated with the local AC does not receive any Ethernet 382 AIS frame within a period indicated by previously received AIS, if 383 AIS was resulted in entering the defect state. 384 - A MEP associated with the local AC and configured with CCM 385 transmission on receives a configured number (e.g. 3 or more) of 386 consecutive CCM frames from the peer MEP on CE1 within an interval 387 equal to a multiple (e.g. 3.5) of the CCM transmission period 388 configured for the MEP. 390 4.2 AC Reverse Defect State Entry or Exit 392 PE1 enters the AC reverse defect state if any of the following 393 condition is met: 395 - It detects or is notified of a physical layer fault on the 396 Ethernet interface (e.g. via loss of signal (LoS) or Ethernet Link 397 OAM [802.3] critical link event notifications generated at an 398 upstream node CE1 with "Link Fault" indication). 399 - A MEP configured with CCM transmission turned ON and associated 400 with the local AC receives a CCM frame, with its RDI bit set, from 401 peer MEP in the client domain (e.g. CE1). 403 PE1 exits the AC reverse defect state if all of the conditions that 404 resulted in entering the defect state are cleared. This includes all 405 of the following conditions: 407 - Any physical layer fault on the Ethernet interface, if detected or 408 notified previously, is removed (e.g. via Ethernet Link OAM 409 [802.3] critical link event notifications with "Link Fault" 410 indication cleared at an upstream node CE1). 411 - A MEP configured with CCM transmission turned ON and associated 412 with the local AC does not receive a CCM frame with RDI bit set, 413 having received a previous CCM frame with RDI bit set from the 414 peer MEP in the client domain (e.g. CE1). 416 5. Ethernet AC and PW Defect States Interworking 418 5.1 PW Forward Defect Entry Procedures 420 When the PW status on PE1 transitions from working to PW forward 421 defect state; PE1's ability to receive user traffic from CE2 is 422 impacted. As a result, PE1 needs to notify CE1 about this problem. 424 Upon entry to the PW Forward Defect State, the following must be 425 done: 427 - If PE1 is configured with a MEP associated with the local AC and 428 CCM transmission is not configured to be turned ON, the MEP 429 associated with the AC must transmit AIS frames periodically to the 430 MEP in the client domain (e.g. on CE1) based on configured AIS 431 transmission period. 433 - If PE1 is configured with a MEP associated with the local AC and 434 CCM transmission is configured to be turned ON, and the MEP 435 associated with the AC is configured to support Interface Status TLV 436 in CCM messages, the MEP associated with the AC must transmit CCM 437 frames with Interface Status TLV as being down to the peer MEP in 438 the client domain (e.g. on CE1). 440 - If PE1 is configured with a MEP associated with the local AC and 441 CCM transmission is configured to be turned ON, and the MEP 442 associated with the AC is configured to not support Interface Status 443 TLV in CCM messages, the MEP associated with the AC must stop 444 transmitting CCM frames to the peer MEP in the client domain (e.g. 445 on CE1). 447 - If PE1 is configured to run E-LMI [MEF16] with CE1 and if E-LMI 448 is used for failure notification, PE1 must transmit E-LMI 449 asynchronous STATUS message with report type Single EVC Asynchronous 450 Status indicating that PW is Not Active. 452 Further, when PE1 enters the forward defect state, it must assume 453 that PE2 has no knowledge of the defect and must send reverse defect 454 failure notification to PE2. For MPLS PSN or MPLS-IP PSN, this is 455 done via either a PW Status notification message indicating a 456 reverse defect; or via VCCV-BFD diagnostic code of reverse defect if 457 VCCV CV type of 0x08 had been negotiated. When Native Service OAM 458 mechanism is supported on PE, it can also use the NS OAM 459 notification as specified in Section 3.1. 461 If PW forward defect is entered as a result of a forward defect 462 notification from PE2 or via loss of control adjacency, no 463 additional action is needed since PE2 is expected to be aware of the 464 defect. 466 Note: The location of the MEP associated with the local AC within a 467 PE can be a down MEP on the port associated with the AC or an Up MEP 468 associated with an emulated LAN interface within the PE, as defined 469 in L2VPN framework for a VPLS PE. Though for the purposes of VPWS 470 service, VPLS PE architecture is not mandatory, the VPLS PE 471 architecture serves as a generic case where the PE can support both 472 VPWS and VPLS services. 474 5.2 PW Forward Defect Exit Procedures 476 When the PW status transitions from PW forward defect state to 477 working, PE1's ability to receive user traffic from CE2 is restored. 478 As a result, PE1 needs to cease defect notification to CE1 by 479 performing the following: 481 - If PE1 is configured with a a MEP associated with the local AC and 482 CCM transmission is not configured to be turned ON, the MEP 483 associated with the AC must stop transmitting AIS frames towards the 484 peer MEP in the client domain (e.g. on CE1). 486 - If PE1 is configured with a MEP associated with the local AC and 487 CCM transmission is configured to be turned ON, and the MEP 488 associated with the AC is configured to support Interface Status TLV 489 in CCM messages, the MEP associated with the AC must transmit CCM 490 frames with Interface Status TLV as being Up to the peer MEP in the 491 client domain (e.g. on CE1). 493 - If PE1 is configured with a MEP associated with the local AC and 494 CCM transmission is configured to be turned ON, and the MEP 495 associated with the AC is configured to not support Interface Status 496 TLV in CCM messages, the MEP associated with the AC must resume 497 transmitting CCM frames to the peer MEP in the client domain (e.g. 498 on CE1). 500 - If PE1 is configured to run E-LMI [MEF16] with CE1 and E-LMI is 501 used for fault notification, PE1 must transmit E-LMI asynchronous 502 STATUS message with report type Single EVC Asynchronous Status 503 indicating that PW is Active. 505 Further, if the PW forward defect was explicitly detected by PE1, it 506 must now notify PE2 about clearing of forward defect state by 507 clearing reverse defect notification. For PWs over MPLS PSN or MPLS- 508 IP PSN, this is either done via PW Status message indicating 509 working; or via VCCV-BFD diagnostic code if VCCV CV type of 0x08 had 510 been negotiated. When Native Service OAM mechanism is supported on 511 PE, it can also clear the NS OAM notification specified in Section 512 3.1. 514 If PW forward defect was established via notification from PE2 or 515 via loss of control adjacency, no additional action is needed, since 516 PE2 is expected to be aware of the defect clearing. 518 5.3 PW Reverse Defect Entry Procedures 520 When the PW status transitions from working to PW reverse defect 521 state, PE1's ability to transmit user traffic to CE2 is impacted. As 522 a result, PE needs to notify CE1 about this problem which has been 523 detected by PE1. 525 Upon entry to the PW Reverse Defect State, the following must be 526 done: 528 - If PE1 is configured with a MEP associated with the local AC and 529 CCM transmission is configured to be turned ON, the MEP associated 530 with the AC must set the RDI bit in transmitted CCM frames sent to 531 the peer MEP in the client domain (e.g. on CE1). 533 - If PE1 is configured to run E-LMI [MEF16] with CE1 and E-LMI is 534 used for fault notification, PE1 must transmit E-LMI asynchronous 535 STATUS message with report type Single EVC Asynchronous Status 536 indicating that PW is Not Active. 538 5.4 PW Reverse Defect Exit Procedures 540 When the PW status transitions from PW reverse defect state to 541 working, PE1's ability to transmit user traffic to CE2 is restored. 542 As a result, PE1 needs to cease defect notifications to CE1 and 543 perform the following 545 - If PE1 is configured with a MEP associated with the local AC and 546 CCM transmission is configured to be turned ON, the MEP associated 547 with the AC must clear the RDI bit in the transmitted CCM frames to 548 the peer MEP (e.g. on CE1). 550 - If PE1 is configured to run E-LMI [MEF16] with CE1, PE1 must 551 transmit E-LMI asynchronous STATUS message with report type Single 552 EVC Asynchronous Status indicating that PW is Active. 554 5.5 AC Forward Defect Entry Procedures 556 When AC status transitions from working to AC Forward defect state, 557 PE1's ability to receive user traffic from CE1 is impacted. As a 558 result, PE1 needs to notify PE2 and CE1 about this problem. 560 If the AC Forward defect is detected by PE1, it must notify PE2 in 561 the form of a forward defect notification. 563 When NS OAM is not supported on PE1, and for PW over MPLS PSN or 564 MPLS-IP PSN, forward defect notification is done via either PW 565 Status message indicating a forward defect or via VCCV-BFD 566 diagnostic code of forward defect if VCCV CV type of 0x08 had been 567 negotiated. 569 When Native Service OAM mechanism is supported on PE1, it can also 570 use the NS OAM notification as specified in Section 3.1. 572 In addition to above actions, PE1 must perform the following: 574 - If PE1 is configured with a MEP associated with the local AC and 575 CCM transmission is configured to be turned ON, the MEP associated 576 with AC must set the RDI bit in transmitted CCM frames. 578 5.6 AC Forward Defect Exit Procedures 580 When AC status transitions from AC Forward defect to working, PE1's 581 ability to receive user traffic from CE1 is restored. As a result, 582 PE1 needs to cease defect notifications to PE2 and CE1 and perform 583 the following: 585 - When NS OAM is not supported on PE1 and for PW over MPLS PSN or 586 MPLS-IP PSN, forward defect notification is cleared via PW Status 587 message indicating a working state; or via VCCV-BFD diagnostic code 588 if VCCV CV type of 0x08 had been negotiated. 590 - When Native Service OAM mechanism is supported on PE1, PE1 clears 591 the NS OAM notification as specified in Section 3.1. 593 - If PE1 is configured with a MEP associated with the local AC and 594 CCM transmission is configured to be turned ON, the MEP associated 595 with the AC must clear the RDI bit in transmitted CCM frames to the 596 peer MEP in the client domain (e.g. on CE1). 598 5.7 AC Reverse Defect Entry Procedures 600 When AC status transitions from working to AC Reverse defect, PE1's 601 ability to transmit user traffic to CE1 is impacted. As a result, 602 PE1 needs to notify PE2 about this problem. 604 If the AC Reverse defect is detected by PE1, it must notify PE2 in 605 the form of a reverse defect notification. 607 When NS OAM is not supported on PE, in PW over MPLS PSN or MPLS-IP 608 PSN, reverse defect notification is either done via PW Status 609 message indicating a reverse defect; or via VCCV-BFD diagnostic code 610 of reverse defect if VCCV CV type of 0x08 had been negotiated. 612 When Native Service OAM mechanism is supported on PE, it can also 613 use the NS OAM notification as specified in Section 3.1. 615 5.8 AC Reverse Defect Exit Procedures 617 When AC status transitions from AC Reverse defect to working, PE1's 618 ability to transmit user traffic to CE1 is restored. As a result, 619 PE1 needs to clear notification to PE2. 621 If the AC Reverse defect is cleared, PE1 must clear reverse defect 622 notification to PE2. 624 When NS OAM is not supported on PE1 and for PW over MPLS PSN or 625 MPLS-IP PSN, reverse defect notification is cleared via either a PW 626 Status message indicating a working state or via VCCV-BFD diagnostic 627 code of if VCCV CV type of 0x08 had been negotiated. 629 When Native Service OAM mechanism is supported on PE1, PE1 can clear 630 NS OAM notification as specified in Section 3.1. 632 6. Acknowledgments 634 The authors are thankful to Samer Salam and Ray Qiu for their 635 comments. 637 7. IANA Considerations 639 This document has no actions for IANA. 641 8. Security Considerations 643 This document does not impose any security concerns since it makes 644 use of existing OAM mechanisms and mapping of these messages does 645 not change inherent security features. 647 9. References 649 9.1 Normative References 650 [Y.1731] "OAM Functions and mechanisms for Ethernet based networks", 651 ITU-T Y.1731, May 2006 653 [802.1ag] "Connectivity Fault Management", IEEE 802.1ag/D8.1, Jul 654 2007 656 [RFC4447] "Pseudowire Setup and Maintenance using LDP", RFC4447, 657 April 2006 659 [VCCV-BFD] "Bidirectional Forwarding Detection (BFD) for the 660 Pseudowire Virtual Circuit Connectivity Verification (VCCV)", 661 [RFC5085] "Pseudowire Virtual Circuit Connectivity Verification 662 (VCCV): A Control Channel for Pseudowires", RFC5085, December 2007 664 [802.3] "CDMA/CD access method and physical layer specifications", 665 Clause 57 for Operations, Administration and Maintenance, 2005 667 [MEF16] "Ethernet Local Management Interface", MEF16, January 2006 669 9.2 Informative References 671 [RFC3985] "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", 672 RFC 3985, March 2005 674 [PW-OAM-MSG-MAP] "Pseudo Wire (PW) OAM Message Mapping", draft-ietf- 675 pwe3-oam-msg-map-06.txt, Work in progress, March 2008 677 [MS-PW-ARCH] "An Architecture for Multi-Segment Pseudo Wire 678 Emulation Edge-to-Edge", draft-ietf-pwe3-ms-pw-arch-03.txt, Work in 679 progress, June 2007 681 Appendix A: Ethernet Native Service Management 683 Ethernet OAM mechanisms are broadly classified into two categories: 684 Fault Management (FM) and Performance Monitoring (PM). ITU-T Y.1731 685 provides coverage for both FM and PM while IEEE 802.1ag provides 686 coverage for a sub-set of FM functions. 688 Ethernet OAM also introduces the concept of Maintenance Entity (ME) 689 which is used to identify the entity that needs to be managed. A ME 690 is inherently a point-to-point association. However, in case of a 691 multipoint association, Maintenance Entity Group (MEG) consisting of 692 different MEs is used. IEEE 802.1 uses the concept of Maintenance 693 Association (MA) which is used to identify both point-to-point and 694 multipoint associations. Each MA consists of Maintenance End Points 695 (MEPs) which are responsible for originating OAM frames. In between 696 the MEPs, there can also be Maintenance Intermediate Points (MIPs) 697 which do not originate OAM frames however do respond to OAM frames 698 from MEPs. 700 Ethernet OAM allows for hierarchical maintenance entities to allow 701 for simultaneous end-to-end and segment monitoring. This is achieved 702 by having a provision of up to 8 Maintenance Domain Levels (MD 703 Levels) where each MEP or MIP is associated with a specific MD 704 Level. 706 It is important to note that the common set of FM mechanisms between 707 IEEE 802.1ag and ITU-T Y.1731 are completely compatible. 709 The common FM mechanisms include: 711 1) Continuity Check Messages (CCM) 712 2) Loopback Message (LBM) and Loopback Reply (LBR) 713 3) Linktrace Message (LTM) and Linktrace Reply (LTR) 715 CCM messages are used for fault detection including misconnections 716 and mis-configurations. Typically CCM messages are sent as multicast 717 frames or Unicast frames and also allow RDI notifications. LBM/LBR 718 are used to perform fault verification, while also allow for MTU 719 verification and CIR/EIR measurements. LTM/LTR can be used for 720 discovering the path traversed between a MEP and another target 721 MIP/MEP in the same MA. LTM/LTR also allow for fault localization. 723 In addition, ITU-T Y.1731 also specifies the following FM functions: 725 4) Alarm Indication Signal (AIS) 727 AIS allows for fault notification to downstream and upstream nodes. 729 Further, ITU-T Y.1731 also specifies the following PM functions: 731 5) Loss Measurement Message (LMM) and Reply (LMR) 732 6) Delay Measurement Message (DMR) and Reply (DMR) 733 7) 1-way Delay Message (1DM) 734 While LMM/LMR is used to measure Frame Loss Ratio (FLR), DMM/DMR is 735 used to measure single-ended (aka two-way) Frame Delay (FD) and 736 Frame Delay Variation (FDV, also known as Jitter). 1DM can be used 737 for dual-ended (aka one-way) FD and FDV measurements. 739 Authors' Addresses 741 Dinesh Mohan 742 Nortel 743 3500 Carling Ave 744 Ottawa, ON K2H8E9 745 Email: mohand@nortel.com 747 Nabil Bitar 748 Verizon Communications 749 117 West Street 750 Waltham, MA 02451 751 Email : nabil.n.bitar@verizon.com 753 Simon Delord 754 Uecomm 755 658 Church St 756 Richmond, VIC, 3121, Australia 757 E-mail: sdelord@uecomm.com.au 759 Philippe Niger 760 France Telecom 761 2 av. Pierre Marzin 762 22300 LANNION, France 763 E-mail: philippe.niger@francetelecom.com 765 Ali Sajassi 766 Cisco 767 170 West Tasman Drive 768 San Jose, CA 95134, US 769 Email: sajassi@cisco.com