idnits 2.17.1 draft-mohan-pwe3-mpls-eth-oam-iwk-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 796. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 742. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 749. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 755. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- 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) == Missing Reference: 'VCCV' is mentioned on line 314, but not defined == Missing Reference: 'MEF 16' is mentioned on line 545, but not defined == Unused Reference: 'RFC5085' is defined on line 654, 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. 'MEF16' -- No information found for draft-ietf-pwe3-oam-msp-map - is the name correct? == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-ms-pw-arch-03 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 9 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: July 7, 2008 S. Delord, Uecomm 6 Expiration Date: January 7, 2009 A. Sajassi (Editor), Cisco 8 MPLS and Ethernet OAM Interworking 9 draft-mohan-pwe3-mpls-eth-oam-iwk-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire in January 2009. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document specifies the mapping of defect states between 43 Ethernet Attachment Circuits (ACs) and associated Ethernet 44 Pseudowires (PWs) connected in accordance to the PWE3 architecture 45 [RFC3985] to realize an end-to-end emulated Ethernet service. This 46 document augments the mapping of defect states between a PW and 47 associated AC of the end-to-end emulated service in [PW-OAM-MSG- 48 MAP]. In [PW-OAM-MSG-MAP], Ethernet OAM was not covered due to lack 49 of Ethernet OAM maturity. However, since then, [Y.1731] and 50 [802.1ag] have been completed, and this document specifies the 51 mapping of defect states between Ethernet ACs and corresponding 52 Ethernet PWs. 54 Conventions used in this document 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in RFC 2119. 60 Table of Contents 62 Status of this Memo................................................1 63 Conventions used in this document..................................2 64 1. Introduction....................................................3 65 1.1. Reference Model and Defect Locations..........................4 66 1.2. Abstract Defect States........................................4 67 2. Terminology.....................................................6 68 3. PW Status and Defects...........................................6 69 3.1 Use of Native Service notification.............................6 70 3.2 Use of PW Status notification for MPLS PSNs....................7 71 3.3 Use of BFD Diagnostic Codes....................................7 72 4. Ethernet AC Defect States Entry or Exit Criteria................8 73 4.1 AC Forward Defect State Entry or Exit..........................8 74 4.2 AC Reverse Defect State Entry or Exit..........................8 75 5. Ethernet AC and PW Defect States Interworking...................9 76 5.1 PW Forward Defect Entry Procedures.............................9 77 5.2 PW Forward Defect Exit Procedures.............................10 78 5.3 PW Reverse Defect Entry Procedures............................11 79 5.4 PW Reverse Defect Exit Procedures.............................11 80 5.5 AC Forward Defect Entry Procedures............................12 81 5.6 AC Forward Defect Exit Procedures.............................12 82 5.7 AC Reverse Defect Entry Procedures............................12 83 5.8 AC Reverse Defect Exit Procedures.............................13 84 6. Acknowledgments................................................13 85 7. IANA Considerations............................................13 86 8. Security Considerations........................................13 87 9. References.....................................................13 88 9.1 Normative References..........................................13 89 9.2 Informative References........................................14 90 Appendix A: Ethernet Native Service Management....................14 91 Intellectual Property Statement...................................15 92 Authors' Addresses................................................16 93 Full Copyright Statement..........................................16 94 1. Introduction 96 This document specifies the mapping of defect states between 97 Ethernet Attachment Circuits (ACs) and associated Ethernet 98 Pseudowires (PWs) connected in accordance to the PWE3 architecture 99 [RFC3985] to realize an end-to-end emulated Ethernet service. This 100 document augments the mapping of defect states between a PW and 101 associated AC of the end-to-end emulated service in [PW-OAM-MSG- 102 MAP]. In [PW-OAM-MSG-MAP], Ethernet OAM was not covered due to lack 103 of Ethernet OAM maturity. However, since then, [Y.1731] and 104 [802.1ag] have been completed, and this document specifies the 105 mapping of defect states between Ethernet ACs and corresponding 106 Ethernet PWs. 108 Ethernet Link OAM [802.3] allows some Link defect states to be 109 detected and communicated across an Ethernet Link. When an Ethernet 110 AC is an Ethernet PHY, there may be some application of Ethernet 111 Link OAM [802.3]. Further, E-LMI [MEF16] also allows for some EVC 112 defect states to be communicated across an Ethernet UNI where 113 Ethernet UNI constitutes a single hop Ethernet Link (i.e. without 114 any 802.1Q/.1ad compliant bridges in between). There may be some 115 application of E-LMI [MEF16] for failure notification across single 116 hop Ethernet AC in certain deployments that specifically do not 117 support [802.1ag] and/or [Y.1731]. [Y.1731] and [802.1ag] based 118 mechanisms are applicable in all types of Ethernet ACs. Ethernet 119 Link OAM [802.3] and E-LMI [MEF16] are optional and their 120 applicability is called out, where applicable. 122 Native Service (NS) OAM may be transported transparently over the 123 corresponding PW as user data. For Ethernet, as an example, 802.1ag 124 continuity check messages (CCMs) between two Maintenance End Points 125 (MEPs) can be transported transparently as user data over the 126 corresponding PW. At MEP locations, service failure is detected when 127 a number of consecutive CCMs are missed. MEP locations can be the 128 PE, the CE or both with different Maintenance Domain Levels. 129 However, when interworking two networking domains, such as native 130 Ethernet and PWs to provide an end-to-end emulated service, there is 131 need to identify the failure domain and location even when a PE 132 supports both the NS OAM mechanisms and the PW OAM mechanisms. In 133 addition, scalability constraints may not allow running proactive 134 monitoring, such as CCMs with transmission on, at a PE to detect the 135 failure of an Ethernet Virtual circuit (EVC) across the PW domain. 136 Thus, network driven alarms generated upon failure detection in the 137 NS or PW domain and their mappings to the other domain are needed. 138 There are also cases where a PE may not be able to process NS OAM 139 messages received on the PW even when such messages are defined, as 140 in Ethernet case, necessitating the need for fault notification 141 message mapping between the PW domain and the Client domain. 143 For Multi-Segment PWs (MS-PWs) [MS-PW-ARCH], Switching PEs (S-PEs) 144 are not aware of the NS. Thus failure detection and notification at 145 S-PEs will be based on PW OAM mechanisms. Mapping between PW OAM and 146 NS OAM will be required at the Terminating PEs (T-PEs) to propagate 147 the failure notification to the EVC endpoints. 149 Similar to [PW-OAM-MSG-MAP], the intent of this document is to 150 standardize the behavior of PEs with respect to failures on Ethernet 151 ACs and PWs, so that there is no ambiguity about the alarms 152 generated and consequent actions undertaken by PEs in response to 153 specific failure conditions. 155 1.1. Reference Model and Defect Locations 157 Figure 1 is the same as used in [PW-OAM-MSG-MAP] and is reproduced 158 in this document as a reference to highlight defect locations. 160 ACs PSN tunnel ACs 161 +----+ +----+ 162 +----+ | PE1|==================| PE2| +----+ 163 | |---(a)---(b)..(c)......PW1..(d)..(c)..(f)---(e)---| | 164 | CE1| (N1) | | | | (N2) |CE2 | 165 | |----------|............PW2.............|----------| | 166 +----+ | |==================| | +----+ 167 ^ +----+ +----+ ^ 168 | Provider Edge 1 Provider Edge 2 | 169 | | 170 |<-------------- Emulated Service ---------------->| 172 Customer Customer 173 Edge 1 Edge 2 175 Figure 1: PWE3 Network Defect Locations 177 1.2. Abstract Defect States 179 Abstract Defect States are also introduced in [PW-OAM-MSG-MAP]. This 180 document uses the same conventions, as shown in Figure 2 from [PW- 181 OAM-MSG-MAP]. It may be noted however that CE devices, shown in 182 Figure 2, do not necessarily have to be end customer devices; these 183 are essentially devices in client network segments that are 184 connecting to PSN network for the emulated services. 186 +-----+ 187 ----AC forward---->| |-----PW reverse----> 188 CE1 | PE1 | PE2/CE2 189 <---AC reverse-----| |<----PW forward----- 190 +-----+ 192 (arrows indicate direction of user traffic impacted by a defect) 194 Figure 2: Forward and Reverse Defect States and Notifications 195 PE1 may detect a forward defect in local Ethernet AC via one of the 196 following mechanisms: 197 - An AIS alarm generated at an upstream node in the client domain 198 (CE1 in Figure 2) and received by a local MEP associated with the 199 local AC. 200 - Failure of the local link on which the AC is configured. Link 201 failure may be detected via physical failures e.g. loss of signal 202 (LoS), or via Ethernet Link OAM [802.3] critical link event 203 notifications generated at an upstream node CE1 with "Dying Gasp" 204 or "Critical Event" indication. 205 - Failure to receive CCMs on the AC if a local MEP is configured for 206 the AC. 208 AC forward defect impacts the ability of PE1 to receive user traffic 209 from the Client domain. 211 Similarly, PE1 may detect a forward defect in the PW via one of the 212 following mechanisms: 213 - Forward Defect indication received from PE2. This defect 214 indication could point to problems associated with PE2's inability 215 to transmit traffic on the PW or PE2's inability to receive traffic 216 on its local AC. 217 - Unavailability of a PSN path in the PW domain to PE2. 219 PW forward defect received on PE1 impacts the ability of PE1 to 220 receive traffic on the PW. 222 PE1 may be notified of an AC reverse defect via one of the following 223 mechanisms: 224 - CCMs with RDI (Remote Defect Indication) bit set. 225 - In case when the AC is associated with a physical port, failure of 226 the local link on which the AC is configured (e.g. via Ethernet 227 Link OAM [802.3] critical link event notifications generated at an 228 upstream node CE1 with "Link Fault" indication). 230 AC reverse defect impacts the ability of PE1 to send user traffic on 231 the local AC. 233 Similarly, PE1 may be notified of a PW reverse defect via Reverse 234 Defect indication from PE2, which could point to problems associated 235 with PE2's inability to receive traffic on the PW or PE2's inability 236 to transmit traffic on its local AC. PW reverse defect impacts PE1 237 ability to send user traffic to CE2. 239 The procedures outlined in this document define the entry and exit 240 criteria for each of the four defect states with respect to Ethernet 241 ACs and corresponding PWs, and the consequent actions that PE1 must 242 support to properly interwork these defect states and corresponding 243 notification messages between the PW domain and the Native Service 244 (NS) domain. Forward defect state should have precedence over 245 reverse defect state in terms of handling, when both forward and 246 reverse defect states are identified simultaneously. 248 2. Terminology 250 This document uses the following terms. 252 AIS Alarm Indication Signal 253 MD Level Maintenance Domain (MD) Level which identifies a value 254 in the range of 0-7 associated with Ethernet OAM frame. 255 MD Level identifies the span of the Ethernet OAM frame. 256 MEP Maintenance End Point is responsible for origination 257 and termination of OAM frames for a given MEG 258 MIP Maintenance Intermediate Point is located between peer 259 MEPs and can process OAM frames but does not initiate 260 or terminate them 261 RDI Remote Defect Indication 263 Further, this document also uses the terminology and conventions 264 used in [PW-OAM-MSG-MAP]. 266 3. PW Status and Defects 268 [PW-OAM-MSG-MAP] introduces a range of defects that impact PW 269 status. All these defect conditions are applicable for Ethernet PWs. 271 Similarly, there are different mechanisms described in [PW-OAM-MSG- 272 MAP] to detect PW defects, depending on the PSN type (e.g. MPLS PSN, 273 MPLS-IP PSN). Any of these mechanisms can be used when monitoring 274 the state of Ethernet PWs. [PW-OAM-MSG-MAP] also discusses the 275 applicability of these failure detection mechanisms. 277 3.1 Use of Native Service notification 279 There is no NS fault notification capability currently specified for 280 Ethernet PWs. However, with the completion of Ethernet OAM work, 281 this capability should be added. This includes the ability to create 282 a MEP associated with the Ethernet PW on the PE. The native service 283 notification options include: 285 - AIS Frames sent by the local MEP to the MEP on the remote PE when 286 the MEP needs to convey PE forward defects, and when CCM 287 transmission is configured not to be turned ON. 288 - Suspension of CCM frames transmission from the MEP to the peer MEP 289 on the other PE to convey PE forward defects, when CCM 290 transmission is configured to be turned ON. 291 - RDI in transmitted CCM frames, when loss of CCMs from the peer MEP 292 is detected or PE needs to convey PW reverse defects. 294 These NS OAM notifications are inserted into the corresponding PW. 296 Similarly, when the defect conditions are cleared, a PE can take one 297 of the following actions, depending on the mechanism that was used 298 for failure notification, to clear the defect sate on the peer PE: 300 - Stop AIS Frame transmission from the local MEP to the MEP on the 301 remote PE to clear PW forward defects; 302 - Resuming CCM frames transmission from the MEP to the peer MEP to 303 clear PW forward defects notification, when CCM transmission is 304 configured to be turned ON. 305 - Clearing RDI indication in transmitted CCM frames, to clear PW 306 reverse defects notification. 308 3.2 Use of PW Status notification for MPLS PSNs 310 When PWs are established using LDP, LDP status notification 311 signaling SHOULD be used as the default mechanism to signal AC and 312 PW status and defects [RFC4447]. For PWs established over an MPLS or 313 MPLS-IP PSN using other mechanisms (e.g. static configuration), 314 inband signaling using VCCV-BFD [VCCV] SHOULD be used to convey AC 315 and PW status and defects. 317 [PW-OAM-MSG-MAP] identifies the following PW defect status 318 codepoints: 319 - Forward defect: corresponds to a logical OR of local AC (ingress) 320 Receive fault AND local PSN-facing PW (egress) transmit fault. 321 - Reverse defect: corresponds to a logical OR of local AC (egress) 322 transmit fault and local PW PSN-facing (ingress) receive fault. 324 There are also scenarios where a PE carries out PW label withdrawal 325 instead of PW status notification. These include administrative 326 disablement of the PW or loss of Target LDP session with the peer 327 PE. 329 3.3 Use of BFD Diagnostic Codes 331 When using VCCV, the control channel (CC) type and Connectivity 332 Verification (CV) Type are agreed on between the peer PEs using the 333 OAM capability sub-TLV signaled as part of the interface parameter 334 TLV when using FEC 129 and the interface parameter sub-TLV when 335 using FEC 128. 337 As defined in [PW-OAM-MSG-MAP], when CV type of 0x04 is used to 338 indicate that BFD is used for PW fault detection only, PW defect is 339 detected via the BFD session while other defects, such as AC defects 340 or PE internal defects preventing it from forwarding traffic, are 341 communicated via LDP Status notification message in MPLS and MPLS-IP 342 PSN or other mechanisms in L2TP-IP PSN. 344 Similarly, when CV type of 0x08 is used to indicate that BFD is used 345 for both PW fault detection and AC/PW Fault Notification, all 346 defects are signaled via BFD. 348 4. Ethernet AC Defect States Entry or Exit Criteria 350 4.1 AC Forward Defect State Entry or Exit 352 PE1 enters the AC forward defect state if any of the following 353 conditions are met: 355 - It detects or is notified of a physical layer fault on the 356 Ethernet interface. Ethernet link failure can be detected based on 357 loss of signal (LoS) or via Ethernet Link OAM [802.3] critical 358 link event notifications generated at an upstream node CE1 with 359 "Dying Gasp" or "Critical Event" indication. 360 - A MEP associated with the local AC receives an Ethernet AIS frame. 361 - A MEP associated with the local AC does not receive CCM frames 362 from the peer MEP in the client domain (e.g. CE1) within a 363 configurable interval equal to a multiple (e.g. 3.5) of the CCM 364 transmission period configured for the MEP. This is the case when 365 CCM transmission is configured to be turned ON. 367 PE1 exits the AC forward defect state if all of the conditions that 368 resulted in entering the defect state are cleared. This includes all 369 of the following conditions: 371 - Any physical layer fault on the Ethernet interface, if detected or 372 notified previously, is removed (e.g. via loss of signal (LoS), or 373 Ethernet Link OAM [802.3] critical link event notifications with 374 "Dying Gasp" or "Critical Event" indication cleared at an upstream 375 node CE1). 376 - A MEP associated with the local AC does not receive any Ethernet 377 AIS frame within a period indicated by previously received AIS, if 378 AIS was resulted in entering the defect state. 379 - A MEP associated with the local AC and configured with CCM 380 transmission on receives a configured number (e.g. 3 or more) of 381 consecutive CCM frames from the peer MEP on CE1 within an interval 382 equal to a multiple (e.g. 3.5) of the CCM transmission period 383 configured for the MEP. 385 4.2 AC Reverse Defect State Entry or Exit 387 PE1 enters the AC reverse defect state if any of the following 388 condition is met: 390 - It detects or is notified of a physical layer fault on the 391 Ethernet interface (e.g. via loss of signal (LoS) or Ethernet Link 392 OAM [802.3] critical link event notifications generated at an 393 upstream node CE1 with "Link Fault" indication). 394 - A MEP configured with CCM transmission turned ON and associated 395 with the local AC receives a CCM frame, with its RDI bit set, from 396 peer MEP in the client domain (e.g. CE1). 398 PE1 exits the AC reverse defect state if all of the conditions that 399 resulted in entering the defect state are cleared. This includes all 400 of the following conditions: 402 - Any physical layer fault on the Ethernet interface, if detected or 403 notified previously, is removed (e.g. via Ethernet Link OAM 404 [802.3] critical link event notifications with "Link Fault" 405 indication cleared at an upstream node CE1). 406 - A MEP configured with CCM transmission turned ON and associated 407 with the local AC does not receive a CCM frame with RDI bit set, 408 having received a previous CCM frame with RDI bit set from the 409 peer MEP in the client domain (e.g. CE1). 411 5. Ethernet AC and PW Defect States Interworking 413 5.1 PW Forward Defect Entry Procedures 415 When the PW status on PE1 transitions from working to PW forward 416 defect state; PE1's ability to receive user traffic from CE2 is 417 impacted. As a result, PE1 needs to notify CE1 about this problem. 419 Upon entry to the PW Forward Defect State, the following must be 420 done: 422 - If PE1 is configured with a MEP associated with the local AC and 423 CCM transmission is not configured to be turned ON, the MEP 424 associated with the AC must transmit AIS frames periodically to the 425 MEP in the client domain (e.g. on CE1) based on configured AIS 426 transmission period. 428 - If PE1 is configured with a MEP associated with the local AC and 429 CCM transmission is configured to be turned ON, and the MEP 430 associated with the AC is configured to support Interface Status TLV 431 in CCM messages, the MEP associated with the AC must transmit CCM 432 frames with Interface Status TLV as being down to the peer MEP in 433 the client domain (e.g. on CE1). 435 - If PE1 is configured with a MEP associated with the local AC and 436 CCM transmission is configured to be turned ON, and the MEP 437 associated with the AC is configured to not support Interface Status 438 TLV in CCM messages, the MEP associated with the AC must stop 439 transmitting CCM frames to the peer MEP in the client domain (e.g. 440 on CE1). 442 - If PE1 is configured to run E-LMI [MEF 16] with CE1 and if E-LMI 443 is used for failure notification, PE1 must transmit E-LMI 444 asynchronous STATUS message with report type Single EVC Asynchronous 445 Status indicating that PW is Not Active. 447 Further, when PE1 enters the forward defect state, it must assume 448 that PE2 has no knowledge of the defect and must send reverse defect 449 failure notification to PE2. For MPLS PSN or MPLS-IP PSN, this is 450 done via either a PW Status notification message indicating a 451 reverse defect; or via VCCV-BFD diagnostic code of reverse defect if 452 VCCV CV type of 0x08 had been negotiated. When Native Service OAM 453 mechanism is supported on PE, it can also use the NS OAM 454 notification as specified in Section 3.1. 456 If PW forward defect is entered as a result of a forward defect 457 notification from PE2 or via loss of control adjacency, no 458 additional action is needed since PE2 is expected to be aware of the 459 defect. 461 Note: The location of the MEP associated with the local AC within a 462 PE can be a down MEP on the port associated with the AC or an Up MEP 463 associated with an emulated LAN interface within the PE, as defined 464 in L2VPN framework for a VPLS PE. Though for the purposes of VPWS 465 service, VPLS PE architecture is not mandatory, the VPLS PE 466 architecture serves as a generic case where the PE can support both 467 VPWS and VPLS services. 469 5.2 PW Forward Defect Exit Procedures 471 When the PW status transitions from PW forward defect state to 472 working, PE1's ability to receive user traffic from CE2 is restored. 473 As a result, PE1 needs to cease defect notification to CE1 by 474 performing the following: 476 - If PE1 is configured with a a MEP associated with the local AC and 477 CCM transmission is not configured to be turned ON, the MEP 478 associated with the AC must stop transmitting AIS frames towards the 479 peer MEP in the client domain (e.g. on CE1). 481 - If PE1 is configured with a MEP associated with the local AC and 482 CCM transmission is configured to be turned ON, and the MEP 483 associated with the AC is configured to support Interface Status TLV 484 in CCM messages, the MEP associated with the AC must transmit CCM 485 frames with Interface Status TLV as being Up to the peer MEP in the 486 client domain (e.g. on CE1). 488 - If PE1 is configured with a MEP associated with the local AC and 489 CCM transmission is configured to be turned ON, and the MEP 490 associated with the AC is configured to not support Interface Status 491 TLV in CCM messages, the MEP associated with the AC must resume 492 transmitting CCM frames to the peer MEP in the client domain (e.g. 493 on CE1). 495 - If PE1 is configured to run E-LMI [MEF 16] with CE1 and E-LMI is 496 used for fault notification, PE1 must transmit E-LMI asynchronous 497 STATUS message with report type Single EVC Asynchronous Status 498 indicating that PW is Active. 500 Further, if the PW forward defect was explicitly detected by PE1, it 501 must now notify PE2 about clearing of forward defect state by 502 clearing reverse defect notification. For PWs over MPLS PSN or MPLS- 503 IP PSN, this is either done via PW Status message indicating 504 working; or via VCCV-BFD diagnostic code if VCCV CV type of 0x08 had 505 been negotiated. When Native Service OAM mechanism is supported on 506 PE, it can also clear the NS OAM notification specified in Section 507 3.1. 509 If PW forward defect was established via notification from PE2 or 510 via loss of control adjacency, no additional action is needed, since 511 PE2 is expected to be aware of the defect clearing. 513 5.3 PW Reverse Defect Entry Procedures 515 When the PW status transitions from working to PW reverse defect 516 state, PE1's ability to transmit user traffic to CE2 is impacted. As 517 a result, PE needs to notify CE1 about this problem which has been 518 detected by PE1. 520 Upon entry to the PW Reverse Defect State, the following must be 521 done: 523 - If PE1 is configured with a MEP associated with the local AC and 524 CCM transmission is configured to be turned ON, the MEP associated 525 with the AC must set the RDI bit in transmitted CCM frames sent to 526 the peer MEP in the client domain (e.g. on CE1). 528 - If PE1 is configured to run E-LMI [MEF 16] with CE1 and E-LMI is 529 used for fault notification, PE1 must transmit E-LMI asynchronous 530 STATUS message with report type Single EVC Asynchronous Status 531 indicating that PW is Not Active. 533 5.4 PW Reverse Defect Exit Procedures 535 When the PW status transitions from PW reverse defect state to 536 working, PE1's ability to transmit user traffic to CE2 is restored. 537 As a result, PE1 needs to cease defect notifications to CE1 and 538 perform the following 540 - If PE1 is configured with a MEP associated with the local AC and 541 CCM transmission is configured to be turned ON, the MEP associated 542 with the AC must clear the RDI bit in the transmitted CCM frames to 543 the peer MEP (e.g. on CE1). 545 - If PE1 is configured to run E-LMI [MEF 16] with CE1, PE1 must 546 transmit E-LMI asynchronous STATUS message with report type Single 547 EVC Asynchronous Status indicating that PW is Active. 549 5.5 AC Forward Defect Entry Procedures 551 When AC status transitions from working to AC Forward defect state, 552 PE1's ability to receive user traffic from CE1 is impacted. As a 553 result, PE1 needs to notify PE2 and CE1 about this problem. 555 If the AC Forward defect is detected by PE1, it must notify PE2 in 556 the form of a forward defect notification. 558 When NS OAM is not supported on PE1, and for PW over MPLS PSN or 559 MPLS-IP PSN, forward defect notification is done via either PW 560 Status message indicating a forward defect or via VCCV-BFD 561 diagnostic code of forward defect if VCCV CV type of 0x08 had been 562 negotiated. 564 When Native Service OAM mechanism is supported on PE1, it can also 565 use the NS OAM notification as specified in Section 3.1. 567 In addition to above actions, PE1 must perform the following: 569 - If PE1 is configured with a MEP associated with the local AC and 570 CCM transmission is configured to be turned ON, the MEP associated 571 with AC must set the RDI bit in transmitted CCM frames. 573 5.6 AC Forward Defect Exit Procedures 575 When AC status transitions from AC Forward defect to working, PE1's 576 ability to receive user traffic from CE1 is restored. As a result, 577 PE1 needs to cease defect notifications to PE2 and CE1 and perform 578 the following: 580 - When NS OAM is not supported on PE1 and for PW over MPLS PSN or 581 MPLS-IP PSN, forward defect notification is cleared via PW Status 582 message indicating a working state; or via VCCV-BFD diagnostic code 583 if VCCV CV type of 0x08 had been negotiated. 585 - When Native Service OAM mechanism is supported on PE1, PE1 clears 586 the NS OAM notification as specified in Section 3.1. 588 - If PE1 is configured with a MEP associated with the local AC and 589 CCM transmission is configured to be turned ON, the MEP associated 590 with the AC must clear the RDI bit in transmitted CCM frames to the 591 peer MEP in the client domain (e.g. on CE1). 593 5.7 AC Reverse Defect Entry Procedures 595 When AC status transitions from working to AC Reverse defect, PE1's 596 ability to transmit user traffic to CE1 is impacted. As a result, 597 PE1 needs to notify PE2 about this problem. 599 If the AC Reverse defect is detected by PE1, it must notify PE2 in 600 the form of a reverse defect notification. 602 When NS OAM is not supported on PE, in PW over MPLS PSN or MPLS-IP 603 PSN, reverse defect notification is either done via PW Status 604 message indicating a reverse defect; or via VCCV-BFD diagnostic code 605 of reverse defect if VCCV CV type of 0x08 had been negotiated. 607 When Native Service OAM mechanism is supported on PE, it can also 608 use the NS OAM notification as specified in Section 3.1. 610 5.8 AC Reverse Defect Exit Procedures 612 When AC status transitions from AC Reverse defect to working, PE1's 613 ability to transmit user traffic to CE1 is restored. As a result, 614 PE1 needs to clear notification to PE2. 616 If the AC Reverse defect is cleared, PE1 must clear reverse defect 617 notification to PE2. 619 When NS OAM is not supported on PE1 and for PW over MPLS PSN or 620 MPLS-IP PSN, reverse defect notification is cleared via either a PW 621 Status message indicating a working state or via VCCV-BFD diagnostic 622 code of if VCCV CV type of 0x08 had been negotiated. 624 When Native Service OAM mechanism is supported on PE1, PE1 can clear 625 NS OAM notification as specified in Section 3.1. 627 6. Acknowledgments 629 The authors are thankful to Samer Salam and Ray Qiu for their 630 comments. 632 7. IANA Considerations 634 This document has no actions for IANA. 636 8. Security Considerations 638 This document does not impose any security concerns since it makes 639 use of existing OAM mechanisms and mapping of these messages does 640 not change inherent security features. 642 9. References 644 9.1 Normative References 645 [Y.1731] "OAM Functions and mechanisms for Ethernet based networks", 646 ITU-T Y.1731, May 2006 648 [802.1ag] "Connectivity Fault Management", IEEE 802.1ag/D8.1, Jul 649 2007 651 [RFC4447] "Pseudowire Setup and Maintenance using LDP", RFC4447, 652 April 2006 654 [RFC5085] "Pseudowire Virtual Circuit Connectivity Verification 655 (VCCV): A Control Channel for Pseudowires", RFC5085, December 2007 657 [802.3] "CDMA/CD access method and physical layer specifications", 658 Clause 57 for Operations, Administration and Maintenance, 2005 660 [MEF16] "Ethernet Local Management Interface", MEF16, January 2006 662 9.2 Informative References 664 [RFC3985] "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", 665 RFC 3985, Mar 2005 667 [PW-OAM-MSG-MAP] "Pseudo Wire (PW) OAM Message Mapping", draft-ietf- 668 pwe3-oam-msp-map-06.txt, Work in progress, Mar 2008 670 [MS-PW-ARCH] "An Architecture for Multi-Segment Pseudo Wire 671 Emulation Edge-to-Edge", draft-ietf-pwe3-ms-pw-arch-03.txt, Work in 672 progress, Jun 2007 674 Appendix A: Ethernet Native Service Management 676 Ethernet OAM mechanisms are broadly classified into two categories: 677 Fault Management (FM) and Performance Monitoring (PM). ITU-T Y.1731 678 provides coverage for both FM and PM while IEEE 802.1ag provides 679 coverage for a sub-set of FM functions. 681 Ethernet OAM also introduces the concept of Maintenance Entity (ME) 682 which is used to identify the entity that needs to be managed. A ME 683 is inherently a point-to-point association. However, in case of a 684 multipoint association, Maintenance Entity Group (MEG) consisting of 685 different MEs is used. IEEE 802.1 uses the concept of Maintenance 686 Association (MA) which is used to identify both point-to-point and 687 multipoint associations. Each MA consists of Maintenance End Points 688 (MEPs) which are responsible for originating OAM frames. In between 689 the MEPs, there can also be Maintenance Intermediate Points (MIPs) 690 which do not originate OAM frames however do respond to OAM frames 691 from MEPs. 693 Ethernet OAM allows for hierarchical maintenance entities to allow 694 for simultaneous end-to-end and segment monitoring. This is achieved 695 by having a provision of up to 8 Maintenance Domain Levels (MD 696 Levels) where each MEP or MIP is associated with a specific MD 697 Level. 699 It is important to note that the common set of FM mechanisms between 700 IEEE 802.1ag and ITU-T Y.1731 are completely compatible. 702 The common FM mechanisms include: 704 1) Continuity Check Messages (CCM) 705 2) Loopback Message (LBM) and Loopback Reply (LBR) 706 3) Linktrace Message (LTM) and Linktrace Reply (LTR) 708 CCM messages are used for fault detection including misconnections 709 and mis-configurations. Typically CCM messages are sent as multicast 710 frames or Unicast frames and also allow RDI notifications. LBM/LBR 711 are used to perform fault verification, while also allow for MTU 712 verification and CIR/EIR measurements. LTM/LTR can be used for 713 discovering the path traversed between a MEP and another target 714 MIP/MEP in the same MA. LTM/LTR also allow for fault localization. 716 In addition, ITU-T Y.1731 also specifies the following FM functions: 718 4) Alarm Indication Signal (AIS) 720 AIS allows for fault notification to downstream and upstream nodes. 722 Further, ITU-T Y.1731 also specifies the following PM functions: 724 5) Loss Measurement Message (LMM) and Reply (LMR) 725 6) Delay Measurement Message (DMR) and Reply (DMR) 726 7) 1-way Delay Message (1DM) 728 While LMM/LMR is used to measure Frame Loss Ratio (FLR), DMM/DMR is 729 used to measure single-ended (aka two-way) Frame Delay (FD) and 730 Frame Delay Variation (FDV, also known as Jitter). 1DM can be used 731 for dual-ended (aka one-way) FD and FDV measurements. 733 Intellectual Property Statement 735 The IETF takes no position regarding the validity or scope of any 736 Intellectual Property Rights or other rights that might be claimed 737 to pertain to the implementation or use of the technology described 738 in this document or the extent to which any license under such 739 rights might or might not be available; nor does it represent that 740 it has made any independent effort to identify any such rights. 741 Information on the procedures with respect to rights in RFC 742 documents can be found in BCP 78 and BCP 79. 744 Copies of IPR disclosures made to the IETF Secretariat and any 745 assurances of licenses to be made available, or the result of an 746 attempt made to obtain a general license or permission for the use 747 of such proprietary rights by implementers or users of this 748 specification can be obtained from the IETF on-line IPR repository 749 at http://www.ietf.org/ipr. 751 The IETF invites any interested party to bring to its attention any 752 copyrights, patents or patent applications, or other proprietary 753 rights that may cover technology that may be required to implement 754 this standard. Please address the information to the IETF at ietf- 755 ipr@ietf.org. 757 Authors' Addresses 759 Dinesh Mohan 760 Nortel 761 3500 Carling Ave 762 Ottawa, ON K2H8E9 763 Email: mohand@nortel.com 765 Nabil Bitar 766 Verizon Communications 767 Email : nabil.n.bitar@verizon.com 769 Simon Delord 770 Uecomm 771 658 Church St 772 Richmond, VIC, 3121, Australia 773 E-mail: sdelord@uecomm.com.au 775 Philippe Niger 776 France Telecom 777 2 av. Pierre Marzin 778 22300 LANNION, France 779 E-mail: philippe.niger@francetelecom.com 781 Full Copyright Statement 783 Copyright (C) The IETF Trust (2008). 785 This document is subject to the rights, licenses and restrictions 786 contained in BCP 78, and except as set forth therein, the authors 787 retain all their rights. 789 This document and the information contained herein are provided on 790 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 791 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 792 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 793 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 794 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 795 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 796 FOR A PARTICULAR PURPOSE.