idnits 2.17.1 draft-ietf-pwe3-oam-msg-map-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 21, 2011) is 4754 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) -- Possible downref: Non-RFC (?) normative reference: ref. 'G.707' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.775' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.783' == Outdated reference: A later version (-08) exists of draft-ietf-pwe3-mpls-eth-oam-iwk-04 == Outdated reference: A later version (-10) exists of draft-ietf-pwe3-static-pw-status-03 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PWE3 M. Aissaoui 3 Internet-Draft P. Busschbach 4 Intended status: Standards Track Alcatel-Lucent 5 Expires: October 21, 2011 L. Martini 6 M. Morrow 7 Cisco Systems, Inc. 8 T. Nadeau 9 CA Technologies 10 Y(J). Stein 11 RAD Data Communications 12 April 21, 2011 14 Pseudowire (PW) OAM Message Mapping 15 draft-ietf-pwe3-oam-msg-map-16.txt 17 Abstract 19 This document specifies the mapping and notification of defect states 20 between a pseudowire (PW) and the Attachment Circuits (ACs) of the 21 end-to-end emulated service. It standardizes the behavior of 22 Provider Edges (PEs) with respect to PW and AC defects. It addresses 23 ATM, frame relay, TDM, and SONET/SDH PW services, carried over MPLS, 24 MPLS/IP and L2TPv3/IP Packet Switched Networks (PSNs). 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 21, 2011. 43 Copyright Notice 45 Copyright (c) 2011 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Abbreviations and Conventions . . . . . . . . . . . . . . . . 5 74 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 75 2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 76 3. Reference Model and Defect Locations . . . . . . . . . . . . . 7 77 4. Abstract Defect States . . . . . . . . . . . . . . . . . . . . 8 78 5. OAM Modes . . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 6. PW Defect States and Defect Notifications . . . . . . . . . . 11 80 6.1. PW Defect Notification Mechanisms . . . . . . . . . . . . 11 81 6.1.1. LDP Status TLV . . . . . . . . . . . . . . . . . . . . 12 82 6.1.2. L2TP Circuit Status AVP . . . . . . . . . . . . . . . 14 83 6.1.3. BFD Diagnostic Codes . . . . . . . . . . . . . . . . . 15 84 6.2. PW Defect State Entry/Exit . . . . . . . . . . . . . . . . 17 85 6.2.1. PW receive defect state entry/exit criteria . . . . . 17 86 6.2.2. PW transmit defect state entry/exit criteria . . . . . 18 87 7. Procedures for ATM PW Service . . . . . . . . . . . . . . . . 18 88 7.1. AC receive defect state entry/exit criteria . . . . . . . 18 89 7.2. AC transmit defect state entry/exit criteria . . . . . . . 19 90 7.3. Consequent Actions . . . . . . . . . . . . . . . . . . . . 20 91 7.3.1. PW receive defect state entry/exit . . . . . . . . . . 20 92 7.3.2. PW transmit defect state entry/exit . . . . . . . . . 20 93 7.3.3. PW defect state in ATM Port Mode PW Service . . . . . 20 94 7.3.4. AC receive defect state entry/exit . . . . . . . . . . 21 95 7.3.5. AC transmit defect state entry/exit . . . . . . . . . 22 97 8. Procedures for Frame Relay PW Service . . . . . . . . . . . . 22 98 8.1. AC receive defect state entry/exit criteria . . . . . . . 22 99 8.2. AC transmit defect state entry/exit criteria . . . . . . . 23 100 8.3. Consequent Actions . . . . . . . . . . . . . . . . . . . . 23 101 8.3.1. PW receive defect state entry/exit . . . . . . . . . . 23 102 8.3.2. PW transmit defect state entry/exit . . . . . . . . . 23 103 8.3.3. PW defect state in the FR Port Mode PW Service . . . . 24 104 8.3.4. AC receive defect state entry/exit . . . . . . . . . . 24 105 8.3.5. AC transmit defect state entry/exit . . . . . . . . . 24 106 9. Procedures for TDM PW Service . . . . . . . . . . . . . . . . 24 107 9.1. AC receive defect state entry/exit criteria . . . . . . . 25 108 9.2. AC transmit defect state entry/exit criteria . . . . . . . 25 109 9.3. Consequent Actions . . . . . . . . . . . . . . . . . . . . 25 110 9.3.1. PW receive defect state entry/exit . . . . . . . . . . 25 111 9.3.2. PW transmit defect state entry/exit . . . . . . . . . 26 112 9.3.3. AC receive defect state entry/exit . . . . . . . . . . 26 113 10. Procedures for CEP PW Service . . . . . . . . . . . . . . . . 26 114 10.1. Defect states . . . . . . . . . . . . . . . . . . . . . . 27 115 10.1.1. PW receive defect state entry/exit . . . . . . . . . . 27 116 10.1.2. PW transmit defect state entry/exit . . . . . . . . . 27 117 10.1.3. AC receive defect state entry/exit . . . . . . . . . . 27 118 10.1.4. AC transmit defect state entry/exit . . . . . . . . . 28 119 10.2. Consequent Actions . . . . . . . . . . . . . . . . . . . . 28 120 10.2.1. PW receive defect state entry/exit . . . . . . . . . . 28 121 10.2.2. PW transmit defect state entry/exit . . . . . . . . . 28 122 10.2.3. AC receive defect state entry/exit . . . . . . . . . . 28 123 11. Security Considerations . . . . . . . . . . . . . . . . . . . 29 124 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 125 13. Contributors and Acknowledgments . . . . . . . . . . . . . . . 30 126 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 127 14.1. Normative References . . . . . . . . . . . . . . . . . . . 30 128 14.2. Informative References . . . . . . . . . . . . . . . . . . 33 129 Appendix A. Native Service Management (informative) . . . . . . . 35 130 A.1. Frame Relay Management . . . . . . . . . . . . . . . . . . 35 131 A.2. ATM Management . . . . . . . . . . . . . . . . . . . . . . 35 132 Appendix B. PW Defects and Detection tools . . . . . . . . . . . 37 133 B.1. PW Defects . . . . . . . . . . . . . . . . . . . . . . . . 37 134 B.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 37 135 B.3. PW Defect Detection Tools . . . . . . . . . . . . . . . . 37 136 B.4. PW specific defect detection mechanisms . . . . . . . . . 38 137 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 139 1. Introduction 141 This document specifies the mapping and notification of defect states 142 between a Pseudowire and the Attachment Circuits (AC) of the end-to- 143 end emulated service. It covers the case where the ACs and the PWs 144 are of the same type in accordance to the PWE3 architecture [RFC3985] 145 such that a homogeneous PW service can be constructed. 147 This document is motivated by the requirements put forth in [RFC4377] 148 and [RFC3916]. Its objective is to standardize the behavior of PEs 149 with respect to defects on PWs and ACs, so that there is no ambiguity 150 about the alarms generated and consequent actions undertaken by PEs 151 in response to specific failure conditions. 153 This document addresses PWs over MPLS, MPLS/IP and L2TPv3/IP PSNs, 154 and ATM, frame relay, TDM, and SONET/SDH PW native services. Due to 155 its unique characteristics, the Ethernet PW service is covered in a 156 separate document [I-D.ietf-pwe3-mpls-eth-oam-iwk]. 158 This document provides procedures for PWs set up using LDP [RFC4447] 159 or L2TPv3 [RFC3931] control protocols. While we mention fault 160 reporting options for PWs established by other means (e.g., by static 161 configuration or via BGP), we do not provide detailed procedures for 162 such cases. 164 This document is scoped only to single segment PWs. The mechanisms 165 described in this document could also be applied to T-PEs for MS-PWs 166 ([RFC5254]). Section 10 of [RFC6073] details procedures for 167 generating or relaying PW status by an S-PE. 169 2. Abbreviations and Conventions 171 2.1. Abbreviations 173 AAL5 ATM Adaptation Layer 5 174 AIS Alarm Indication Signal 175 AC Attachment Circuit 176 ATM Asynchronous Transfer Mode 177 AVP Attribute Value Pair 178 BFD Bidirectional Forwarding Detection 179 CC Continuity Check 180 CDN Call Disconnect Notify 181 CE Customer Edge 182 CV Connectivity Verification 183 DBA Dynamic Bandwidth Allocation 184 DLC Data Link Connection 185 FDI Forward Defect Indication 186 FR Frame Relay 187 FRBS Frame Relay Bearer Service 188 ICMP Internet Control Message Protocol 189 LB Loopback 190 LCCE L2TP Control Connection Endpoint 191 LDP Label Distribution Protocol 192 LSP Label Switched Path 193 L2TP Layer 2 Tunneling Protocol 194 MPLS Multiprotocol Label Switching 195 NE Network Element 196 NS Native Service 197 OAM Operations, Administration, and Maintenance 198 PE Provider Edge 199 PSN Packet Switched Network 200 PW Pseudowire 201 RDI Remote Defect Indication 202 PDU Protocol Data Unit 203 SDH Synchronous Digital Hierarchy 204 SDU Service Data Unit 205 SONET Synchronous Optical Network 206 TDM Time Division Multiplexing 207 TLV Type Length Value 208 VCC Virtual Channel Connection 209 VCCV Virtual Connection Connectivity Verification 210 VPC Virtual Path Connection 212 2.2. Conventions 214 The words "defect" and "fault" are used interchangeably to mean any 215 condition that negatively impacts forwarding of user traffic between 216 the CE endpoints of the PW service. 218 The words "defect notification" and "defect indication" are used 219 interchangeably to mean any OAM message generated by a PE and sent to 220 other nodes in the network to convey the defect state local to this 221 PE. 223 The PW can be carried over three types of Packet Switched Networks 224 (PSNs). An "MPLS PSN" makes use of MPLS Label Switched Paths 225 [RFC3031] as the tunneling technology to forward the PW packets. An 226 "MPLS/IP PSN" makes use of MPLS-in-IP tunneling [RFC4023], with an 227 MPLS shim header used as PW demultiplexer. An "L2TPv3/IP PSN" makes 228 use of L2TPv3/IP [RFC3931] as the tunneling technology with the 229 L2TPv3/IP Session ID as the PW demultiplexer. 231 If LSP-Ping [RFC4379] is run over a PW as described in [RFC5085], it 232 will be referred to as "VCCV-Ping". If BFD is run over a PW as 233 described in [RFC5885], it will be referred to as "VCCV-BFD". 235 While PWs are inherently bidirectional entities, defects and OAM 236 messaging are related to a specific traffic direction. We use the 237 terms "upstream" and "downstream" to identify PEs in relation to the 238 traffic direction. A PE is upstream for the traffic it is forwarding 239 and is downstream for the traffic it is receiving. 241 We use the terms "local" and "remote" to identify native service 242 networks and ACs in relation to a specific PE. The local AC is 243 attached to the PE in question, while the remote AC is attached to 244 the PE at the other end of the PW. 246 A "transmit defect" is any defect that uniquely impacts traffic sent 247 or relayed by the observing PE. A "receive defect" is any defect 248 that impacts information transfer to the observing PE. Note that a 249 receive defect also impacts traffic meant to be relayed, and thus can 250 be considered to incorporate two defect states. Thus when a PE 251 enters both receive and transmit defect states of a PW service, the 252 receive defect takes precedence over the transmit defect in terms of 253 the consequent actions. 255 A "forward defect indication" (FDI) is sent in the same direction as 256 the user traffic impacted by the defect. A "reverse defect 257 indication" (RDI) is sent in the direction opposite to that of the 258 impacted traffic. 260 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 261 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 262 document are to be interpreted as described in [RFC2119]. 264 3. Reference Model and Defect Locations 266 Figure 1 illustrates the PWE3 network reference model with an 267 indication of the possible defect locations. This model will be 268 referenced in the remainder of this document for describing the OAM 269 procedures. 271 ACs PSN tunnel ACs 272 +----+ +----+ 273 +----+ | PE1|==================| PE2| +----+ 274 | |---(a)---(b)..(c)......PW1..(d)..(e)..(f)---(g)---| | 275 | CE1| (N1) | | | | (N2) |CE2 | 276 | |----------|............PW2.............|----------| | 277 +----+ | |==================| | +----+ 278 ^ +----+ +----+ ^ 279 | Provider Edge 1 Provider Edge 2 | 280 | | 281 |<-------------- Emulated Service ---------------->| 282 Customer Customer 283 Edge 1 Edge 2 285 Figure 1: PWE3 Network Defect Locations 287 The procedures will be described in this document from the viewpoint 288 of PE1, so that N1 is the local native service network and N2 is the 289 remote native service network. PE2 will typically implement the same 290 functionality. Note that PE1 is the upstream PE for traffic 291 originating in the local NS network N1, while it is the downstream PE 292 for traffic originating in the remote NS network N2. 294 The following is a brief description of the defect locations: 296 a. Defect in NS network N1. This covers any defect in network N1 297 (including any CE1 defect) that impacts all or some ACs attached 298 to PE1, and is thus a local AC defect. The defect is conveyed to 299 PE1 and to NS network N2 using NS specific OAM defect indications. 300 b. Defect on a PE1 AC interface (another local AC defect). 301 c. Defect on a PE1 PSN interface. 302 d. Defect in the PSN network. This covers any defect in the PSN that 303 impacts all or some PWs between PE1 and PE2. The defect is 304 conveyed to the PE using a PSN and/or a PW specific OAM defect 305 indication. Note that both data plane defects and control plane 306 defects must be taken into consideration. Although control 307 messages may follow a different path than PW data plane traffic, a 308 control plane defect may affect the PW status. 310 e. Defect on a PE2 PSN interface. 311 f. Defect on a PE2 AC interface (a remote AC defect). 312 g. Defect in NS network N2 (another remote AC defect). This covers 313 any defect in N2 (including any CE2 defect) that impacts all or a 314 subset of ACs attached to PE2. The defect is conveyed to PE2 and 315 to NS network N1 using the NS OAM defect indication. 317 4. Abstract Defect States 319 PE1 must track four defect states that reflect the observed states of 320 both directions of the PW service on both the AC and the PW sides. 321 Defects may impact one or both directions of the PW service. 323 The observed state is a combination of defects directly detected by 324 PE1 and defects of which it has been made aware via notifications. 326 +-----+ 327 ----AC receive---->| |-----PW transmit----> 328 CE1 | PE1 | PE2/CE2 329 <---AC transmit----| |<----PW receive----- 330 +-----+ 331 (arrows indicate direction of user traffic impacted by a defect) 333 Figure 2: Receive and Transmit Defect States 335 PE1 will directly detect or be notified of AC receive or PW receive 336 defects as they occur upstream of PE1 and impact traffic being sent 337 to PE1. As a result, PE1 enters the AC or PW receive defect state. 339 In Figure 2, PE1 may be notified of a receive defect in the AC by 340 receiving a Forward Defect indication, e.g., ATM AIS, from CE1 or an 341 intervening network. This defect notification indicates that user 342 traffic sent by CE1 may not be received by PE1 due to a defect. PE1 343 can also directly detect an AC receive defect if it resulted from a 344 failure of the receive side in the local port or link over which the 345 AC is configured. 347 Similarly, PE1 may detect or be notified of a receive defect in the 348 PW by receiving a Forward Defect indication from PE2. If the PW 349 status TLV is used for fault notification, this message will indicate 350 a Local PSN-facing PW (egress) Transmit Fault or a Local AC (ingress) 351 Receive Fault at PE2, as described in Section 6.1.1. This defect 352 notification indicates that user traffic sent by CE2 may not be 353 received by PE1 due to a defect. As a result, PE1 enters the PW 354 receive defect state. 356 Note that a Forward Defect Indication is sent in the same direction 357 as the user traffic impacted by the defect. 359 Generally, a PE cannot detect transmit defects by itself and will 360 therefore need to be notified of AC transmit or PW transmit defects 361 by other devices. 363 In Figure 2, PE1 may be notified of a transmit defect in the AC by 364 receiving a Reverse Defect indication, e.g., ATM RDI, from CE1. This 365 defect relates to the traffic sent by PE1 to CE1 on the AC. 367 Similarly, PE1 may be notified of a transmit defect in the PW by 368 receiving a Reverse Defect indication from PE2. If PW status is used 369 for fault notification, this message will indicate a Local PSN- 370 facing PW (ingress) Receive Fault or a Local Attachment Circuit 371 (egress) Transmit Fault at PE2, as described in Section 6.1.1. This 372 defect impacts the traffic sent by PE1 to CE2. As a result, PE1 373 enters the PW transmit defect state. 375 Note that a Reverse Defect indication is sent in the reverse 376 direction to the user traffic impacted by the defect. 378 The procedures outlined in this document define the entry and exit 379 criteria for each of the four states with respect to the set of PW 380 services within the document scope and the consequent actions that 381 PE1 must perform. 383 When a PE enters both receive and transmit defect states related to 384 the same PW service, then the receive defect takes precedence over 385 transmit defect in terms of the consequent actions. 387 5. OAM Modes 389 A homogeneous PW service forwards packets between an AC and a PW of 390 the same type. It thus implements both NS OAM and PW OAM mechanisms. 391 PW OAM defect notification messages are described in Section 6.1. NS 392 OAM messages are described in Appendix A. 394 This document defines two different OAM modes, the distinction being 395 the method of mapping between the NS and PW OAM defect notification 396 messages. 398 The first mode, illustrated in Figure 3, is called the "single 399 emulated OAM loop" mode. Here a single end-to-end NS OAM loop is 400 emulated by transparently passing NS OAM messages over the PW. Note 401 that the PW OAM is shown outside the PW in Figure 3, as it is 402 transported in LDP messages or in the associated channel, not inside 403 the PW itself. 405 +-----+ +-----+ 406 +-----+ | |=================| | +-----+ 407 | CE1 |-=NS-OAM=>| PE1 |----=NS-OAM=>----| PE2 |-=NS-OAM=>| CE2 | 408 +-----+ | |=================| | +-----+ 409 +-----+ +-----+ 410 \ / 411 -------=PW-OAM=>------- 413 Figure 3: Single Emulated OAM Loop mode 415 The single emulated OAM loop mode implements the following behavior: 417 a. The upstream PE (PE1) MUST transparently relay NS OAM messages 418 over the PW. 419 b. The upstream PE MUST signal local defects affecting the AC using a 420 NS defect notification message sent over the PW. In the case that 421 it is not possible to generate NS OAM messages (e.g., because the 422 defect interferes with NS OAM message generation) the PE MUST 423 signal local defects affecting the AC using a PW defect 424 notification message. 425 c. The upstream PE MUST signal local defects affecting the PW using a 426 PW defect notification message. 427 d. The downstream PE (PE2) MUST insert NS defect notification 428 messages into its local AC when it detects or is notified of a 429 defect in the PW or remote AC. This includes translating received 430 PW defect notification messages into NS defect notification 431 messages for defects signaled by the upstream PE. 433 The single emulated OAM loop mode is suitable for PW services that 434 have a widely deployed NS OAM mechanism. This document specifies the 435 use of this mode for ATM PW, TDM PW, and CEP PW services. It is the 436 default mode of operation for all ATM cell-mode PW services and the 437 only mode specified for CEP and SAToP/CESoPSN TDM PW services. It is 438 optional for AAL5 PDU transport and AAL5 SDU transport modes. 440 The second OAM mode operates three OAM loops joined at the AC/PW 441 boundaries of the PEs. This is referred to as the "coupled OAM 442 loops" mode and is illustrated in Figure 4. Note that in contrast to 443 Figure 3, NS OAM messages are never carried over the PW. 445 +-----+ +-----+ 446 +-----+ | |=================| | +-----+ 447 | CE1 |-=NS-OAM=>| PE1 | | PE2 |-=NS-OAM=>| CE2 | 448 +-----+ | |=================| | +-----+ 449 +-----+ +-----+ 450 \ / 451 -------=PW-OAM=>------- 453 Figure 4: Coupled OAM Loops mode 455 The coupled OAM loops mode implements the following behavior: 457 a. The upstream PE (PE1) MUST terminate and translate a received NS 458 defect notification message into a PW defect notification message. 459 b. The upstream PE MUST signal local failures affecting its local AC 460 using PW defect notification messages to the downstream PE. 461 c. The upstream PE MUST signal local failures affecting the PW using 462 PW defect notification messages. 463 d. The downstream PE (PE2) MUST insert NS defect notification 464 messages into the AC when it detects or is notified of defects in 465 the PW or remote AC. This includes translating received PW defect 466 notification messages into NS defect notification messages. 468 This document specifies the coupled OAM loops mode as the default 469 mode for the frame relay, ATM AAL5 PDU transport, and AAL5 SDU 470 transport services. It is an optional mode for ATM VCC cell mode 471 services. This mode is not specified for TDM, CEP, or ATM VPC cell 472 mode PW services. RFC5087 defines a similar but distinct mode, as 473 will be explained in Section 9 below. For the ATM VPC cell mode case 474 a pure coupled OAM loops mode is not possible as a PE MUST 475 transparently pass VC-level (F5) ATM OAM cells over the PW while 476 terminating and translating VP-level (F4) OAM cells. 478 6. PW Defect States and Defect Notifications 480 6.1. PW Defect Notification Mechanisms 482 For MPLS and MPLS/IP PSNs, a PE that establishes a PW using the Label 483 Distribution Protocol [RFC5036], and that has negotiated use of the 484 LDP status TLV per Section 5.4.3 of [RFC4447], MUST use the PW status 485 TLV mechanism for AC and PW status and defect notification. 486 Additionally, such a PE MAY use VCCV-BFD Connectivity Verification 487 (CV) for fault detection only (CV types 0x04 and 0x10 [RFC5885]). 489 A PE that establishes an MPLS PW using means other than LDP, e.g., by 490 static configuration or by use of BGP, MUST support some alternative 491 method of status reporting. The design of a suitable mechanism to 492 carry the aforementioned status TLV in the the PW associated channel 493 is work in progress [I-D.ietf-pwe3-static-pw-status]. Additionally, 494 such a PE MAY use VCCV-BFD CV for both fault detection and status 495 notification (CV types 0x08 and 0x20 [RFC5885]). 497 For a L2TPv3/IP PSN, a PE SHOULD use the Circuit Status Attribute 498 Value Pair (AVP) as the mechanism for AC and PW status and defect 499 notification. In its most basic form, the Circuit Status AVP 500 [RFC3931] in a Set-Link-Info (SLI) message can signal active/inactive 501 AC status. The Circuit Status AVP as described in [RFC5641] is 502 proposed to be extended to convey status and defects in the AC and 503 the PSN-facing PW in both ingress and egress directions, i.e., four 504 independent status bits, without the need to tear down the sessions 505 or control connection. 507 When a PE does not support the Circuit Status AVP, it MAY use the 508 Stop-Control-Connection-Notification (StopCCN) and the Call- 509 Disconnect-Notify (CDN) messages to tear down L2TP sessions in a 510 fashion similar to LDP's use of Label Withdrawal to tear down a PW. 511 A PE may use the StopCCN to shutdown the L2TP control connection, and 512 implicitly all L2TP sessions associated with that control connection, 513 without any explicit session control messages. This is useful for 514 the case of a failure which impacts all L2TP sessions (all PWs) 515 managed by the control connection. It MAY use CDN to disconnect a 516 specific L2TP session when a failure only affects a specific PW. 518 Additionally, a PE MAY use VCCV-BFD CV types 0x04 and 0x10 for fault 519 detection only, but SHOULD notify the remote PE using the Circuit 520 Status AVP. A PE that establishes a PW using means other than the 521 L2TP control plane, e.g., by static configuration or by use of BGP, 522 MAY use VCCV-BFD CV types 0x08 and 0x20 for AC and PW status and 523 defect notification. These CV types SHOULD NOT be used when the PW 524 is established via the L2TP control plane. 526 The CV types are defined in Section 6.1.3 of this document. 528 6.1.1. LDP Status TLV 530 [RFC4446] defines the following PW status code points: 532 0x00000000 - Pseudowire forwarding (clear all failures) 533 0x00000001 - Pseudowire Not Forwarding 534 0x00000002 - Local Attachment Circuit (ingress) Receive Fault 535 0x00000004 - Local Attachment Circuit (egress) Transmit Fault 536 0x00000008 - Local PSN-facing PW (ingress) Receive Fault 537 0x00000010 - Local PSN-facing PW (egress) Transmit Fault 539 [RFC4447] specifies that the "Pseudowire forwarding" code point is 540 used to indicate that all faults are to be cleared. It also 541 specifies that the "Pseudowire Not Forwarding" code point means that 542 a defect has been detected that is not represented by the defined 543 code points. 545 The code points used in the LDP status TLV in a PW status 546 notification message report defects from the viewpoint of the 547 originating PE. The originating PE conveys this state in the form of 548 a forward defect or a reverse defect indication. 550 The forward and reverse defect indication definitions used in this 551 document map to the LDP Status TLV codes as follows: 553 Forward defect indication corresponds to the logical OR of: 554 * Local Attachment Circuit (ingress) Receive Fault, 555 * Local PSN-facing PW (egress) Transmit Fault, and 556 * PW Not Forwarding. 557 Reverse defect indication corresponds to the logical OR of: 558 * Local Attachment Circuit (egress) Transmit Fault and 559 * Local PSN-facing PW (ingress) Receive Fault. 561 A PE MUST use PW status notification messages to report all defects 562 affecting the PW service including, but not restricted, to the 563 following: 565 o defects detected through fault detection mechanisms in the MPLS 566 and MPLS/IP PSN, 567 o defects detected through VCCV-Ping or VCCV-BFD CV types 0x04 and 568 0x10 for fault detection only, 569 o defects within the PE that result in an inability to forward 570 traffic between the AC and the PW, 571 o defects of the AC or in the Layer 2 network affecting the AC as 572 per the rules detailed in Section 5 for the "single emulated OAM 573 loop" mode and "coupled OAM loops" modes. 575 Note that there are two situations that require PW label withdrawal 576 as opposed to a PW status notification by the PE. The first one is 577 when the PW is taken down administratively in accordance with 578 [RFC4447]. The second one is when the Target LDP session established 579 between the two PEs is lost. In the latter case, the PW labels will 580 need to be re-signaled when the Targeted LDP session is re- 581 established. 583 6.1.2. L2TP Circuit Status AVP 585 [RFC3931] defines the Circuit Status AVP in the Set-Link-Info (SLI) 586 message to exchange initial status and status changes in the circuit 587 to which the pseudowire is bound. [RFC5641] defines extensions to 588 the Circuit Status AVP that are analogous to the PW Status TLV 589 defined for LDP. Consequently, for L2TPv3/IP the Circuit Status AVP 590 is used in the same fashion as the PW Status described in the 591 previous section. Extended circuit status for L2TPv3/IP is described 592 in [RFC5641]. 594 If the extended Circuit Status bits are not supported, and instead 595 only the "A-bit" (Active) is used as described in [RFC3931], a PE MAY 596 use CDN messages to clear L2TPv3/IP sessions in the presence of 597 session-level failures detected in the L2TPv3/IP PSN. 599 A PE MUST set the Active bit in the Circuit Status to clear all 600 faults, and it MUST clear the Active bit in the Circuit Status to 601 convey any defect that cannot be represented explicitly with specific 602 Circuit Status flags from [RFC3931] or [RFC5641]. 604 The forward and reverse defect indication definitions used in this 605 document map to the L2TP Circuit Status AVP as follows: 607 Forward defect indication corresponds to the logical OR of: 608 * Local Attachment Circuit (ingress) Receive Fault, 609 * Local PSN-facing PW (egress) Transmit Fault, and 610 * PW Not Forwarding. 611 Reverse defect indication corresponds to the logical OR of: 612 * Local Attachment Circuit (egress) Transmit Fault and 613 * Local PSN-facing PW (ingress) Receive Fault. 615 The status notification conveys defects from the viewpoint of the 616 originating LCCE (PE). 618 When the extended Circuit Status definition of [RFC5641] is 619 supported, a PE SHALL use the Circuit Status to report all failures 620 affecting the PW service including, but not restricted, to the 621 following: 623 o defects detected through defect detection mechanisms in the 624 L2TPv3/IP PSN, 625 o defects detected through VCCV-Ping or VCCV-BFD CV types 0x04 (BFD 626 IP/UDP-encapsulated, for PW Fault Detection only) and 0x10 (BFD 627 PW-ACH-encapsulated (without IP/UDP headers), for PW. Fault 628 Detection and AC/PW Fault Status Signaling) for fault detection 629 only which are described in Section 6.1.3 of this document, 631 o defects within the PE that result in an inability to forward 632 traffic between the AC and the PW, 633 o defects of the AC or in the L2 network affecting the AC as per the 634 rules detailed in Section 5 for the "single emulated OAM loop" 635 mode and the "coupled OAM loops" modes. 637 When the extended Circuit Status definition of [RFC5641] is not 638 supported, a PE SHALL use the A-bit in the Circuit Status AVP in SLI 639 to report: 641 o defects of the AC or in the L2 network affecting the AC as per the 642 rules detailed in Section 5 for the "single emulated OAM loop" 643 mode and the "coupled OAM loops" modes. 645 When the extended Circuit Status definition of [RFC5641] is not 646 supported, a PE MAY use the CDN and StopCCN messages in a similar way 647 to an MPLS PW label withdrawal to report: 649 o defects detected through defect detection mechanisms in the 650 L2TPv3/IP PSN (using StopCCN), 651 o defects detected through VCCV (pseudowire level) (using CDN), 652 o defects within the PE that result in an inability to forward 653 traffic between ACs and PW (using CDN). 655 For ATM L2TPv3/IP pseudowires, in addition to the Circuit Status AVP, 656 a PE MAY use the ATM Alarm Status AVP [RFC4454] to indicate the 657 reason for the ATM circuit status and the specific alarm type, if 658 any. This AVP is sent in the SLI message to indicate additional 659 information about the ATM circuit status. 661 L2TP control connections use Hello messages as a keep-alive facility. 662 It is important to note that if PSN failure is detected by keep-alive 663 timeout, the control connection is cleared. L2TP Hello messages are 664 sent in-band so as to follow the data plane with respect to the 665 source and destination addresses, IP protocol number and UDP port 666 (when UDP is used). 668 6.1.3. BFD Diagnostic Codes 670 BFD [RFC5880] defines a set of diagnostic codes that partially 671 overlap the set of defects that can be communicated through LDP 672 Status TLV or L2TP Circuit Status AVP. This section describes the 673 behavior of the PEs with respect to using one or both of these 674 methods for detecting and propagating defect state. 676 In the case of an MPLS PW established via LDP signaling, the PEs 677 negotiate VCCV capabilities during the label mapping messages 678 exchange used to establish the two directions of the PW. This is 679 achieved by including a capability TLV in the PW FEC interface 680 parameters TLV. In the L2TPv3/IP case, the PEs negotiate the use of 681 VCCV during the pseudowire session initialization using the VCCV AVP 682 [RFC5085]. 684 The CV Type Indicators field in the OAM capability TLV or VCCV AVP 685 defines a bitmask used to indicate the specific OAM capabilities that 686 the PE can use over the PW being established. 688 A CV type of 0x04 or 0x10 [RFC5885] indicates that BFD is used for PW 689 fault detection only. These CV types MAY be used any time the PW is 690 established using LDP or L2TP control planes. In this mode, only the 691 following diagnostic (Diag) codes specified in [RFC5880] will be 692 used: 694 0 - No diagnostic 695 1 - Control detection time expired 696 3 - Neighbor signaled session down 697 7 - Administratively Down 699 A PE using VCCV-BFD MUST use diagnostic code 0 to indicate to its 700 peer PE that is correctly receiving BFD control messages. It MUST 701 use diagnostic code 1 to indicate that to its peer it has stopped 702 receiving BFD control messages and will thus declare the PW to be 703 down in the receive direction. It MUST use diagnostic code 3 to 704 confirm to its peer that the BFD session is going down after 705 receiving diagnostic code 1 from this peer. In this case, it will 706 declare the PW to be down in the transmit direction. A PE MUST use 707 diagnostic code 7 to bring down the BFD session when the PW is 708 brought down administratively. All other defects, such as AC/PW 709 defects and PE internal failures that prevent it from forwarding 710 traffic, MUST be communicated through the LDP Status TLV in the case 711 of MPLS or MPLS/IP PSN, or through the appropriate L2TP codes in the 712 Circuit Status AVP in the case of L2TPv3/IP PSN. 714 A CV type of 0x08 or 0x20 in the OAM capabilities TLV indicates that 715 BFD is used for both PW fault detection and Fault Notification. In 716 addition to the above diagnostic codes, a PE uses the following codes 717 to signal AC defects and other defects impacting forwarding over the 718 PW service: 720 6 - Concatenated Path Down 721 8 - Reverse Concatenated Path Down 723 As specified in [RFC5085], the PEs negotiate the use of VCCV during 724 PW set-up. When a PW transported over an MPLS-PSN is established 725 using LDP, the PEs negotiate the use of the VCCV capabilities using 726 the optional VCCV Capability Advertisement Sub- TLV parameter in the 727 Interface Parameter Sub-TLV field of the LDP PW ID FEC or using an 728 Interface Parameters TLV of the LDP Generalized PW ID FEC. In the 729 case of L2TPv3/IP PSNs, the PEs negotiate the use of VCCV during the 730 pseudowire session initialization using VCCV AVP. 732 Note that a defect that causes the generation of the "PW not 733 forwarding code" (diagnostic code 6 or 8) does not necessarily result 734 in the BFD session going down. However, if the BFD session times 735 out, then diagnostic code 1 MUST be used since it signals a state 736 change of the BFD session itself. In general, when a BFD session 737 changes state, the PEs MUST use state change diagnostic codes 0, 1, 738 3, and 7 in accordance with [RFC5880] and they MUST override any of 739 the AC/PW status diagnostic codes (codes 6 or 8) that may have been 740 signaled prior to the BFD session changing state. 742 The forward and reverse defect indications used in this document map 743 to the following BFD codes: 745 Forward defect indication corresponds to the logical OR of: 746 * Concatenated Path Down (BFD diagnostic code 06) 747 * Pseudowire Not Forwarding (PW status code 0x00000001). 748 Reverse defect indication- corresponds to: 749 * Reverse Concatenated Path Down (BFD diagnostic code 08). 751 These diagnostic codes are used to signal forward and reverse defect 752 states, respectively, when the PEs negotiated the use of BFD as the 753 mechanism for AC and PW fault detection and status signaling 754 notification. As stated in Section 6.1, these CV types SHOULD NOT be 755 used when the PW is established with the LDP or L2TP control plane. 757 6.2. PW Defect State Entry/Exit 759 6.2.1. PW receive defect state entry/exit criteria 761 PE1, as downstream PE, will enter the PW receive defect state if one 762 or more of the following occurs: 764 o It receives a Forward Defect Indication (FDI) from PE2 indicating 765 either a receive defect on the remote AC, or that PE2 detected or 766 was notified of downstream PW fault. 767 o It detects loss of connectivity on the PSN tunnel upstream of PE1 768 which affects the traffic it receives from PE2. 769 o It detects a loss of PW connectivity through VCCV-BFD or VCCV-PING 770 which affects the traffic it receives from PE2. 772 Note that if the PW control session (LDP session, the L2TP session, 773 or the L2TP control connection) between the PEs fails, the PW is torn 774 down and needs to be re-established. However, the consequent actions 775 towards the ACs are the same as if the PW entered the receive defect 776 state. 778 PE1 will exit the PW receive defect state when the following 779 conditions are met. Note that this may result in a transition to the 780 PW operational state or the PW transmit defect state. 782 o All previously detected defects have disappeared, and 783 o PE2 cleared the FDI, if applicable. 785 6.2.2. PW transmit defect state entry/exit criteria 787 PE1, as upstream PE, will enter the PW transmit defect state if the 788 following conditions occur: 790 o It receives a Reverse Defect Indication (RDI) from PE2 indicating 791 either a transmit fault on the remote AC, or that PE2 detected or 792 was notified of a upstream PW fault, and 793 o it is not already in the PW receive defect state. 795 PE1 will exit the transmit defect state if it receives an OAM message 796 from PE2 clearing the RDI, or it has entered the PW receive defect 797 state. 799 For a PW over L2TPv3/IP using the basic Circuit Status AVP [RFC3931], 800 the PW transmit defect state is not valid and a PE can only enter the 801 PW receive defect state. 803 7. Procedures for ATM PW Service 805 The following procedures apply to Asynchronous Transfer Mode (ATM) 806 pseudowires [RFC4717]. ATM terminology is explained in Appendix A.2 807 of this document. 809 7.1. AC receive defect state entry/exit criteria 811 When operating in the coupled OAM loops mode, PE1 enters the AC 812 receive defect state when any of the following conditions are met: 814 a. It detects or is notified of a physical layer fault on the ATM 815 interface. 816 b. It receives an end-to-end Flow 4 OAM (F4) Alarm Indication Signal 817 (AIS) OAM flow on a Virtual Path (VP) AC, or an end-to-end Flow 5 818 (F5) AIS OAM flow on a Virtual Circuit (VC) as per ITU-T 819 Recommendation I.610 [I.610], indicating that the ATM VPC or VCC 820 is down in the adjacent Layer 2 ATM network. 822 c. It receives a segment F4 AIS OAM flow on a VP AC, or a segment F5 823 AIS OAM flow on a VC AC, provided that the operator has 824 provisioned segment OAM and the PE is not a segment end-point. 825 d. It detects loss of connectivity on the ATM VPC/VCC while 826 terminating segment or end-to-end ATM continuity check (ATM CC) 827 cells with the local ATM network and CE. 829 When operating in the coupled OAM loops mode, PE1 exits the AC 830 Receive defect state when all previously detected defects have 831 disappeared. 833 When operating in the single emulated OAM loop mode, PE1 enters the 834 AC receive defect state if any of the following conditions are met: 836 a. It detects or is notified of a physical layer fault on the ATM 837 interface. 838 b. It detects loss of connectivity on the ATM VPC/VCC while 839 terminating segment ATM continuity check (ATM CC) cells with the 840 local ATM network and CE. 842 When operating in the single emulated OAM loop mode, PE1 exits the AC 843 receive defect state when all previously detected defects have 844 disappeared. 846 The exact conditions under which a PE enters and exits the AIS state, 847 or declares that connectivity is restored via ATM CC, are defined in 848 Section 9.2 of [I.610]. 850 7.2. AC transmit defect state entry/exit criteria 852 When operating in the coupled OAM loops mode, PE1 enters the AC 853 transmit defect state if any of the following conditions are met: 855 a. It terminates an end-to-end F4 RDI OAM flow, in the case of a VPC, 856 or an end-to-end F5 RDI OAM flow, in the case of a VCC, indicating 857 that the ATM VPC or VCC is down in the adjacent L2 ATM. 858 b. It receives a segment F4 RDI OAM flow on a VP AC, or a segment F5 859 RDI OAM flow on a VC AC, provided that the operator has 860 provisioned segment OAM and the PE is not a segment end-point. 862 PE1 exits the AC transmit defect state if the AC state transitions to 863 working or to the AC receive defect state. The exact conditions for 864 exiting the RDI state are described in Section 9.2 of [I.610]. 866 Note that the AC transmit defect state is not valid when operating in 867 the single emulated OAM loop mode, as PE1 transparently forwards the 868 received RDI cells as user cells over the ATM PW to the remote CE. 870 7.3. Consequent Actions 872 In the remainder of this section, the text refers to AIS, RDI and CC 873 without specifying whether there is an F4 (VP-level) flow or an F5 874 (VC- level) flow, or whether it is an end-to-end or a segment flow. 875 Precise ATM OAM procedures for each type of flow are specified in 876 Section 9.2 of [I.610]. 878 7.3.1. PW receive defect state entry/exit 880 On entry to the PW receive defect state: 882 a. PE1 MUST commence AIS insertion into the corresponding AC. 883 b. PE1 MUST cease generation of CC cells on the corresponding AC, if 884 applicable. 885 c. If the PW defect was detected by PE1 without receiving FDI from 886 PE2, PE1 MUST assume PE2 has no knowledge of the defect and MUST 887 notify PE2 by sending RDI. 889 On exit from the PW receive defect state: 891 a. PE1 MUST cease AIS insertion into the corresponding AC. 892 b. PE1 MUST resume any CC cell generation on the corresponding AC, if 893 applicable. 894 c. PE1 MUST clear the RDI to PE2, if applicable. 896 7.3.2. PW transmit defect state entry/exit 898 On entry to the PW Transmit Defect State: 900 a. PE1 MUST commence RDI insertion into the corresponding AC. 901 b. If the PW failure was detected by PE1 without receiving an RDI 902 from PE2, PE1 MUST assume PE2 has no knowledge of the defect and 903 MUST notify PE2 by sending FDI. 905 On exit from the PW Transmit Defect State: 907 a. PE1 MUST cease RDI insertion into the corresponding AC. 908 b. PE1 MUST clear the FDI to PE2, if applicable. 910 7.3.3. PW defect state in ATM Port Mode PW Service 912 In case of transparent cell transport PW service, i.e., "port mode", 913 where the PE does not keep track of the status of individual ATM VPCs 914 or VCCs, a PE cannot relay PW defect state over these VCCs and VPCs. 915 If ATM CC is run on the VCCs and VPCs end-to-end (CE1 to CE2), or on 916 a segment originating and terminating in the ATM network and spanning 917 the PSN network, it will timeout and cause the CE or ATM switch to 918 enter the ATM AIS state. 920 7.3.4. AC receive defect state entry/exit 922 On entry to the AC receive defect state and when operating in the 923 coupled OAM loops mode: 925 a. PE1 MUST send FDI to PE2. 926 b. PE1 MUST commence insertion of ATM RDI cells into the AC towards 927 CE1. 929 When operating in the single emulated OAM loop mode, PE1 must be able 930 to support two options, subject to the operator's preference. The 931 default option is the following: 933 On entry to the AC receive defect state: 935 a. PE1 MUST transparently relay ATM AIS cells, or, in the case of a 936 local AC defect, commence insertion of ATM AIS cells into the 937 corresponding PW towards CE2. 938 b. If the defect interferes with NS OAM message generation, PE1 MUST 939 send an FDI indication to PE2. 940 c. PE1 MUST cease the generation of CC cells on the corresponding PW, 941 if applicable. 943 In certain operational models, for example in the case that the ATM 944 access network is owned by a different provider than the PW, an 945 operator may want to distinguish between defects detected in the ATM 946 access network and defects detected on the AC directly adjacent to 947 the PE. Therefore, the following option MUST also be supported: 949 a. PE1 MUST transparently relay ATM AIS cells over the corresponding 950 PW towards CE2. 951 b. Upon detection of a defect on the ATM interface on the PE or in 952 the PE itself, PE1 MUST send FDI to PE2. 953 c. PE1 MUST cease generation of CC cells on the corresponding PW, if 954 applicable. 956 On exit from the AC receive defect state and when operating in the 957 coupled OAM loops mode: 959 a. PE1 MUST clear the FDI to PE2. 960 b. PE1 MUST cease insertion of ATM RDI cells into the AC. 962 On exit from the AC receive defect state and when operating in the 963 single emulated OAM loop mode: 965 a. PE1 MUST cease insertion of ATM AIS cells into the corresponding 966 PW. 967 b. PE1 MUST clear the FDI to PE2, if applicable. 968 c. PE1 MUST resume any CC cell generation on the corresponding PW, if 969 applicable. 971 7.3.5. AC transmit defect state entry/exit 973 On entry to the AC transmit defect state and when operating in the 974 coupled OAM loops mode: 976 * PE1 MUST send RDI to PE2. 978 On exit from the AC transmit defect state and when operating in the 979 coupled OAM loops mode: 981 * PE1 MUST clear the RDI to PE2. 983 8. Procedures for Frame Relay PW Service 985 The following procedures apply to Frame Relay (FR) pseudowires 986 [RFC4619]. Frame Relay (FR) terminology is explained in Appendix A.1 987 of this document. 989 8.1. AC receive defect state entry/exit criteria 991 PE1 enters the AC receive defect state if one or more of the 992 following conditions are met: 994 a. A Permanent Virtual Circuit (PVC) is not deleted from the FR 995 network and the FR network explicitly indicates in a full status 996 report (and optionally by the asynchronous status message) that 997 this PVC is inactive [Q.933]. In this case, this status maps 998 across the PE to the corresponding PW only. 999 b. The Link Integrity Verification (LIV) indicates that the link from 1000 the PE to the Frame Relay network is down [Q.933]. In this case, 1001 the link down indication maps across the PE to all corresponding 1002 PWs. 1003 c. A physical layer alarm is detected on the FR interface. In this 1004 case, this status maps across the PE to all corresponding PWs. 1006 PE1 exits the AC receive defect state when all previously detected 1007 defects have disappeared. 1009 8.2. AC transmit defect state entry/exit criteria 1011 The AC transmit defect state is not valid for a FR AC. 1013 8.3. Consequent Actions 1015 8.3.1. PW receive defect state entry/exit 1017 The A (Active) bit indicates whether the FR PVC is ACTIVE (1) or 1018 INACTIVE (0) as explained in [RFC4591]. 1020 On entry to the PW receive defect state: 1022 a. PE1 MUST clear the Active bit for the corresponding FR AC in a 1023 full status report, and optionally in an asynchronous status 1024 message, as per Q.933 Annex A [Q.933]. 1025 b. If the PW failure was detected by PE1 without receiving FDI from 1026 PE2, PE1 MUST assume PE2 has no knowledge of the defect and MUST 1027 notify PE2 by sending RDI. 1029 On exit from the PW receive defect state: 1031 a. PE1 MUST set the Active bit for the corresponding FR AC in a full 1032 status report, and optionally in an asynchronous status message, 1033 as per Q.933 annex A. PE1 does not apply this procedure on a 1034 transition from the PW receive defect state to the PW transmit 1035 defect state. 1036 b. PE1 MUST clear the RDI to PE2, if applicable. 1038 8.3.2. PW transmit defect state entry/exit 1040 On entry to the PW transmit defect state: 1042 a. PE1 MUST clear the Active bit for the corresponding FR AC in a 1043 full status report, and optionally in an asynchronous status 1044 message, as per Q.933 Annex A. 1045 b. If the PW failure was detected by PE1 without RDI from PE2, PE1 1046 MUST assume PE2 has no knowledge of the defect and MUST notify PE2 1047 by sending FDI. 1049 On exit from the PW transmit defect state: 1051 a. PE1 MUST set the Active bit for the corresponding FR AC in a full 1052 status report, and optionally in an asynchronous status message, 1053 as per Q.933 annex A. PE1 does not apply this procedure on a 1054 transition from the PW transmit defect state to the PW receive 1055 defect state. 1057 b. PE1 MUST clear the FDI to PE2, if applicable. 1059 8.3.3. PW defect state in the FR Port Mode PW Service 1061 In case of port mode PW service, STATUS ENQUIRY and STATUS messages 1062 are transported transparently over the PW. A PW Failure will 1063 therefore result in timeouts of the Q.933 link and PVC management 1064 protocol at the Frame Relay devices at one or both sites of the 1065 emulated interface. 1067 8.3.4. AC receive defect state entry/exit 1069 On entry to the AC receive defect state: 1071 * PE1 MUST send FDI to PE2. 1073 On exit from the AC receive defect state: 1075 * PE1 MUST clear FDI to PE2. 1077 8.3.5. AC transmit defect state entry/exit 1079 The AC transmit defect state is not valid for a FR AC. 1081 9. Procedures for TDM PW Service 1083 The following procedures apply to SAToP [RFC4553], CESoPSN [RFC5086] 1084 and TDMoIP [RFC5087]. These technologies utilize the single emulated 1085 OAM loop mode. RFC 5087 distinguishes between trail-extended and 1086 trail-terminated scenarios; the former is essentially the single 1087 emulated loop model. The latter applies to cases where the NS 1088 networks are run by different operators and defect notifications are 1089 not propagated across the PW. 1091 Since TDM is inherently real-time in nature, many OAM indications 1092 must be generated or forwarded with minimal delay. This requirement 1093 rules out the use of messaging protocols, such as PW status messages. 1094 Thus, for TDM PWs, alternate mechanisms are employed. 1096 The fact that TDM PW packets are sent at a known constant rate can be 1097 exploited as an OAM mechanism. Thus, a PE enters the PW receive 1098 defect state whenever a preconfigured number of TDM PW packets do not 1099 arrive in a timely fashion. It exits this state when packets once 1100 again arrive at their proper rate. 1102 Native TDM carries OAM indications in overhead fields that travel 1103 along with the data. TDM PWs emulate this behavior by sending urgent 1104 OAM messages in the PWE control word. 1106 The TDM PWE3 control word contains a set of flags used to indicate PW 1107 and AC defect conditions. The L bit is an AC forward defect 1108 indication used by the upstream PE to signal NS network defects to 1109 the downstream PE. The M field may be used to modify the meaning of 1110 receive defects. The R bit is a PW reverse defect indication used by 1111 the PE to signal PSN failures to the remote PE. Upon reception of 1112 packets with the R bit set, a PE enters the PW transmit defect state. 1113 L bits and R bits are further described in [RFC5087]. 1115 9.1. AC receive defect state entry/exit criteria 1117 PE1 enters the AC receive defect state if any of the following 1118 conditions are met: 1120 a. It detects a physical layer fault on the TDM interface (Loss of 1121 Signal, Loss of Alignment, etc., as described in [G.775]). 1122 b. It is notified of a previous physical layer fault by detecting 1123 AIS. 1125 The exact conditions under which a PE enters and exits the AIS state 1126 are defined in [G.775]. Note that Loss of Signal and AIS detection 1127 can be performed by PEs for both structure-agnostic and structure- 1128 aware TDM PW types. Note that PEs implementing structure- agnostic 1129 PWs can not detect Loss of Alignment. 1131 9.2. AC transmit defect state entry/exit criteria 1133 PE1 enters the AC transmit defect state when it detects RDI according 1134 to the criteria in [G.775]. Note that PEs implementing structure- 1135 agnostic PWs can not detect RDI. 1137 9.3. Consequent Actions 1139 9.3.1. PW receive defect state entry/exit 1141 On entry to the PW receive defect state: 1143 a. PE1 MUST commence AIS insertion into the corresponding TDM AC. 1144 b. PE1 MUST set the R bit in all PW packets sent back to PE2. 1146 On exit from the PW receive defect state: 1148 a. PE1 MUST cease AIS insertion into the corresponding TDM AC. 1149 b. PE1 MUST clear the R bit in all PW packets sent back to PE2. 1151 Note that AIS generation can in general be performed by both 1152 structure-aware and structure-agnostic PEs. 1154 9.3.2. PW transmit defect state entry/exit 1156 On entry to the PW Transmit Defect State: 1158 * A structure-aware PE1 MUST commence RDI insertion into the 1159 corresponding AC. 1161 On exit from the PW Transmit Defect State: 1163 * A structure-aware PE1 MUST cease RDI insertion into the 1164 corresponding AC. 1166 Note that structure-agnostic PEs are not capable of injecting RDI 1167 into an AC. 1169 9.3.3. AC receive defect state entry/exit 1171 On entry to the AC receive defect state and when operating in the 1172 single emulated OAM loop mode: 1174 a. PE1 SHOULD overwrite the TDM data with AIS in the PW packets sent 1175 towards PE2. 1176 b. PE1 MUST set the L bit in these packets. 1177 c. PE1 MAY omit the payload in order to conserve bandwidth. 1178 d. A structure-aware PE1 SHOULD send RDI back towards CE1. 1179 e. A structure-aware PE1 that detects a potentially correctable AC 1180 defect MAY use the M field to indicate this. 1182 On exit from the AC receive defect state and when operating in the 1183 single emulated OAM loop mode: 1185 a. PE1 MUST cease overwriting PW content with AIS and return to 1186 forwarding valid TDM data in PW packets sent towards PE2. 1187 b. PE1 MUST clear the L bit in PW packets sent towards PE2. 1188 c. A structure-aware PE1 MUST cease sending RDI towards CE1. 1190 10. Procedures for CEP PW Service 1192 The following procedures apply to SONET/SDH Circuit Emulation 1193 [RFC4842]. They are based on the single emulated OAM loop mode. 1195 Since SONET and SDH are inherently real-time in nature, many OAM 1196 indications must be generated or forwarded with minimal delay. This 1197 requirement rules out the use of messaging protocols, such as PW 1198 status messages. Thus, for CEP PWs alternate mechanisms are 1199 employed. 1201 The CEP PWE3 control word contains a set of flags used to indicate PW 1202 and AC defect conditions. The L bit is a forward defect indication 1203 used by the upstream PE to signal to the downstream PE a defect in 1204 its local attachment circuit. The R bit is a PW reverse defect 1205 indication used by the PE to signal PSN failures to the remote PE. 1206 The combination of N and P bits is used by the local PE to signal 1207 loss of pointer to the remote PE. 1209 The fact that CEP PW packets are sent at a known constant rate can be 1210 exploited as an OAM mechanism. Thus, a PE enters the PW receive 1211 defect state when it loses packet synchronization. It exits this 1212 state when it regains packet synchronization. See [RFC4842] for 1213 further details. 1215 10.1. Defect states 1217 10.1.1. PW receive defect state entry/exit 1219 In addition to the conditions specified in Section 6.2.1, PE1 will 1220 enter the PW receive defect state when one of the following becomes 1221 true: 1223 o It receives packets with the L bit set. 1224 o It receives packets with both the N and P bits set. 1225 o It loses packet synchronization. 1227 10.1.2. PW transmit defect state entry/exit 1229 In addition to the conditions specified in Section 6.2.2, PE1 will 1230 enter the PW transmit defect state if it receives packets with the R 1231 bit set. 1233 10.1.3. AC receive defect state entry/exit 1235 PE1 enters the AC receive defect state when any of the following 1236 conditions are met: 1238 a. It detects a physical layer fault on the TDM interface (Loss of 1239 Signal, Loss of Alignment, etc.). 1241 b. It is notified of a previous physical layer fault by detecting of 1242 AIS. 1244 The exact conditions under which a PE enters and exits the AIS state 1245 are defined in [G.707] and [G.783]. 1247 10.1.4. AC transmit defect state entry/exit 1249 The AC transmit defect state is not valid for CEP PWs. RDI signals 1250 are forwarded transparently. 1252 10.2. Consequent Actions 1254 10.2.1. PW receive defect state entry/exit 1256 On entry to the PW receive defect state: 1258 a. PE1 MUST commence AIS-P/V insertion into the corresponding AC. 1259 See [RFC4842]. 1260 b. PE1 MUST set the R bit in all PW packets sent back to PE2. 1262 On exit from the PW receive defect state: 1264 a. PE1 MUST cease AIS-P/V insertion into the corresponding AC. 1265 b. PE1 MUST clear the R bit in all PW packets sent back to PE2. 1267 See [RFC4842] for further details. 1269 10.2.2. PW transmit defect state entry/exit 1271 On entry to the PW Transmit Defect State: 1273 a. A structure-aware PE1 MUST commence RDI insertion into the 1274 corresponding AC. 1276 On exit from the PW Transmit Defect State: 1278 a. A structure-aware PE1 MUST cease RDI insertion into the 1279 corresponding AC. 1281 10.2.3. AC receive defect state entry/exit 1283 On entry to the AC receive defect state: 1285 a. PE1 MUST set the L bit in these packets. 1286 b. If Dynamic Bandwidth Allocation (DBA) has been enabled, PE1 MAY 1287 omit the payload in order to conserve bandwidth. 1288 c. If Dynamic Bandwidth Allocation (DBA) is not enabled PE1 SHOULD 1289 insert AIS-V/P in the SDH/SONET client layer in the PW packets 1290 sent towards PE2. 1292 On exit from the AC receive defect state: 1294 a. PE1 MUST cease overwriting PW content with AIS-P/V and return to 1295 forwarding valid data in PW packets sent towards PE2. 1296 b. PE1 MUST clear the L bit in PW packets sent towards PE2. 1298 See [RFC4842] for further details. 1300 11. Security Considerations 1302 The mapping messages described in this document do not change the 1303 security functions inherent in the actual messages. All generic 1304 security considerations applicable to PW traffic specified in Section 1305 10 of [RFC3985] are applicable to NS OAM messages transferred inside 1306 the PW. 1308 Security considerations in Section 10 of RFC 5085 for VCCV apply to 1309 the OAM messages thus transferred. Security considerations 1310 applicable to the PWE3 control protocol of RFC 4447 Section 8.2 apply 1311 to OAM indications transferred using the LDP status message. 1313 Since the mechanisms of this document enable propagation of OAM 1314 messages and fault conditions between native service networks and 1315 PSNs, continuity of the end-to-end service depends on a trust 1316 relationship between the operators of these networks. Security 1317 considerations for such scenarios are discussed in Section 7 of 1318 [RFC5254]. 1320 12. IANA Considerations 1322 This document requires no IANA actions. 1324 13. Contributors and Acknowledgments 1326 Mustapha Aissaoui, Peter Busschbach, Luca Martini, Monique Morrow, 1327 Thomas Nadeau, and Yaakov (J) Stein, were each, in turn, editors of 1328 one or more revisions of this document. All of the above were 1329 contributing authors, as was Dave Allan, david.i.allan@ericsson.com. 1331 The following contributed significant ideas or text: 1332 Matthew Bocci, matthew.bocci@alcatel-lucent.co.uk 1333 Simon Delord, Simon.A.DeLord@team.telstra.com 1334 Yuichi Ikejiri, y.ikejiri@ntt.com 1335 Kenji Kumaki, kekumaki@kddi.com 1336 Satoru Matsushima, satoru.matsushima@tm.softbank.co.jp 1337 Teruyuki Oya, teruyuki.oya@tm.softbank.co.jp 1338 Carlos Pignataro, cpignata@cisco.com 1339 Vasile Radoaca, vasile.radoaca@alcatel-lucent.com 1340 Himanshu Shah, hshah@ciena.com 1341 David Watkinson, david.watkinson@alcatel-lucent.com 1343 The editors would like to acknowledge the contributions of Bertrand 1344 Duvivier, Adrian Farrel, Tiberiu Grigoriu, Ron Insler, Michel 1345 Khouderchah, Vanson Lim, Amir Maleki, Neil McGill, Chris Metz, Hari 1346 Rakotoranto, Eric Rosen, Mark Townsley, and Ben Washam. 1348 14. References 1350 14.1. Normative References 1352 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1353 Requirement Levels", BCP 14, RFC 2119, March 1997. 1355 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 1356 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1357 February 2006. 1359 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 1360 Heron, "Pseudowire Setup and Maintenance Using the Label 1361 Distribution Protocol (LDP)", RFC 4447, April 2006. 1363 [RFC4553] Vainshtein, A. and YJ. Stein, "Structure-Agnostic Time 1364 Division Multiplexing (TDM) over Packet (SAToP)", 1365 RFC 4553, June 2006. 1367 [RFC4591] Townsley, M., Wilkie, G., Booth, S., Bryant, S., and J. 1368 Lau, "Frame Relay over Layer 2 Tunneling Protocol Version 1369 3 (L2TPv3)", RFC 4591, August 2006. 1371 [RFC4619] Martini, L., Kawa, C., and A. Malis, "Encapsulation 1372 Methods for Transport of Frame Relay over Multiprotocol 1373 Label Switching (MPLS) Networks", RFC 4619, 1374 September 2006. 1376 [RFC4717] Martini, L., Jayakumar, J., Bocci, M., El-Aawar, N., 1377 Brayley, J., and G. Koleyni, "Encapsulation Methods for 1378 Transport of Asynchronous Transfer Mode (ATM) over MPLS 1379 Networks", RFC 4717, December 2006. 1381 [RFC4842] Malis, A., Pate, P., Cohen, R., and D. Zelig, "Synchronous 1382 Optical Network/Synchronous Digital Hierarchy (SONET/SDH) 1383 Circuit Emulation over Packet (CEP)", RFC 4842, 1384 April 2007. 1386 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1387 Specification", RFC 5036, October 2007. 1389 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 1390 Connectivity Verification (VCCV): A Control Channel for 1391 Pseudowires", RFC 5085, December 2007. 1393 [RFC5641] McGill, N. and C. Pignataro, "Layer 2 Tunneling Protocol 1394 Version 3 (L2TPv3) Extended Circuit Status Values", 1395 RFC 5641, August 2009. 1397 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1398 (BFD)", RFC 5880, June 2010. 1400 [RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding 1401 Detection (BFD) for the Pseudowire Virtual Circuit 1402 Connectivity Verification (VCCV)", RFC 5885, June 2010. 1404 [G.707] "Network node interface for the synchronous digital 1405 hierarchy", ITU-T Recommendation G.707, December 2003. 1407 [G.775] "Loss of Signal (LOS), Alarm Indication Signal(AIS) and 1408 Remote Defect Indication (RDI) defect detection and 1409 clearance criteria for PDH signals", ITU-T Recommendation 1410 G.775, October 1998. 1412 [G.783] "Characteristics of synchronous digital hierarchy (SDH) 1413 equipment functional blocks", ITU-T Recommendation G.783, 1414 March 2006. 1416 [I.610] "B-ISDN operation and maintenance principles and 1417 functions", ITU-T Recommendation I.610, February 1999. 1419 [Q.933] "ISDN Digital Subscriber Signalling System No. 1 (DSS1) 1420 Signalling specifications for frame mode switched and 1421 permanent virtual connection control and status 1422 monitoring", ITU-T Recommendation Q.993, February 2003. 1424 14.2. Informative References 1426 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1427 RFC 792, September 1981. 1429 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1430 Label Switching Architecture", RFC 3031, January 2001. 1432 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1433 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1434 Tunnels", RFC 3209, December 2001. 1436 [RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for 1437 Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, 1438 September 2004. 1440 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 1441 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 1443 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 1444 Edge (PWE3) Architecture", RFC 3985, March 2005. 1446 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating 1447 MPLS in IP or Generic Routing Encapsulation (GRE)", 1448 RFC 4023, March 2005. 1450 [RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. 1451 Matsushima, "Operations and Management (OAM) Requirements 1452 for Multi-Protocol Label Switched (MPLS) Networks", 1453 RFC 4377, February 2006. 1455 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 1456 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 1457 Use over an MPLS PSN", RFC 4385, February 2006. 1459 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 1460 Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 1462 [RFC4454] Singh, S., Townsley, M., and C. Pignataro, "Asynchronous 1463 Transfer Mode (ATM) over Layer 2 Tunneling Protocol 1464 Version 3 (L2TPv3)", RFC 4454, May 2006. 1466 [RFC5086] Vainshtein, A., Sasson, I., Metz, E., Frost, T., and P. 1467 Pate, "Structure-Aware Time Division Multiplexed (TDM) 1468 Circuit Emulation Service over Packet Switched Network 1469 (CESoPSN)", RFC 5086, December 2007. 1471 [RFC5087] Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi, 1472 "Time Division Multiplexing over IP (TDMoIP)", RFC 5087, 1473 December 2007. 1475 [RFC5254] Bitar, N., Bocci, M., and L. Martini, "Requirements for 1476 Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", 1477 RFC 5254, October 2008. 1479 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. 1480 Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011. 1482 [I-D.ietf-pwe3-mpls-eth-oam-iwk] 1483 Qiu, R., Mohan, D., Bitar, N., DeLord, S., Niger, P., and 1484 A. Sajassi, "MPLS and Ethernet OAM Interworking", 1485 draft-ietf-pwe3-mpls-eth-oam-iwk-04 (work in progress), 1486 March 2011. 1488 [I-D.ietf-pwe3-static-pw-status] 1489 Martini, L., Swallow, G., Heron, G., and M. Bocci, 1490 "Pseudowire Status for Static Pseudowires", 1491 draft-ietf-pwe3-static-pw-status-03 (work in progress), 1492 March 2011. 1494 [I.620] "Frame relay operation and maintenance principles and 1495 functions", ITU-T Recommendation I.620, October 1996. 1497 Appendix A. Native Service Management (informative) 1499 A.1. Frame Relay Management 1501 The management of Frame Relay Bearer Service (FRBS) connections can 1502 be accomplished through two distinct methodologies: 1504 a. Based on ITU-T Q.933 Annex A, Link Integrity Verification 1505 procedure, where STATUS and STATUS ENQUIRY signaling messages are 1506 sent using DLCI=0 over a given UNI and NNI physical link. 1507 b. Based on FRBS LMI, and similar to ATM ILMI where LMI is common in 1508 private Frame Relay networks. 1510 In addition, ITU-T I.620 [I.620] addressed Frame Relay loopback. 1511 This Recommendation was withdrawn in 2004 and its deployment was 1512 limited. 1514 It is possible to use either, or both, of the above options to manage 1515 Frame Relay interfaces. This document will refer exclusively to 1516 Q.933 messages. 1518 The status of any provisioned Frame Relay PVC may be updated through: 1520 a. Frame Relay STATUS messages in response to Frame Relay STATUS 1521 ENQUIRY messages; these are mandatory. 1522 b. Optional unsolicited STATUS updates independent of STATUS ENQUIRY 1523 (typically under the control of management system, these updates 1524 can be sent periodically (continuous monitoring) or only upon 1525 detection of specific defects based on configuration. 1527 In Frame Relay, a Data Link Connection (DLC) is either up or down. 1528 There is no distinction between different directions. To achieve 1529 commonality with other technologies, down is represented as a receive 1530 defect. 1532 Frame relay connection management is not implemented over the PW 1533 using either of the techniques native to FR, therefore PW mechanisms 1534 are used to synchronize the view each PE has of the remote Native 1535 Service/Attachment Circuit (NS/AC). A PE will treat a remote NS/AC 1536 failure in the same way it would treat a PW or PSN failure; that is 1537 using AC facing FR connection management to notify the CE that FR is 1538 down. 1540 A.2. ATM Management 1542 ATM management and OAM mechanisms are much more evolved than those of 1543 Frame Relay. There are five broad management-related categories, 1544 including fault management (FT), Performance management (PM), 1545 configuration management (CM), Accounting management (AC), and 1546 Security management (SM). [I.610] describes the functions for the 1547 operation and maintenance of the physical layer and the ATM layer, 1548 that is, management at the bit and cell levels. Because of its 1549 scope, this document will concentrate on ATM fault management 1550 functions. Fault management functions include the following: 1552 a. Alarm indication signal (AIS). 1553 b. Remote Defect indication (RDI). 1554 c. Continuity Check (CC). 1555 d. Loopback (LB). 1557 Some of the basic ATM fault management functions are described as 1558 follows: Alarm indication signal (AIS) sends a message in the same 1559 direction as that of the signal, to the effect that an error has been 1560 detected. 1562 Remote defect indication (RDI) sends a message to the transmitting 1563 terminal that an error has been detected. Alarms related to the 1564 physical layer are indicated using path AIS/RDI. Virtual path AIS/ 1565 RDI and virtual channel AIS/RDI are also generated for the ATM layer. 1567 OAM cells (F4 and F5 cells) are used to instrument virtual paths and 1568 virtual channels respectively with regard to their performance and 1569 availability. OAM cells in the F4 and F5 flows are used for 1570 monitoring a segment of the network and end-to-end monitoring. OAM 1571 cells in F4 flows have the same VPI as that of the connection being 1572 monitored. OAM cells in F5 flows have the same VPI and VCI as that 1573 of the connection being monitored. The AIS and RDI messages of the 1574 F4 and F5 flows are sent to the other network nodes via the VPC or 1575 the VCC to which the message refers. The type of error and its 1576 location can be indicated in the OAM cells. Continuity check is 1577 another fault management function. To check whether a VCC that has 1578 been idle for a period of time is still functioning, the network 1579 elements can send continuity-check cells along that VCC. 1581 Appendix B. PW Defects and Detection tools 1583 B.1. PW Defects 1585 Possible defects that impact PWs are the following: 1587 a. Physical layer defect in the PSN interface. 1588 b. PSN tunnel failure which results in a loss of connectivity between 1589 ingress and egress PE. 1590 c. Control session failures between ingress and egress PE. 1592 In case of an MPLS PSN and an MPLS/IP PSN there are additional 1593 defects: 1595 a. PW labeling error, which is due to a defect in the ingress PE, or 1596 to an over-writing of the PW label value somewhere along the LSP 1597 path. 1598 b. LSP tunnel Label swapping errors or LSP tunnel label merging 1599 errors in the MPLS network. This could result in the termination 1600 of a PW at the wrong egress PE. 1601 c. Unintended self-replication; e.g., due to loops or denial- of- 1602 service attacks. 1604 B.2. Packet Loss 1606 Persistent congestion in the PSN or in a PE could impact the proper 1607 operation of the emulated service. 1609 A PE can detect packet loss resulting from congestion through several 1610 methods. If a PE uses the sequence number field in the PWE3 Control 1611 Word for a specific Pseudowire [RFC3985] and [RFC4385], it has the 1612 ability to detect packet loss. Translation of congestion detection 1613 to PW defect states is beyond the scope of this document. 1615 There are congestion alarms that are raised in the node and to the 1616 management system when congestion occurs. The decision to declare 1617 the PW Down and to select another path is usually at the discretion 1618 of the network operator. 1620 B.3. PW Defect Detection Tools 1622 To detect the defects listed above, Service Providers have a variety 1623 of options available. 1625 Physical Layer defect detection and notification mechanisms include 1626 SONET/SDH Loss of Signal (LOS), Loss of Alignment (LOA), and AIS/RDI. 1628 PSN defect detection mechanisms vary according to the PSN type. 1630 For PWs over L2TPv3/IP PSNs, with L2TP as encapsulation protocol, the 1631 defect detection mechanisms described in [RFC3931] apply. These 1632 include, for example, the keep-alive mechanism performed with Hello 1633 messages for detection of loss of connectivity between a pair of 1634 LCCEs (i.e., dead PE peer and path detection). Furthermore, the 1635 tools Ping and Traceroute, based on ICMP Echo Messages [RFC0792] 1636 apply and can be used to detect defects on the IP PSN. Additionally, 1637 VCCV-Ping [RFC5085] and VCCV-BFD [RFC5885] can also be used to detect 1638 defects at the individual pseudowire level. 1640 For PWs over MPLS or MPLS/IP PSNs, several tools can be used: 1642 a. LSP-Ping and LSP-Traceroute [RFC4379] for LSP tunnel connectivity 1643 verification. 1644 b. LSP-Ping with Bi-directional Forwarding Detection [RFC5885] for 1645 LSP tunnel continuity checking. 1646 c. Furthermore, if RSVP-TE is used to setup the PSN Tunnels between 1647 ingress and egress PE, the hello protocol can be used to detect 1648 loss of connectivity [RFC3209], but only at the control plane. 1650 B.4. PW specific defect detection mechanisms 1652 [RFC4377] describes how LSP-Ping and BFD can be used over individual 1653 PWs for connectivity verification and continuity checking 1654 respectively. 1656 Furthermore, the detection of a fault could occur at different points 1657 in the network and there are several ways the observing PE determines 1658 a fault exists: 1660 a. Egress PE detection of failure (e.g., BFD). 1661 b. Ingress PE detection of failure (e.g., LSP-PING). 1662 c. Ingress PE notification of failure (e.g. RSVP Path-err). 1664 Authors' Addresses 1666 Mustapha Aissaoui 1667 Alcatel-Lucent 1668 600 March Rd 1669 Kanata, ON K2K 2E6 1670 Canada 1672 Email: mustapha.aissaoui@alcatel-lucent.com 1674 Peter Busschbach 1675 Alcatel-Lucent 1676 67 Whippany Rd 1677 Whippany, NJ 07981 1678 USA 1680 Email: busschbach@alcatel-lucent.com 1682 Luca Martini 1683 Cisco Systems, Inc. 1684 9155 East Nichols Avenue, Suite 400 1685 Englewood, CO 80112 1686 USA 1688 Email: lmartini@cisco.com 1690 Monique Morrow 1691 Cisco Systems, Inc. 1692 Richtistrase 7 1693 CH-8304 Wallisellen 1694 Switzerland 1696 Email: mmorrow@cisco.com 1698 Thomas Nadeau 1699 CA Technologies 1700 273 Corporate Dr. 1701 Portsmouth, NH 03801 1702 USA 1704 Email: Thomas.Nadeau@ca.com 1705 Yaakov (Jonathan) Stein 1706 RAD Data Communications 1707 24 Raoul Wallenberg St., Bldg C 1708 Tel Aviv 69719 1709 ISRAEL 1711 Email: yaakov_s@rad.com