idnits 2.17.1 draft-ietf-pwe3-oam-msg-map-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3985]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 188 has weird spacing: '... PWs are ...' -- 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.) -- The document date (April 15, 2009) is 5487 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) == Missing Reference: 'RFC792' is mentioned on line 1725, but not defined == Missing Reference: 'RFC3209' is mentioned on line 1741, but not defined == Unused Reference: 'ICMP' is defined on line 1440, but no explicit reference was found in the text == Unused Reference: 'CONGESTION' is defined on line 1488, but no explicit reference was found in the text == Unused Reference: 'RFC4717' is defined on line 1521, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'BFD' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-T G.707' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-T G.775' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-T G.806' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-T I.610' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-T I.620' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-T Q.933' ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-vccv-bfd-02 == Outdated reference: A later version (-02) exists of draft-ietf-pwe3-congestion-frmwk-01 Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Mustapha Aissaoui 2 Internet Draft Peter Busschbach 3 Expires: October 2009 Alcatel-Lucent 5 Dave Allan 6 Nortel 8 Monique Morrow 9 Luca Martini 10 Cisco Systems Inc. 12 Thomas Nadeau 13 BT 15 Yaakov Stein 16 RAD Data Communications 18 Editors 20 April 15, 2009 22 Pseudo Wire (PW) OAM Message Mapping 23 draft-ietf-pwe3-oam-msg-map-10.txt 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on October 15, 2009. 48 Copyright and License Notice 50 Copyright (c) 2009 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents in effect on the date of 55 publication of this document (http://trustee.ietf.org/license-info). 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. 59 Abstract 61 This document specifies the mapping and notification of defect states 62 between a Pseudo Wire and the Attachment Circuits (AC) of the end-to- 63 end emulated service. This document covers the case whereby the ACs 64 and the PWs are of the same type in accordance to the PWE3 65 architecture [RFC3985] such that a homogenous PW service can be 66 constructed. 68 Conventions used in this document 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 72 document are to be interpreted as described in RFC-2119. 74 Table of Contents 76 1. Acknowledgments................................................4 77 2. Contributors...................................................4 78 3. Introduction...................................................5 79 4. Terminology....................................................5 80 5. Reference Model and Defect Locations...........................7 81 6. Abstract Defect States.........................................8 82 7. OAM Models....................................................10 83 8. PW Defect States and Defect Notifications.....................12 84 8.1. PW Defect Notification Mechanisms........................12 85 8.1.1. LDP Status TLV......................................13 86 8.1.2. L2TP Circuit Status AVP.............................14 87 8.1.3. BFD Diagnostic Codes................................16 88 8.2. PW Defect State Entry/Exit...............................18 89 8.2.1. PW receive defect state entry/exit criteria.........18 90 8.2.2. PW transmit defect state entry/exit criteria........19 91 9. Procedures for ATM PW Service.................................19 92 9.1. AC receive defect state entry/exit criteria..............19 93 9.2. AC transmit defect state entry/exit criteria.............20 94 9.3. Consequent Actions.......................................21 95 9.3.1. PW receive defect state entry/exit..................21 96 9.3.2. PW transmit defect state entry/exit.................22 97 9.3.3. PW defect state in ATM Port Mode PW Service.........22 98 9.3.4. AC receive defect state entry/exit..................22 99 9.3.5. AC transmit defect state entry/exit.................24 100 10. Procedures for Frame Relay PW Service........................24 101 10.1. AC receive defect state entry/exit criteria.............24 102 10.2. AC transmit defect state entry/exit criteria............24 103 10.3. Consequent Actions......................................25 104 10.3.1. PW receive defect state entry/exit.................25 105 10.3.2. PW transmit defect state entry/exit................25 106 10.3.3. PW defect state in the FR Port Mode PW service.....26 107 10.3.4. AC receive defect state entry/exit.................26 108 10.3.5. AC transmit defect state entry/exit................26 109 11. Procedures for TDM PW Service................................26 110 11.1. AC receive defect state entry/exit criteria.............27 111 11.2. AC transmit defect state entry/exit criteria............27 112 11.3. Consequent Actions......................................28 113 11.3.1. PW receive defect state entry/exit.................28 114 11.3.2. PW transmit defect state entry/exit................28 115 11.3.3. AC receive defect state entry/exit.................28 116 12. Procedures for CEP PW Service................................29 117 12.1. Defect states...........................................30 118 12.1.1. PW receive defect state entry/exit criteria........30 119 12.1.2. PW transmit defect state entry/exit criteria.......30 120 12.1.3. AC receive defect state entry/exit criteria........30 121 12.1.4. AC transmit defect state entry/exit criteria.......30 122 12.2. Consequent actions......................................31 123 12.2.1. PW receive defect state entry/exit.................31 124 12.2.2. PW transmit defect state entry/exit................31 125 12.2.3. AC receive defect state entry/exit.................31 126 13. Security Considerations......................................32 127 14. IANA Considerations..........................................32 128 15. References...................................................32 129 15.1. Normative References....................................32 130 15.2. Informative References..................................33 131 16. Editor's Addresses...........................................34 132 Informative Appendix A: Native Service Management................35 133 - Frame Relay Management.....................................35 134 - ATM Management.............................................36 135 Informative Appendix B: PW Defects and Detection tools...........37 136 - PW Defects.................................................37 137 - Packet Loss.............................................38 138 - PW Defect Detection Tools..................................38 140 1. Acknowledgments 142 The editors would like to acknowledge the important contributions of 143 Hari Rakotoranto, Eric Rosen, Mark Townsley, Michel Khouderchah, 144 Bertrand Duvivier, Vanson Lim, Chris Metz, Ben Washam, Tiberiu 145 Grigoriu, Neil McGill, and Amir Maleki. 147 2. Contributors 149 Thomas D. Nadeau, tom.nadeau@bt.com 151 Monique Morrow, mmorrow@cisco.com 153 Peter B. Busschbach, busschbach@alcatel-lucent.com 155 Mustapha Aissaoui, mustapha.aissaoui@alcatel-lucent.com 157 Matthew Bocci, matthew.bocci@alcatel-lucent.co.uk 159 David Watkinson, david.watkinson@alcatel-lucent.com 161 Yuichi Ikejiri, y.ikejiri@ntt.com 163 Kenji Kumaki, kekumaki@kddi.com 165 Satoru Matsushima, satoru@ft.solteria.net 167 David Allan, dallan@nortel.com 169 Himanshu Shah, hshah@ciena.com 171 Simon Delord, sdelord@uecomm.com.au 173 Vasile Radoaca, vasile.radoaca@alcatel-lucent.com 175 Carlos Pignataro, cpignata@cisco.com 177 Luca Martini, lmartini@cisco.com 179 Yaakov (J) Stein, yaakov_s@rad.com 181 Teruyuki Oya, teruyuki.oya@tm.softbank.co.jp 183 3. Introduction 185 This document specifies the mapping and notification of defect states 186 between a Pseudo Wire and the Attachment Circuits (AC) of the end- 187 to-end emulated service. It covers the case whereby the ACs and the 188 PWs are of the same type in accordance to the PWE3 architecture 189 [RFC3985] such that a homogeneous PW service can be constructed. 191 This document is motivated by the requirements put forth in [RFC4377] 192 and [RFC3916]. Its objective is to standardize the behavior of PEs 193 with respects to failures on PWs and ACs, so that there is no 194 ambiguity about the alarms generated and consequent actions 195 undertaken by PEs in response to specific failure conditions. 197 This document covers PWE over MPLS PSN, PWE over MPLS-IP PSN and PWE 198 over L2TP-IP PSN. 200 The Ethernet PW service is covered in a separate document [ETH-OAM- 201 IWK]. 203 4. Terminology 205 AIS Alarm Indication Signal 207 AC Attachment circuit 209 BDI Backward Defect Indication 211 CC Continuity Check 213 CE Customer Edge 215 CPCS Common Part Convergence Sub-layer 217 DLC Data Link Connection 219 FDI Forward Defect Indication 221 FRBS Frame Relay Bearer Service 223 IWF Interworking Function 225 LB Loopback 227 NE Network Element 229 NS Native Service 230 OAM Operations and Maintenance 232 PE Provider Edge 234 PW Pseudowire 236 PSN Packet Switched Network 238 RDI Remote Defect Indication 240 SDU Service Data Unit 242 VCC Virtual Channel Connection 244 VPC Virtual Path Connection 246 The rest of this document will follow the following conventions. 248 The words "defect" and "fault" are used inter-changeably to mean a 249 condition which causes user packets not to be forwarded between the 250 CE endpoints of the PW service. 252 The words "defect notification" and "defect indication" are used 253 inter-changeably to mean an OAM message generated by a PE and sent to 254 other nodes in the network to convey the defect state local to this 255 PE. 257 The PW can ride over three types of Packet Switched Network (PSN). A 258 PSN which makes use of LSPs as the tunneling technology to forward 259 the PW packets will be referred to as an MPLS PSN. A PSN which makes 260 use of MPLS-in-IP tunneling [RFC4023], with an MPLS shim header used 261 as PW demultiplexer, will be referred to as an MPLS-IP PSN. A PSN 262 which makes use of L2TPv3 [RFC3931] as the tunneling technology with 263 the L2TPv3 Session ID as the PW demultiplexer will be referred to as 264 L2TP-IP PSN. 266 If LSP-Ping [RFC4379] is run over a PW as described in [RFC4377], it 267 will be referred to as VCCV-Ping. 269 If BFD is run over a PW as described in [RFC4377], it will be 270 referred to as VCCV-BFD [VCCV-BFD]. 272 In the context of this document a PE forwards packets between an AC 273 and a PW. The other PE that terminates the PW is the peer PE or 274 remote PE and the attachment circuit associated with the far-end PW 275 termination is the remote AC. 277 Defects are discussed in the context of defect states, and the 278 criteria to enter and exit the defect state. The direction of defects 279 is discussed from the perspective of the observing PE. 281 A receive defect is one that impacts information transfer to the 282 observing PE. It impacts the observing PEs ability to receive 283 information. 285 A transmit defect is one that uniquely impacts information sent or 286 relayed by the observing PE. 288 A receive defect generally also impacts information sent or relayed 289 by the observing PE. Therefore the receive defect state is considered 290 to be a superset of the two defect states. Thus, when a PE enters 291 both receive and transmit defect states related to the same PW 292 service, the receive defect takes precedence over the transmit defect 293 in terms of the consequent actions. 295 A forward defect indication is sent in the same direction as the user 296 traffic impacted by the defect. A reverse defect indication is sent 297 in the opposite direction of the traffic impacted by the defect. 299 5. Reference Model and Defect Locations 301 Figure 1 illustrates the PWE3 network reference model with an 302 indication of the possible defect locations. This model will be 303 referenced in the remainder of this document for describing the OAM 304 procedures. 306 ACs PSN tunnel ACs 307 +----+ +----+ 308 +----+ | PE1|==================| PE2| +----+ 309 | |---(a)---(b)..(c)......PW1..(d)..(c)..(f)---(e)---| | 310 | CE1| (N1) | | | | (N2) |CE2 | 311 | |----------|............PW2.............|----------| | 312 +----+ | |==================| | +----+ 313 ^ +----+ +----+ ^ 314 | Provider Edge 1 Provider Edge 2 | 315 | | 316 |<-------------- Emulated Service ---------------->| 317 Customer Customer 318 Edge 1 Edge 2 319 Figure 1: PWE3 Network Defect Locations 321 In all interworking scenarios described in this document, it is 322 assumed the AC and the PW are of the same type at PE1. The procedures 323 described in this document apply to PE1. PE2 implements the identical 324 functionality for a homogeneous service (although it is not required 325 to as long as the notifications across the PWs are consistent). 327 The following is a brief description of the defect locations: 329 a. Defect in the first native service network (N1). This covers 330 any defect in the N1 which impacts all or a subset of ACs 331 terminating in PE1. The defect is conveyed to PE1 and to the 332 remote native service network (N2) using the native service 333 specific OAM defect indication. 334 b. Defect on a PE1 AC interface. 335 c. Defect on a PE1 PSN interface. 336 d. Defect in the PSN network. This covers any defect in the PSN 337 which impacts all or a subset of PWs terminating in a PE. The 338 defect is conveyed to the PE using a PSN and/or a PW specific 339 OAM defect indication. Note that both data plane defects and 340 control plane defects must be taken into consideration. Even 341 though control messages may follow a different path than the 342 PW data plane traffic, a control plane failure may affect the 343 PW status. 344 e. Defect in the second native service network (N2). This covers 345 any defect in N2 which impacts all or a subset of ACs 346 terminating in PE2 (which is considered a remote AC defect in 347 the context of procedures outlined in this draft). The defect 348 is conveyed to PE2 and to the remote native service network 349 (N1) using the native service OAM defect indication. 350 f. Defect on a PE2 AC interface (which is also considered a 351 remote AC defect in the context of this draft). 353 6. Abstract Defect States 355 PE1 must track four defect states that reflect the observed states of 356 both directions of the PW service on both the AC and the PW sides. 357 Defects may impact one or both directions of the PW service. 359 The observed state is a combination of defects directly detected by 360 PE1 and defects it has been made aware of via notifications. 362 +-----+ 363 ----AC receive---->| |-----PW transmit----> 364 CE1 | PE1 | PE2/CE2 365 <---AC transmit-----| |<----PW receive----- 366 +-----+ 368 (arrows indicate direction of user traffic impacted by a defect) 369 Figure 2: Receive and Transmit Defect States 371 PE1 will directly detect or be notified of AC receive or PW receive 372 defects as they occur upstream of PE1 and impact traffic being sent 373 to PE1. As a result, PE1 enters the AC or PW receive defect state. 375 In Figure 2, PE1 may be notified of a receive defect in the AC by 376 receiving a Forward Defect indication, e.g., ATM AIS, from an ATM 377 switch in network N1. This defect notification indicates that user 378 traffic sent by CE1 may not be received by PE1 due to a defect. PE1 379 can also directly detect an AC receive defect if it resulted from a 380 failure of the receive side in the local port or link over which the 381 AC is configured. 383 Similarly, PE1 may detect or be notified of a receive defect in the 384 PW by receiving a Forward Defect indication from PE2. If PW status is 385 used for fault notification, this message will indicate a Local PSN- 386 facing PW (egress) Transmit Fault or a Local Attachment Circuit 387 (ingress) Receive Fault at PE2, as described in Section 8.1.1. . This 388 defect notification indicates that user traffic sent by CE2 may not 389 be received by PE1 due to a defect. As a result, PE1 enters the PW 390 receive defect state. 392 Note that a Forward Defect indication is sent in the same direction 393 as the user traffic impacted by the defect. 395 Generally, a PE cannot detect transmit defects directly and will 396 therefore need to be notified of AC transmit or PW transmit defects 397 by other devices. 399 In Figure 2, PE1 may be notified of a transmit defect in the AC by 400 receiving a Reverse Defect indication, e.g., ATM RDI, from CE1. This 401 defect relates to the traffic sent by PE1 to CE1 on the AC. 403 Similarly, PE1 may be notified of a transmit defect in the PW by 404 receiving a Reverse Defect indication from PE2. If PW status is used 405 for fault notification, this message will indicate a Local PSN-facing 406 PW (ingress) Receive Fault or a Local Attachment Circuit (egress) 407 Transmit Fault at PE2, as described in Section 8.1.1. . This defect 408 impacts the traffic sent by PE1 to CE2. As a result, PE1 enters the 409 PW transmit defect state. 411 Note that a Reverse Defect indication is sent in the reverse 412 direction to the user traffic impacted by the defect. 414 The procedures outlined in this document define the entry and exit 415 criteria for each of the four states with respect to the set of PW 416 services within the document scope and the consequent actions that 417 PE1 must perform. 419 When a PE enters both receive and transmit defect states related to 420 the same PW service, then the receive defect takes precedence over 421 transmit defect in terms of the consequent actions. 423 7. OAM Models 425 A homogeneous PW service forwards packets between an AC and a PW of 426 the same type. It thus implements both a Native Service OAM 427 mechanism and a PW OAM mechanism. PW OAM defect notification 428 messages are described in Section 8.1. Native Service (NS) OAM 429 messages are described in Appendix A. 431 This document defines two different modes for operating OAM on a PW 432 service which dictate the mapping between the NS OAM the PW OAM 433 defect notification messages. 435 The first one operates a single emulated OAM loop end-to-end between 436 the endpoints of the PW service. This is referred to as "single 437 emulated OAM loop" mode and is illustrated in Figure 3. 439 |<----- AC ----->|<----- PW ----->|<----- AC ----->| 440 | | | | 441 ___ ===============_ 442 |CE|---=NS-OAM=>---(---=NS-OAM=>---)---=NS-OAM=>---|CE| 443 =============== / 444 \ / 445 ---=PW-OAM=>--- 447 Figure 3: Single Emulated OAM Loop mode 449 This mode implements the following behavior. We use the words 450 upstream and downstream to identify PEs in relation to a specific 451 traffic direction. 452 a. An upstream PE node MUST transparently relay NS OAM messages 453 over the PW. 455 b. An upstream PE node MUST signal local failures affecting the 456 AC using a NS defect notification OAM message sent over the 457 PW. In the case that it is not possible to generate NS OAM 458 messages (e.g. because the defect interferes with NS OAM 459 message generation) the PE MUST signal local failures 460 affecting the AC using a PW defect notification OAM message. 461 c. An upstream PE node MUST signal local failures affecting the 462 PW using a PW defect notification OAM message. 463 d. A downstream PE node MUST insert a NS defect notification OAM 464 message into the AC when it detects or is notified of a 465 defect in the PW or remote AC. This includes receiving a PW 466 defect notification message and translating it into a NS 467 defect notification OAM message over the AC. The latter is 468 required for handling defects signaled by a peer PE with PW 469 OAM messaging. 471 The "single emulated OAM loop" mode is suitable for PW services 472 which have a widely deployed NS OAM mechanism that operates within 473 the AC. This document specifies the use of this mode for ATM PW, TDM 474 PW, and CEP PW services. It is the default mode of operation for all 475 ATM cell-mode PW services and the only mode specified for TDM and 476 CEP PW services. It is optional for AAL5 PDU transport and AAL5 SDU 477 transport modes. 479 The second mode operates three OAM loops which join at the AC/PW 480 boundary of a PE. This is referred to as "coupled OAM loops" mode 481 and is illustrated in Figure 4. 483 |<----- AC ----->|<----- PW ----->|<----- AC ----->| 484 | | | | 485 __ ===============__ 486 |CE|---=NS-OAM=>---(---------------)---=NS-OAM=>---|CE| 487 \ =============== / 488 \ / 489 \ / 490 -------=PW-OAM=>------ 492 Figure 4: Coupled OAM Loops mode 494 This mode implements the following behavior. We use the words 495 upstream and downstream to identify PEs in relation to a specific 496 traffic direction. 497 a. An upstream PE node MUST terminate and translate a received 498 NS defect notification OAM message to a PW defect 499 notification message. 501 b. An upstream PE node MUST signal local failures affecting the 502 AC using a PW defect notification OAM message to the remote 503 PE. 504 c. An upstream PE node MUST signal local failures affecting the 505 PW using a PW defect notification OAM message. 506 d. A downstream PE node MUST insert a NS defect notification OAM 507 message into the AC when it detects or is notified of a 508 defect in the PW or remote AC. This includes support 509 receiving a PW defect notification message and translating it 510 into a NS defect notification OAM message over the AC. 512 This document specifies the "coupled OAM loops" mode as the default 513 mode for a FR PW service and for ATM AAL5 PDU transport and AAL5 SDU 514 transport services and as optional for ATM VCC cell mode services. 515 It does not specify the use of this mode for TDM PW, CEP PW, and ATM 516 VPC cell mode PW services. In the latter last case, a PE node must 517 pass transparently VC-level (F5) ATM OAM cells over the PW while 518 terminating and translating VP-level (F4) OAM cells. Thus, it cannot 519 operate a pure "coupled OAM loops" mode. 521 8. PW Defect States and Defect Notifications 523 8.1. PW Defect Notification Mechanisms 525 For a MPLS PSN and a MPLS-IP PSN, a PE node which establishes a PW 526 using LDP SHALL use LDP status TLV as the mechanism for AC and PW 527 status and defect notification [RFC4447]. Additionally, a PE node MAY 528 use VCCV-BFD Connectivity Verification (CV) types for fault detection 529 only but SHOULD notify the remote PE using LDP Status TLV. These CV 530 types are 0x04 and 0x10 [VCCV-BFD]. 532 A PE node which establishes a PW using other means than LDP, e.g., 533 static configuration, MAY use VCCV-BFD CV types for AC and PW status 534 and defect notification. These CV types are 0x08 and 0x20 [VCCV-BFD]. 535 These CV types SHOULD NOT be used when the PW is established with the 536 LDP control plane. 538 For a L2TP-IP PSN, A PE node SHOULD use the Circuit Status AVP as the 539 mechanism for AC and PW status and defect notification. In its most 540 basic form, the Circuit Status AVP [RFC3931] in a Set-Link-Info (SLI) 541 message can signal active/inactive AC status. The Circuit Status AVP 542 is proposed to be extended to convey status and defects in the AC and 543 the PSN-facing PW in both ingress and egress directions, i.e., four 544 independent status bits without the need to tear down the sessions or 545 control connection [L2TP-Status]. 547 When a PE does not support the Circuit Status AVP, it MAY use the 548 StopCCN and the CDN message to bring down L2TP sessions in a similar 549 way LDP uses the Label Withdrawal to bring down a PW. A PE node may 550 use the StopCCN to shutdown the L2TP control connection, and 551 implicitly all L2TP sessions associated with that control connection 552 without any explicit session control messages. This is in the case of 553 a failure which impacts all L2TP sessions, i.e., all PWs, managed by 554 the control connection. It may use the CDN message to disconnect a 555 specific L2TP session when a failure affects a specific PW. 557 Additionally, a PE node MAY use VCCV-BFD CV types 0x04 and 0x10 for 558 fault detection only but SHOULD notify the remote PE using the 559 Circuit Status AVP. A PE node which establishes a PW using other 560 means than L2TP control plane MAY use VCCV-BFD CV types 0x08 and 0x20 561 for AC and PW status and defect notification. These CV types SHOULD 562 NOT be used when the PW is established with the L2TP control plane. 564 8.1.1. LDP Status TLV 566 [RFC4446] defines the following PW status code points: 568 0x00000000 - Pseudo Wire forwarding (clear all failures) 569 0x00000001 - Pseudo Wire Not Forwarding 570 0x00000002 - Local Attachment Circuit (ingress) Receive Fault 571 0x00000004 - Local Attachment Circuit (egress) Transmit Fault 572 0x00000008 - Local PSN-facing PW (ingress) Receive Fault 573 0x00000010 - Local PSN-facing PW (egress) Transmit Fault 575 [RFC4447] specifies that "Pseudo Wire forwarding" code point is used 576 to clear all faults. It also specifies that "Pseudo Wire Not 577 Forwarding" code is used to convey any other defect that cannot be 578 represented by the other code points. 580 The code points used in the LDP status TLV in a PW status 581 notification message convey the defect view of the originating PE. 583 The originating PE conveys this state in the form of a forward defect 584 or a reverse defect indication. 586 The forward and reverse defect indication definitions used in this 587 document map to the LDP Status TLV codes as follows: 589 Forward defect indication - corresponds to the logical OR of 591 Local Attachment Circuit (ingress) Receive Fault, 592 Local PSN-facing PW (egress) Transmit Fault, and 594 PW not Forwarding Fault 596 Reverse defect indication - corresponds to the logical OR of 598 Local Attachment Circuit (egress) Transmit Fault and 600 Local PSN-facing PW (ingress) Receive Fault 602 A PE SHALL thus use PW status notification messages to report all 603 failures affecting the PW service including, but not restricted, to 604 the following: 606 - Failures detected through defect detection mechanisms in 607 the MPLS and MPLS-IP PSN 609 - Failures detected through VCCV-Ping or VCCV-BFD CV types 610 0x04 and 0x10 for fault detection only 612 - Failures within the PE that result in an inability to 613 forward traffic between the AC and the PW 615 - Failures of the AC or in the L2 network affecting the AC 616 as per the rules detailed in Section 7. for the "single 617 emulated OAM loop" mode and "coupled OAM loops" mode. 619 Note that there are two situations which require PW label withdrawal 620 as opposed to a PW status notification by the PE. The first one is 621 when the PW is taken administratively down in accordance to 622 [RFC4447]. The second one is when the Target LDP session established 623 between the two PEs is lost. In the latter case, the PW labels will 624 need to be re-signaled when the Targeted LDP session is re- 625 established. 627 8.1.2. L2TP Circuit Status AVP 629 [RFC3931] defines the Circuit Status AVP in the Set-Link-Info (SLI) 630 message to exchange initial status and status changes in the circuit 631 to which the pseudowire is bound. [L2TP-Status] defines extensions to 632 the Circuit Status AVP that are analogous to the PW Status TLV 633 defined for LDP. Consequently, for L2TP-IP, the Circuit Status AVP 634 is used in the same fashion as the PW Status described in the 635 previous section. 637 If the extended Circuit Status bits are not supported, and instead 638 only the "A-bit" (Active) is used as described in [RFC3931], a PE MAY 639 use CDN messages to clear L2TPv3 sessions in the presence of session- 640 level failures detected in the L2TP-IP PSN. 642 A PE MUST set the Active bit in the Circuit Status to clear all 643 faults, and it MUST clear the Active bit in the Circuit Status to 644 convey any defect that cannot be represented explicitly with specific 645 Circuit Status flags from [RFC3931] or [L2TP-Status]. 647 The forward and reverse defect indication definitions used in this 648 document map to the L2TP Circuit Status AVP as follows: 650 Forward defect indication - corresponds to the logical OR of 652 Local Attachment Circuit (ingress) Receive Fault, 654 Local PSN-facing PW (egress) Transmit Fault, and 656 PW not Forwarding Fault 658 Reverse defect indication- corresponds to the logical OR of 660 Local Attachment Circuit (egress) Transmit Fault and 662 Local PSN-facing PW (ingress) Receive Fault 664 The status notification conveys the defect view of the originating 665 LCCE (PE). 667 When the extended Circuit Status definition of [L2TP-Status] is 668 supported, a PE SHALL use the Circuit Status to report all failures 669 affecting the PW service including, but not restricted, to the 670 following: 672 - Failures detected through defect detection mechanisms in 673 the L2TP-IP PSN. 675 - Failures detected through VCCV-Ping or VCCV-BFD CV types 676 0x04 and 0x10 for fault detection only 678 - Failures within the PE that result in an inability to 679 forward traffic between the AC and the PW 681 - Failures of the AC or in the L2 network affecting the AC 682 as per the rules detailed in Section 7. for the "single 683 emulated OAM loop" mode and the "coupled OAM loops" mode. 685 When the extended Circuit Status definition of [L2TP-Status] is not 686 supported, a PE SHALL use the A-bit in the Circuit Status AVP in SLI 687 to report: 689 - Failures of the AC or in the L2 network affecting the AC 690 as per the rules detailed in Section 7. for the "single 691 emulated OAM loop" mode and the "coupled OAM loops" mode. 693 When the extended Circuit Status definition of [L2TP-Status] is not 694 supported, a PE MAY use the CDN and StopCCN messages in a similar way 695 to an MPLS PW label withdrawal to report: 697 - Failures detected through defect detection mechanisms in 698 the L2TP-IP PSN (using StopCCN) 700 - Failures detected through VCCV (pseudowire level) (using 701 CDN) 703 - Failures within the PE that result in an inability to 704 forward traffic between ACs and PW (using CDN) 706 For ATM L2TPv3 pseudowires, in addition to the Circuit Status AVP, a 707 PE MAY use the ATM Alarm Status AVP [RFC4454] to indicate the reason 708 for the ATM circuit status and the specific alarm type, if any. This 709 AVP is sent in the SLI message to indicate additional information 710 about the ATM circuit status. 712 L2TP control connections use Hello messages as a keep-alive facility. 713 It is important to note that if a PSN failure is such that the loss 714 of connectivity is detected when it triggers a keep-alive timeouts, 715 the control connection is cleared. L2TP Hello messages are sent in- 716 band with the data plane, with respect to the source and destination 717 addresses, IP protocol number and UDP port (when UDP is used). 719 8.1.3. BFD Diagnostic Codes 721 [BFD] defines a set of diagnostic codes that partially overlap with 722 failures that can be communicated through LDP Status TLV or L2TP 723 Circuit Status AVP. This section describes the behavior of the PE 724 nodes with respect to using one or both methods for detecting and 725 propagating defect state. 727 For a MPLS-PSN, the PEs negotiate the use of the VCCV capabilities 728 when the label mapping messages are exchanged to establish the two 729 directions of the PW. An OAM capability TLV is signaled as part of 730 the PW FEC interface parameters TLV. For L2TP-IP PSNs, the PEs 731 negotiate the use of VCCV during the pseudowire session 732 initialization using the VCCV AVP [RFC5085]. 734 The CV Type Indicators field in this TLV defines a bitmask used to 735 indicate the specific OAM capabilities that the PE can make use of 736 over the PW being established. 738 A CV type of 0x04 or 0x10 indicates that BFD is used for PW fault 739 detection only [VCCV-BFD]. These CV types MAY be used any time the PW 740 is established using LDP or L2TP control planes. 742 In this mode, only the following diagnostic (Diag) codes specified in 743 [BFD] will be used, they are: 745 0 - No diagnostic 747 1 - Control detection time expired 749 7 - Administratively Down 751 A PE MUST use code 0 to indicate to its peer PE that is correctly 752 receiving BFD control messages. It MUST use the second code to 753 indicate that to its peer it has stopped receiving BFD control 754 messages. A PE shall use "Administrative down" to bring down the BFD 755 session when the PW is brought down administratively. All other 756 defects, such as AC/PW defects and PE internal failures that prevent 757 it from forwarding traffic, MUST be communicated through LDP Status 758 TLV in the case of MPLS PSN or MPLS-IP PSN, or through the 759 appropriate L2TP codes in the Circuit Status AVP in the case of L2TP- 760 IP PSN. 762 A CV type of 0x08 or 0x20 in the OAM capabilities TLV indicates that 763 BFD is used for both PW fault detection and Fault Notification. In 764 addition to the above diagnostic codes, a PE used the following codes 765 to signal AC defects and other defects impacting forwarding over the 766 PW service: 768 6 -- Concatenated Path Down 770 8 -- Reverse Concatenated Path Down 771 TBD -- PW not forwarding 773 A PE MAY use the "PW not forwarding" code to convey any other defect 774 that cannot be represented by code points 6 and 8. In general, this 775 applies to a defect that does not cause the PW to be torn down. This 776 implies the BFD session must not be brought down when this defect 777 exists. 779 The forward and reverse defect indication definitions used in this 780 document map to the BFD codes as follows: 782 Forward defect indication - corresponds to the logical OR of 784 Concatenated Path Down and PW not forwarding 786 Reverse defect indication- corresponds to Reverse 788 Concatenated Path Down 790 These diagnostic codes are used to signal receive and reverse defect 791 states respectively when the PEs negotiated the use of BFD as the 792 mechanism for AC and PW fault detection and status signaling 793 notification. As stated in Section 8.1. , these CV types SHOULD NOT 794 be used when the PW is established with the LDP or L2TP control 795 plane. 797 8.2. PW Defect State Entry/Exit 799 8.2.1. PW receive defect state entry/exit criteria 801 PE1 will enter the PW receive defect state if one or more of the 802 following occurs: 804 - It receives a forward defect indication from PE2, which 805 indicates PE2 detected or was notified of a PW fault 806 downstream of it or that there was a receive defect on 807 remote AC. 809 - It detects loss of connectivity on the PSN tunnel 810 upstream of PE1 which affects the traffic it receives 811 from PE2. 813 - It detects a loss of PW connectivity through VCCV-BFD or 814 VCCV-PING which affects the traffic it receives from PE2. 816 Note that if the PW control session between the PEs fails, the PW is 817 torn down and needs to be re-established. This includes failure of 818 the T-LDP session, the L2TP session, or the L2TP control connection. 819 However, the consequent actions towards the ACs are the same as if 820 the PW entered the receive defect state. 822 PE1 will exit the PW receive defect state when the following 823 conditions are true. Note that this may result in a transition to the 824 PW operational state or the PW transmit defect state. 826 - All defects it had previously detected have disappeared, 827 and 829 - PE2 cleared the forward defect indication if applicable. 831 8.2.2. PW transmit defect state entry/exit criteria 833 PE1 will enter the PW transmit defect state if the following 834 conditions are true: 836 - it receives a reverse defect indication from PE2 which 837 indicates that PE2 detected or was notified of a PW fault 838 upstream of it or that there was a transmit fault on the 839 remote AC, and 841 - it is not already in the PW receive defect state. 843 PE1 will exit the transmit defect state if it receives an OAM message 844 from PE2 clearing the reverse defect indication, or it has entered 845 the PW receive defect state. 847 For a PWE3 over a L2TP-IP PSN using the basic Circuit Status AVP 848 [RFC3931], the PW transmit defect state is not valid and a PE can 849 only enter the PW receive defect state. 851 9. Procedures for ATM PW Service 853 9.1. AC receive defect state entry/exit criteria 855 When operating in the "coupled OAM loops" mode, PE1 enters the AC 856 receive defect state if any of the following conditions are met: 858 a. It detects or is notified of a physical layer fault on 859 the ATM interface. 861 b. It receives an end-to-end F4 AIS OAM flow on a VP AC, 862 or an end-to-end F5 AIS OAM flow on a VC AC, 863 indicating that the ATM VPC or VCC is down in the 864 adjacent L2 ATM network. 866 c. It receives a segment F4 AIS OAM flow on a VP AC, or a 867 segment F5 AIS OAM flow on a VC AC, provided that the 868 operator has provisioned segment OAM and the PE is not 869 a segment end-point 871 d. It detects loss of connectivity on the ATM VPC/VCC 872 while terminating segment or end-to-end ATM continuity 873 check (ATM CC) cells with the local ATM network and 874 CE. 876 When operating in the "coupled OAM loops" mode, PE1 exits the AC 877 Receive defect state when all defects it had previously detected have 878 disappeared. 880 When operating in the "single emulated OAM loop" mode, PE1 enters the 881 AC receive defect state if any of the following conditions are met: 883 a. It detects or is notified of a physical layer fault on 884 the ATM interface. 886 b. It detects loss of connectivity on the ATM VPC/VCC 887 while terminating segment ATM continuity check (ATM 888 CC) cells with the local ATM network and CE. 890 When operating in the "single emulated OAM loop" mode, PE1 exits the 891 AC receive defect state when all defects it had previously detected 892 have disappeared. 894 The exact conditions under which a PE enters and exits the AIS state, 895 or declares that connectivity is restored via ATM CC are defined in 896 Section 9.2 of ITU-T Recommendation I.610 [ITU-T I.610]. 898 9.2. AC transmit defect state entry/exit criteria 900 When operating in the coupled-loop mode, PE1 enters the AC transmit 901 defect state if any of the following conditions are met: 903 a. It terminates an end-to-end F4 RDI OAM flow, in the 904 case of a VPC, or an end-to-end F5 RDI OAM flow, in 905 the case of a VCC, indicating that the ATM VPC or VCC 906 is down in the adjacent L2 ATM. 908 b. It receives a segment F4 RDI OAM flow on a VP AC, or a 909 segment F5 RDI OAM flow on a VC AC, provided that the 910 operator has provisioned segment OAM and the PE is not 911 a segment end-point 913 PE1 exits the AC transmit defect state if the AC state transitions to 914 working or to the AC receive defect state. The exact conditions for 915 exiting the RDI state are described in Section 9.2 of ITU-T 916 Recommendation I.610 [ITU-T I.610]. 918 Note that the AC transmit defect state is not valid when operating in 919 the "single emulated OAM loop" mode as PE1 transparently forwards the 920 received RDI cells as user cells over the ATM PW to the remote CE. 922 9.3. Consequent Actions 924 In the reminder of this section, the text refers to AIS, RDI and CC 925 without specifying whether it is an F4 (VP-level) flow or an F5 (VC- 926 level) flow, or whether it is an end-to-end or a segment flow. 927 Precise ATM OAM procedures for each type of flow are specified in 928 Section 9.2 of ITU-T Recommendation I.610 [ITU-T I.610]. 930 9.3.1. PW receive defect state entry/exit 932 On entry to the PW receive defect state: 934 a. PE1 MUST commence AIS insertion into the corresponding 935 AC. 937 b. PE1 MUST cease generation of CC cells on the 938 corresponding AC, if applicable. 940 c. If the PW failure was detected by PE1 without 941 receiving a forward defect indication from PE2, PE1 942 MUST assume PE2 has no knowledge of the defect and 943 MUST notify PE2 in the form of a reverse defect 944 indication. 946 On exit from the PW receive defect state: 948 a. PE1 MUST cease AIS insertion into the corresponding 949 AC. 951 b. PE1 MUST resume any CC cell generation on the 952 corresponding AC, if applicable. 954 c. PE1 MUST clear the reverse defect indication to PE2 if 955 applicable. 957 9.3.2. PW transmit defect state entry/exit 959 On entry to the PW Transmit Defect State: 961 a. PE1 MUST commence RDI insertion into the corresponding 962 AC. 964 b. If the PW failure was detected by PE1 without 965 receiving a reverse defect indication from PE2, PE1 966 MUST assume PE2 has no knowledge of the defect and 967 MUST notify PE2 in the form of a forward defect 968 indication. 970 On exit from the PW Transmit Defect State: 972 a. PE1 MUST cease RDI insertion into the corresponding 973 AC. 975 b. PE1 MUST clear the forward defect indication to PE2 if 976 applicable. 978 9.3.3. PW defect state in ATM Port Mode PW Service 980 In case of transparent cell transport PW service, i.e., "port mode", 981 where the PE does not keep track of the status of individual ATM VPCs 982 or VCCs, a PE cannot relay PW defect state over these VCCs and VPCs. 983 If ATM CC is run on the VCCs and VPCs end-to-end (CE1 to CE2), or on 984 a segment originating and terminating in the ATM network and spanning 985 the PSN network, it will timeout and cause the CE or ATM switch to 986 enter the ATM AIS state. 988 9.3.4. AC receive defect state entry/exit 990 On entry to the AC receive defect state and when operating in the 991 "coupled OAM loops" mode: 993 a. PE1 MUST send a forward defect indication to PE2. 995 b. PE1 MUST commence insertion of ATM RDI cells into the 996 AC towards CE1. 998 When operating in the "single emulated OAM loop" mode, PE1 must be 999 able to support two options, subject to the operator's preference. 1000 The default option is the following: 1002 On entry to the AC receive defect state: 1004 a. PE1 MUST transparently relay ATM AIS cells, or, in the 1005 case of a local AC defect, commence insertion of ATM 1006 AIS cells into the corresponding PW towards CE2. 1008 b. If the defect interferes with NS OAM message 1009 generation, PE1 MUST send a forward defect indication 1010 to PE2. 1012 c. PE1 MUST cease the generation of CC cells on the 1013 corresponding PW, if applicable. 1015 In certain operational models, for example in the case that the ATM 1016 access network is owned by a different provider than the PW, an 1017 operator may want to distinguish between defects detected in the ATM 1018 access network and defects detected on the AC directly adjacent to 1019 the PE. Therefore, the following option must also be supported: 1021 a. PE1 MUST transparently relay ATM AIS cells over the 1022 corresponding PW towards CE2. 1024 b. Upon detection of a defect on the ATM interface on the 1025 PE or in the PE itself, PE1 MUST send a forward defect 1026 indication to PE2. 1028 c. PE1 MUST cease generation of CC cells on the 1029 corresponding PW, if applicable. 1031 On exit from the AC receive defect state and when operating in the 1032 "coupled OAM loops" mode: 1034 a. PE1 MUST clear the forward defect indication to PE2. 1036 b. PE1 MUST cease insertion of ATM RDI cells into the AC. 1038 On exit from the AC receive defect state and when operating in the 1039 "single emulated OAM loop" mode: 1041 a. PE1 MUST cease insertion of ATM AIS cells into the 1042 corresponding PW. 1044 b. PE1 MUST clear the forward defect indication to PE2 if 1045 applicable. 1047 c. PE1 MUST resume any CC cell generation on the 1048 corresponding PW, if applicable. 1050 9.3.5. AC transmit defect state entry/exit 1052 On entry to the AC transmit defect state and when operating in the 1053 "coupled OAM loops" mode: 1055 a. PE1 MUST send a reverse defect indication to PE2. 1057 On exit from the AC transmit defect state and when operating in the 1058 "coupled OAM loops" mode: 1060 a. PE1 MUST clear the reverse defect indication to PE2. 1062 10. Procedures for Frame Relay PW Service 1064 10.1. AC receive defect state entry/exit criteria 1066 PE1 enters the AC receive defect state if one or more of the 1067 following conditions are true: 1069 a. A PVC is not deleted from the Frame Relay network and 1070 the Frame Relay network explicitly indicates in a full 1071 status report (and optionally by the asynchronous 1072 status message) that this Frame Relay PVC is inactive 1073 [ITU-T Q.933]. In this case, this status maps across 1074 the PE to the corresponding PW only. 1076 b. The Link Integrity Verification (LIV) indicates that 1077 the link from the PE to the Frame Relay network is 1078 down [ITU-T Q.933]. In this case, the link down 1079 indication maps across the PE to all corresponding 1080 PWs. 1082 c. A physical layer alarm is detected on the FR 1083 interface. In this case, this status maps across the 1084 PE to all corresponding PWs. 1086 PE1 exits the AC receive defect state when all defects it had 1087 previously detected have disappeared. 1089 10.2. AC transmit defect state entry/exit criteria 1091 The AC transmit defect state is not valid for a FR AC. 1093 10.3. Consequent Actions 1095 10.3.1. PW receive defect state entry/exit 1097 On entry to the PW receive defect state: 1099 a. PE1 MUST set the Active bit = 0 for the corresponding 1100 FR AC in a full status report, and optionally in an 1101 asynchronous status message, as per Q.933 annex A 1102 [ITU-T Q.933]. 1104 b. If the PW failure was detected by PE1 without 1105 receiving a forward defect indication from PE2, PE1 1106 MUST assume PE2 has no knowledge of the defect and 1107 MUST notify PE2 in the form of a reverse defect 1108 indication. 1110 On exit from the PW receive defect state: 1112 a. PE1 MUST set the Active bit = 1 for the corresponding 1113 FR AC in a full status report, and optionally in an 1114 asynchronous status message, as per Q.933 annex A. PE1 1115 does not apply this procedure on a transition from the 1116 PW receive defect state to the PW transmit defect 1117 state. 1119 b. PE1 MUST clear the reverse defect indication to PE2 if 1120 applicable. 1122 10.3.2. PW transmit defect state entry/exit 1124 On entry to the PW transmit defect state: 1126 a. PE1 MUST set the Active bit = 0 for the corresponding 1127 FR AC in a full status report, and optionally in an 1128 asynchronous status message, as per Q.933 annex A. 1130 b. If the PW failure was detected by PE1 without 1131 receiving a reverse defect indication from PE2, PE1 1132 MUST assume PE2 has no knowledge of the defect and 1133 MUST notify PE2 in the form of a forward defect 1134 indication. 1136 On exit from the PW transmit defect state: 1138 a. PE1 MUST set the Active bit = 1 for the corresponding 1139 FR AC in a full status report, and optionally in an 1140 asynchronous status message, as per Q.933 annex A. PE1 1141 does not apply this procedure on a transition from the 1142 PW transmit defect state to the PW receive defect 1143 state. 1145 b. PE1 MUST clear the forward defect indication to PE2 if 1146 applicable. 1148 10.3.3. PW defect state in the FR Port Mode PW service 1150 In case of port mode PW service, STATUS ENQUIRY and STATUS messages 1151 are transported transparently over the PW. A PW Failure will 1152 therefore result in timeouts of the Q.933 link and PVC management 1153 protocol at the Frame Relay devices at one or both sites of the 1154 emulated interface. 1156 10.3.4. AC receive defect state entry/exit 1158 On entry to the AC receive defect state: 1160 a. PE1 MUST send a forward defect indication to PE2. 1162 On exit from the AC receive defect state: 1164 a. PE1 MUST clear the forward defect indication to PE2. 1166 10.3.5. AC transmit defect state entry/exit 1168 The AC transmit defect state is not valid for a FR AC. 1170 11. Procedures for TDM PW Service 1172 The following procedures apply to SAToP ([RFC4553]), CESoPSN 1173 ([RFC5086]) and TDMoIP ([RFC5087]). These technologies generally 1174 utilize the single-emulated loop mode (see section 7). Note that 1175 TDMoIP distinguishes between trail-extended and trail-terminated 1176 scenarios; the former is essentially the single emulated loop model, 1177 while the latter differs from the coupled-loop model in that failure 1178 notifications are not propagated across the PW. 1180 Since TDM is inherently real-time in nature, many OAM indications 1181 must be generated or forwarded with essentially no delay. This 1182 requirement rules out the use of messaging protocols, such as relying 1183 on the PW status message. Thus, for TDM PWs, alternate mechanism are 1184 employed. 1186 The fact that TDM PW packets are sent at a known constant rate is 1187 used as an OAM mechanism. Thus, a PE enters the PW receive defect 1188 state when a preconfigured number of TDM PW packets do not arrive in 1189 a timely fashion. It exits this state when packets once again arrive 1190 at the proper rate. 1192 Native TDM carries OAM indications in overhead fields that travel 1193 along with the data. TDM PWs emulate this behavior by sending urgent 1194 OAM messages in the PWE control word. 1196 The TDM PWE control word contains a set of flags used to indicate PW 1197 and AC defect conditions. The L bit is an AC forward defect 1198 indication used by the local PE to signal TDM network defects to the 1199 remote PE. The M field may be used to modify the meaning of receive 1200 defects. The R bit is a PW reverse defect indication used by the 1201 local PE to signal PSN failures to the remote PE. Upon reception of 1202 packets with the R-bit set, a PE enters the PW transmit defect state. 1204 11.1. AC receive defect state entry/exit criteria 1206 PE1 enters the AC receive defect state if any of the following 1207 conditions are met: 1209 e. It detects a physical layer fault on the TDM interface 1210 (Loss of Signal, Loss of Alignment, etc (see G.705)). 1212 f. It is notified of a previous physical layer fault by 1213 detecting of AIS. 1215 The exact conditions under which a PE enters and exits the AIS state 1216 are defined in [ITU-T G.775]. Note that Loss of Signal and AIS 1217 detection can be performed for both structure-agnostic and structure- 1218 aware TDM PW types. Note that structure-agnostic PEs can not detect 1219 Loss of Alignment. 1221 11.2. AC transmit defect state entry/exit criteria 1223 PE1 enters the AC transmit defect state when it detects RDI according 1224 to the criteria in [ITU-T G.775]. Note that structure-agnostic PEs 1225 can not detect RDI. 1227 11.3. Consequent Actions 1229 11.3.1. PW receive defect state entry/exit 1231 On entry to the PW receive defect state: 1233 a. PE1 MUST commence AIS insertion into the corresponding 1234 TDM AC. 1236 b. PE1 MUST set the R bit in all PW packets sent back to 1237 PE2. 1239 On exit from the PW receive defect state: 1241 c. PE1 MUST cease AIS insertion into the corresponding 1242 TDM AC. 1244 d. PE1 MUST clear the R bit in all PW packets sent back 1245 to PE2. 1247 Note that AIS generation can in general be performed by both 1248 structure-aware and structure-agnostic PEs. 1250 11.3.2. PW transmit defect state entry/exit 1252 On entry to the PW Transmit Defect State: 1254 a. A structure-aware PE1 MUST commence RDI insertion into 1255 the corresponding AC. 1257 On exit from the PW Transmit Defect State: 1259 b. A structure-aware PE1 MUST cease RDI insertion into 1260 the corresponding AC. 1262 Note that structure-agnostic PEs are not capable of injecting RDI 1263 into an AC. 1265 11.3.3. AC receive defect state entry/exit 1267 On entry to the AC receive defect state and when operating in the 1268 "single emulated OAM loop" mode: 1270 a. PE1 SHOULD overwrite the TDM data with AIS in the PW 1271 packets sent towards PE2. 1273 b. PE1 MUST set the L bit in these packets. 1275 c. PE1 MAY omit the payload in order to conserve 1276 bandwidth. 1278 d. A structure-aware PE1 SHOULD send RDI back towards 1279 CE1. 1281 e. A structure-aware PE1 that detects a potentially 1282 correctable AC defect MAY use the M field to indicate 1283 this. 1285 On exit from the AC receive defect state and when operating in the 1286 "single emulated OAM loop" mode: 1288 a. PE1 MUST cease overwriting PW content with AIS and 1289 return to forwarding valid TDM data in PW packets sent 1290 towards PE2. 1292 b. PE1 MUST clear the notification bit in PW packets sent 1293 towards PE2. 1295 c. A structure-aware PE1 MUST cease sending RDI towards 1296 CE1. 1298 12. Procedures for CEP PW Service 1300 The following procedures apply to SONET/SDH Circuit Emulation 1301 ([RFC4842]). They are based on the single-emulated loop mode (see 1302 section 7). 1304 Since SONET and SDH are inherently real-time in nature, many OAM 1305 indications must be generated or forwarded with essentially no delay. 1306 This requirement rules out the use of messaging protocols, such as 1307 relying on the PW status message. Thus, for CEP PWs alternate 1308 mechanism are employed. 1310 The CEP PWE control word contains a set of flags used to indicate PW 1311 and AC defect conditions. The L bit is a forward defect indication 1312 used by the local PE to signal a defect in the attachment circuit to 1313 the remote PE. The R bit is a PW reverse defect indication used by 1314 the local PE to signal PSN failures to the remote PE. The combination 1315 of N and P bit is used by the local PE to signal loss of pointer to 1316 the remote PE. 1318 The fact that CEP PW packets are sent at a known constant rate is 1319 used as an OAM mechanism. Thus, a PE enters the PW receive defect 1320 state it loses packet synchronization. It exits this state when it 1321 regains packet synchronization. See [RFC4842] for further details. 1323 12.1. Defect states 1325 12.1.1. PW receive defect state entry/exit criteria 1327 In addition to the conditions specified in section 8.2.1. PE1 will 1328 enter the PW receive defect state if one of the following is true: 1330 - it receives packets with the L bit set 1332 - it receives packets with both the N and P bits set 1334 - it loses packet synchronization 1336 12.1.2. PW transmit defect state entry/exit criteria 1338 In addition to the conditions specified in section 8.2.2. PE1 will 1339 enter the PW transmit defect state if it receives packets with the R 1340 bit set. 1342 12.1.3. AC receive defect state entry/exit criteria 1344 PE1 enters the AC receive defect state if any of the following 1345 conditions are met: 1347 a. It detects a physical layer fault on the TDM interface 1348 (Loss of Signal, Loss of Alignment, etc (see 1349 [appropriate SONET & SDH reference])). 1351 b. It is notified of a previous physical layer fault by 1352 detecting of AIS. 1354 The exact conditions under which a PE enters and exits the AIS state 1355 are defined in[ITU-T G.707] and [ITU-T G.806]. 1357 12.1.4. AC transmit defect state entry/exit criteria 1359 The AC transmit defect state is not valid for CEP PWs. RDI signals 1360 are forwarded transparently. 1362 12.2. Consequent actions 1364 12.2.1. PW receive defect state entry/exit 1366 On entry to the PW receive defect state: 1368 a. PE1 MUST commence AIS-P/V insertion into the 1369 corresponding AC. 1371 b. PE1 MUST set the R bit in all PW packets sent back to 1372 PE2. 1374 On exit from the PW receive defect state: 1376 a. PE1 MUST cease AIS-P/V insertion into the 1377 corresponding AC. 1379 b. PE1 MUST clear the R bit in all PW packets sent back 1380 to PE2. 1382 See [RFC4842] for further details. 1384 12.2.2. PW transmit defect state entry/exit 1386 On entry to the PW Transmit Defect State: 1388 a. A structure-aware PE1 MUST commence RDI insertion into 1389 the corresponding AC. 1391 On exit from the PW Transmit Defect State: 1393 a. A structure-aware PE1 MUST cease RDI insertion into 1394 the corresponding AC. 1396 12.2.3. AC receive defect state entry/exit 1398 On entry to the AC receive defect state: 1400 a. PE1 MUST set the L bit in these packets. 1402 b. If Dynamic Bandwidth Allocation (DBA) has been 1403 enabled, PE1 MAY omit the payload in order to conserve 1404 bandwidth. 1406 c. If Dynamic Bandwidth Allocation (DBA) is not enabled 1407 PE1 SHOULD insert AIS-V/P in the SDH/SONET client 1408 layer in the PW packets sent towards PE2. 1410 On exit from the AC receive defect state and when operating in the 1411 "single emulated OAM loop" mode: 1413 d. PE1 MUST cease overwriting PW content with AIS-P/V and 1414 return to forwarding valid data in PW packets sent 1415 towards PE2. 1417 e. PE1 MUST clear the L bit in PW packets sent towards 1418 PE2. 1420 See [RFC4842] for further details. 1422 13. Security Considerations 1424 The mapping messages described in this document do not change the 1425 security functions inherent in the actual messages. 1427 14. IANA Considerations 1429 There are none at this time. 1431 15. References 1433 15.1. Normative References 1435 [BFD] Katz, D., Ward, D., "Bidirectional Forwarding Detection", 1437 [FRF.19] Frame Relay Forum, "Frame Relay Operations, Administration, 1438 and Maintenance Implementation Agreement", March 2001 1440 [ICMP] Postel, J. "Internet Control Message Protocol" RFC 792 1442 [ITU-T G.707] Recommendation G.707 "Network Node Interface For The 1443 Synchronous Digital Hierarchy", December 2003 1445 [ITU-T G.775] Recommendation G.775 "Loss of Signal (LOS), Alarm 1446 Indication Signal(AIS) and Remote Defect Indication (RDI) defect 1447 detection and clearance criteria for PDH signals", October 1998 1449 [ITU-T G.806] Recommendation G.806 "Characteristics of transport 1450 equipment-Description methodology and generic functionality", 1451 February 2004. 1453 [ITU-T I.610] Recommendation I.610 "B-ISDN operation and maintenance 1454 principles and functions", February 1999 1456 [ITU-T I.620] Recommendation I.620 "Frame relay operation and 1457 maintenance principles and functions", October 1996 1459 [ITU-T Q.933] Recommendation Q.933 "ISDN Digital Subscriber 1460 Signalling System No. 1 (DSS1) Signalling specifications for 1461 frame mode switched and permanent virtual connection control and 1462 status monitoring" February 2003 1464 [RFC3931] Lau, J., et. al. "Layer Two Tunneling Protocol (Version 3", 1465 RFC 3931, March 2005 1467 [RFC4023] Worster. T., et al., "Encapsulating MPLS in IP or Generic 1468 Routing Encapsulation (GRE)", RFC 4023, March 2005 1470 [RFC4379] Kompella, K., et. al., "Detecting MPLS Data Plane 1471 Failures", RFC4379, February 2006 1473 [RFC4447] Martini, L., Rosen, E., Smith, T., "Pseudowire Setup and 1474 Maintenance using LDP", RFC4447, April 2006 1476 [RFC4842] Malis, A., et. al., "SONET/SDH Circuit Emulation over 1477 Packet (CEP)", RFC 4842, April 2007 1479 [RFC5085] Nadeau, T., et al., "Pseudo Wire Virtual Circuit Connection 1480 Verification (VCCV)", RFC 5085, December 2007 1482 [VCCV-BFD] Nadeau, T., Pignataro, C., "Bidirectional Forwarding 1483 Detection (BFD) for the Pseudowire Virtual Circuit Connectivity 1484 Verification (VCCV)", draft-ietf-pwe3-vccv-bfd-02, June 2008 1486 15.2. Informative References 1488 [CONGESTION] Rosen, E., Bryant, S., Davie, B., "PWE3 Congestion 1489 Control Framework", draft-ietf-pwe3-congestion-frmwk-01.txt, May 1490 2008 1492 [ETH-OAM-IWK] Mohan, D., et al., "MPLS and Ethernet OAM 1493 Interworking", draft-mohan-pwe3-mpls-eth-oam-iwk-01, July 2008 1495 [L2TP-Status] McGill, N. Pignataro, C., "L2TPv3 Extended Circuit 1496 Status Values", draft-nmcgill-l2tpext-circuit-status-extensions- 1497 01 (work in progress), June 2008. 1499 [RFC3916] Xiao, X., McPherson, D., Pate, P., "Requirements for 1500 Pseudo Wire Emulation Edge to-Edge (PWE3)", RFC 3916, September 1501 2004 1503 [RFC3985] Bryant, S., Pate, P., "PWE3 Architecture", RFC 3985, March 1504 2005 1506 [RFC4377] Nadeau, T. et.al., "OAM Requirements for MPLS Networks", 1507 RFC4377, February 2006 1509 [RFC4446] Martini, L., et al., "IANA Allocations for pseudo 1510 Wire Edge to Edge Emulation (PWE3)", RFC4446, 1511 April 2006 1513 [RFC4454] Singh, S., Townsley, M., and C. Pignataro, "Asynchronous 1514 Transfer Mode (ATM) over Layer 2 Tunneling Protocol 1515 Version 3 (L2TPv3)", RFC 4454, May 2006 1517 [RFC4553] A.Vainshtein, Y.(J) Stein, "Structure-Agnostic Time 1518 Division Multiplexing (TDM) over Packet (SAToP)", RFC 4553, June 1519 2006 1521 [RFC4717] Martini, L., et al., "Encapsulation Methods for Transport 1522 of ATM Cells/Frame Over IP and MPLS Networks", RFC4717, 1523 December 2006 1525 [RFC5086] A.Vainshtein et al., "Structure-Aware Time Division 1526 Multiplexed (TDM) Circuit Emulation Service over Packet Switched 1527 Network (CESoPSN)", RFC 5086, December 2007 1529 [RFC5087] Y.(J) Stein et al., "Time Division Multiplexing over IP 1530 (TDMoIP)", RFC 5087, December 2007 1532 16. Editor's Addresses 1534 Mustapha Aissaoui 1535 Alcatel-lucent 1536 600 March Rd 1537 Kanata, ON, Canada K2K 2E6 1538 Email: mustapha.aissaoui@alcatel-lucent.com 1540 Peter B. Busschbach 1541 Alcatel-Lucent 1542 67 Whippany Road 1543 Whippany, NJ, 07981 1544 Email: busschbach@alcatel-lucent.com 1546 David Allan 1547 Nortel Networks 1548 3500 Carling Ave., 1549 Ottawa, Ontario, CANADA 1550 Email: dallan@nortel.com 1552 Luca Martini 1553 Cisco Systems, Inc. 1554 9155 East Nichols Avenue, Suite 400 1555 Englewood, CO, 80112 1556 Email: lmartini@cisco.com 1558 Thomas D. Nadeau 1559 BT 1560 BT Centre 1561 81 Newgate Street 1562 London EC1A 7AJ 1563 United Kingdom 1564 EMail: tom.nadeau@bt.com 1566 Monique Morrow 1567 Cisco Systems, Inc. 1568 Glatt-com 1569 CH-8301 Glattzentrum 1570 Switzerland 1571 EMail: mmorrow@cisco.com 1573 Yaakov (Jonathan) Stein 1574 RAD Data Communications 1575 24 Raoul Wallenberg St., Bldg C 1576 Tel Aviv 69719 1577 ISRAEL 1578 EMail: yaakov_s@rad.com 1580 Informative Appendix A: Native Service Management 1582 - Frame Relay Management 1584 The management of Frame Relay Bearer Service (FRBS) connections can 1585 be accomplished through two distinct methodologies: 1587 a. Based on ITU-T Q.933 Annex A, Link Integrity Verification 1588 procedure, where STATUS and STATUS ENQUIRY signaling messages 1589 are sent using DLCI=0 over a given UNI and NNI physical link. 1590 [ITU-T Q.933] 1591 b. Based on FRBS LMI, and similar to ATM ILMI where LMI is 1592 common in private Frame Relay networks. 1594 In addition, ITU-T I.620 addresses Frame Relay loopback, but the 1595 deployment of this standard is relatively limited [ITU-T I.620]. 1597 It is possible to use either, or both, of the above options to 1598 manage Frame Relay interfaces. This document will refer exclusively 1599 to Q.933 messages. 1601 The status of any provisioned Frame Relay PVC may be updated 1602 through: 1604 a. STATUS messages in response to STATUS ENQUIRY messages, these 1605 are mandatory. 1607 b. Optional unsolicited STATUS updates independent of STATUS 1608 ENQUIRY (typically under the control of management system, 1609 these updates can be sent periodically (continuous 1610 monitoring) or only upon detection of specific defects based 1611 on configuration. 1613 In Frame Relay, a DLC is either up or down. There is no distinction 1614 between different directions. To achieve commonality with other 1615 technologies, down is represented as a receive defect. 1617 Frame relay connection management is not implemented over the PW 1618 using either of the techniques native to FR, therefore PW mechanisms 1619 are used to synchronize the view each PE has of the remote NS/AC. A 1620 PE will treat a remote NS/AC failure in the same way it would treat 1621 a PW or PSN failure; that is using AC facing FR connection 1622 management to notify the CE that FR is down. 1624 - ATM Management 1626 ATM management and OAM mechanisms are much more evolved than those 1627 of Frame Relay. There are five broad management-related categories, 1628 including fault management (FT), Performance management (PM), 1629 configuration management (CM), Accounting management (AC), and 1630 Security management (SM). ITU-T Recommendation I.610 describes the 1631 functions for the operation and maintenance of the physical layer 1632 and the ATM layer, that is, management at the bit and cell levels 1633 [ITU-T I.610]. Because of its scope, this document will concentrate 1634 on ATM fault management functions. Fault management functions 1635 include the following: 1637 a. Alarm indication signal (AIS) 1638 b. Remote Defect indication (RDI). 1639 c. Continuity Check (CC). 1640 d. Loopback (LB) 1642 Some of the basic ATM fault management functions are described as 1643 follows: Alarm indication signal (AIS) sends a message in the same 1644 direction as that of the signal, to the effect that an error has 1645 been detected. 1647 Remote defect indication (RDI) sends a message to the transmitting 1648 terminal that an error has been detected. RDI is also referred to as 1649 the far-end reporting failure. Alarms related to the physical layer 1650 are indicated using path AIS/RDI. Virtual path AIS/RDI and virtual 1651 channel AIS/RDI are also generated for the ATM layer. 1653 OAM cells (F4 and F5 cells) are used to instrument virtual paths and 1654 virtual channels respectively with regard to their performance and 1655 availability. OAM cells in the F4 and F5 flows are used for 1656 monitoring a segment of the network and end-to-end monitoring. OAM 1657 cells in F4 flows have the same VPI as that of the connection being 1658 monitored. OAM cells in F5 flows have the same VPI and VCI as that 1659 of the connection being monitored. The AIS and RDI messages of the 1660 F4 and F5 flows are sent to the other network nodes via the VPC or 1661 the VCC to which the message refers. The type of error and its 1662 location can be indicated in the OAM cells. Continuity check is 1663 another fault management function. To check whether a VCC that has 1664 been idle for a period of time is still functioning, the network 1665 elements can send continuity-check cells along that VCC. 1667 Informative Appendix B: PW Defects and Detection tools 1669 - PW Defects 1671 Possible defects that impact PWs are the following: 1673 a. Physical layer defect in the PSN interface 1675 b. PSN tunnel failure which results in a loss of connectivity 1676 between ingress and egress PE. 1678 c. Control session failures between ingress and egress PE 1680 In case of an MPLS PSN and an MPLS-IP PSN there are additional 1681 defects: 1683 a. PW labeling error, which is due to a defect in the ingress 1684 PE, or to an over-writing of the PW label value somewhere 1685 along the LSP path. 1687 b. LSP tunnel Label swapping errors or LSP tunnel label merging 1688 errors in the MPLS network. This could result in the 1689 termination of a PW at the wrong egress PE. 1691 c. Unintended self-replication; e.g., due to loops or denial- 1692 of-service attacks. 1694 - Packet Loss 1696 Persistent congestion in the PSN or in a PE could impact the proper 1697 operation of the emulated service. 1699 A PE can detect packet loss resulting from congestion through several 1700 methods. If a PE uses the sequence number field in the PWE3 Control 1701 Word for a specific Pseudo Wire [RFC3985], it has the ability to 1702 detect packet loss. Translation of congestion detection to PW defect 1703 states is outside the scope of this specification. 1705 Generally, there are congestion alarms which are raised in the node 1706 and to the management system when congestion occurs. The decision to 1707 declare the PW Down and to select another path is usually at the 1708 discretion of the network operator. 1710 - PW Defect Detection Tools 1712 To detect the defects listed above, Service Providers have a variety 1713 of options available. 1715 Physical Layer defect detection and notification mechanisms such as 1716 SONET/SDH LOS, LOF, and AIS/FERF. 1718 PSN Defect Detection Mechanisms: 1720 For PWE3 over an L2TP-IP PSN, with L2TP as encapsulation protocol, 1721 the defect detection mechanisms described in [RFC3931] apply. This 1722 includes for example the keep-alive mechanism performed with Hello 1723 messages for detection of loss of connectivity between a pair of 1724 LCCEs (i.e., dead PE peer and path detection). Furthermore, the 1725 tools Ping and Traceroute, based on ICMP Echo Messages apply [RFC792] 1726 and can be used to detect defects on the IP PSN. Additionally, ICMP 1727 Ping [RFC5085] and BFD [VCCV-BFD] can also be used with VCCV to 1728 detect defects at the individual pseudowire level. 1730 For PWE3 over an MPLS PSN and an MPLS-IP PSN, several tools can be 1731 used. 1733 a. LSP-Ping and LSP-Traceroute( [RFC4379]) for LSP tunnel 1734 connectivity verification. 1736 b. LSP-Ping with Bi-directional Forwarding Detection ([BFD]) 1737 for LSP tunnel continuity checking. 1739 c. Furthermore, if RSVP-TE is used to setup the PSN Tunnels 1740 between ingress and egress PE, the hello protocol can be 1741 used to detect loss of connectivity [RFC3209], but only at 1742 the control plane. 1744 PW specific defect detection mechanisms: 1746 [RFC4377] describes how LSP-Ping and BFD can be used over individual 1747 PWs for connectivity verification and continuity checking 1748 respectively. When used as such, we will refer to them as VCCV-Ping 1749 and VCCV-BFD respectively. 1751 Furthermore, the detection of a fault could occur at different points 1752 in the network and there are several ways the observing PE determines 1753 a fault exists: 1755 a. egress PE detection of failure (e.g. BFD) 1757 b. ingress PE detection of failure (e.g. LSP-PING) 1759 c. ingress PE notification of failure (e.g. RSVP Path-err)