idnits 2.17.1 draft-ietf-pwe3-oam-msg-map-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 27. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1517. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1528. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1535. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1541. 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 Copyright Line does not match the current year == Line 155 has weird spacing: '...the 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 (November 3, 2008) is 5653 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 1338, but not defined == Missing Reference: 'RFC3209' is mentioned on line 1354, but not defined == Unused Reference: 'ICMP' is defined on line 1392, but no explicit reference was found in the text == Unused Reference: 'CONGESTION' is defined on line 1426, but no explicit reference was found in the text == Unused Reference: 'RFC4717' is defined on line 1455, but no explicit reference was found in the text == Unused Reference: 'RFC4842' is defined on line 1459, 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 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 (~~), 11 warnings (==), 11 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: May 2009 Alcatel-Lucent 5 Dave Allan 6 Nortel 8 Monique Morrow 9 Luca Martini 10 Cisco Systems Inc. 12 Thomas Nadeau 13 BT 15 Editors 17 November 3, 2008 19 Pseudo Wire (PW) OAM Message Mapping 20 draft-ietf-pwe3-oam-msg-map-08.txt 22 Status of this Memo 24 By submitting this Internet-Draft, each author represents that any 25 applicable patent or other IPR claims of which he or she is aware 26 have been or will be disclosed, and any of which he or she becomes 27 aware will be disclosed, in accordance with Section 6 of BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that other 31 groups may also distribute working documents as Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on May 3, 2009. 46 Abstract 47 This document specifies the mapping of defect states between a Pseudo 48 Wire and the Attachment Circuits (AC) of the end-to-end emulated 49 service. This document covers the case whereby the ACs and the PWs 50 are of the same type in accordance to the PWE3 architecture [RFC3985] 51 such that a homogenous PW service can be constructed. 53 Conventions used in this document 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in RFC-2119. 59 Table of Contents 61 1. Acknowledgments................................................3 62 2. Contributors...................................................3 63 3. Introduction...................................................4 64 4. Terminology....................................................4 65 5. Reference Model and Defect Locations...........................7 66 6. Abstract Defect States.........................................8 67 7. OAM Models.....................................................9 68 8. PW Defect States and Defect Notifications.....................11 69 8.1. PW Defect Notification Mechanisms........................11 70 8.1.1. LDP Status TLV......................................12 71 8.1.2. L2TP Circuit Status AVP.............................14 72 8.1.3. BFD Diagnostic Codes................................16 73 8.2. PW Defect State Entry/Exit...............................17 74 8.2.1. PW Forward Defect State Entry/Exit Criteria.........17 75 8.2.2. PW Reverse Defect State Entry/Exit Criteria.........18 76 9. Procedures for ATM PW Service.................................19 77 9.1. AC forward defect state entry/exit criteria..............19 78 9.2. AC reverse defect state entry/exit criteria..............20 79 9.3. Consequent Actions.......................................20 80 9.3.1. PW forward defect state entry/exit..................20 81 9.3.2. PW reverse defect state entry/exit..................21 82 9.3.3. PW defect state in ATM Port Mode PW Service.........21 83 9.3.4. AC forward defect state entry/exit..................21 84 9.3.5. AC reverse defect state entry/exit..................22 85 10. Procedures for Frame Relay PW Service........................23 86 10.1. AC forward defect state entry/exit criteria.............23 87 10.2. AC reverse defect state entry/exit criteria.............23 88 10.3. Consequent Actions......................................23 89 10.3.1. PW forward defect state entry/exit.................23 90 10.3.2. PW reverse defect state entry/exit.................24 91 10.3.3. PW defect state in the FR Port Mode PW service.....24 92 10.3.4. AC forward defect state entry/exit.................25 93 10.3.5. AC reverse defect state entry/exit.................25 94 11. Procedures for TDM PW Service................................25 95 12. Procedures for CEP PW Service................................26 96 13. Informative Appendix A: Native Service Management............26 97 13.1. Frame Relay Management..................................26 98 13.2. ATM Management..........................................27 99 14. Informative Appendix B: PW Defects and Detection tools.......28 100 14.1. PW Defects..............................................28 101 14.1.1. Packet Loss........................................29 102 14.2. PW Defect Detection Tools...............................29 103 15. Security Considerations......................................30 104 16. IANA Considerations..........................................30 105 17. References...................................................30 106 17.1. Normative References....................................30 107 17.2. Informative References..................................31 108 18. Editor's Addresses...........................................32 109 Full Copyright Statement.........................................33 110 Intellectual Property Statement..................................34 111 Acknowledgment...................................................34 113 1. Acknowledgments 115 The editors would like to acknowledge the important contributions of 116 Hari Rakotoranto, Eric Rosen, Mark Townsley, Michel Khouderchah, 117 Bertrand Duvivier, Vanson Lim, Chris Metz, Ben Washam, Tiberiu 118 Grigoriu, Neil McGill, and Amir Maleki. 120 2. Contributors 122 Thomas D. Nadeau, tom.nadeau@bt.com 124 Monique Morrow, mmorrow@cisco.com 126 Peter B. Busschbach, busschbach@alcatel-lucent.com 128 Mustapha Aissaoui, mustapha.aissaoui@alcatel-lucent.com 130 Matthew Bocci, matthew.bocci@alcatel-lucent.co.uk 132 David Watkinson, david.watkinson@alcatel-lucent.com 134 Yuichi Ikejiri, y.ikejiri@ntt.com 136 Kenji Kumaki, kekumaki@kddi.com 137 Satoru Matsushima, satoru@ft.solteria.net 139 David Allan, dallan@nortel.com 141 Himanshu Shah, hshah@ciena.com 143 Simon Delord, simon.delord@gmail.com 145 Vasile Radoaca, vasile.radoaca@alcatel-lucent.com 147 Carlos Pignataro, cpignata@cisco.com 149 Luca Martini, lmartini@cisco.com 151 3. Introduction 153 This document specifies the mapping of defect states between a Pseudo 154 Wire and the Attachment Circuits (AC) of the end-to-end emulated 155 service. It covers the case whereby the ACs and the PWs are of the 156 same type in accordance to the PWE3 architecture [RFC3985] such 157 that a homogeneous PW service can be constructed. 159 This document is motivated by the requirements put forth in [RFC4377] 160 and [RFC3916]. Its objective is to standardize the behavior of PEs 161 with respects to failures on PWs and ACs, so that there is no 162 ambiguity about the alarms generated and consequent actions 163 undertaken by PEs in response to specific failure conditions. 165 This document covers PWE over MPLS PSN, PWE over IP PSN and PWE over 166 L2TP PSN. 168 The Ethernet PW service is covered in a separate document [ETH-OAM- 169 IWK]. 171 4. Terminology 173 AIS Alarm Indication Signal 175 AC Attachment circuit 177 BDI Backward Defect Indication 179 CC Continuity Check 181 CE Customer Edge 183 CPCS Common Part Convergence Sub-layer 184 DLC Data Link Connection 186 FDI Forward Defect Indication 188 FRBS Frame Relay Bearer Service 190 IWF Interworking Function 192 LB Loopback 194 NE Network Element 196 NS Native Service 198 OAM Operations and Maintenance 200 PE Provider Edge 202 PW Pseudowire 204 PSN Packet Switched Network 206 RDI Remote Defect Indication 208 SDU Service Data Unit 210 VCC Virtual Channel Connection 212 VPC Virtual Path Connection 214 The rest of this document will follow the following conventions. 216 The words "defect" and "fault" are used inter-changeably to mean a 217 condition which causes user packets not to be forwarded between the 218 CE endpoints of the PW service. 220 The words "defect notification" and "defect indication" are used 221 inter-changeably to mean an OAM message generated by a PE and sent to 222 other nodes in the network to convey the defect state local to this 223 PE. 225 The PW can ride over three types of Packet Switched Network (PSN). A 226 PSN which makes use of LSPs as the tunneling technology to forward 227 the PW packets will be referred to as an MPLS PSN. A PSN which makes 228 use of MPLS-in-IP tunneling [RFC4023], with an MPLS shim header used 229 as PW demultiplexer, will be referred to as an MPLS-IP PSN. A PSN 230 which makes use of L2TPv3 [RFC3931] as the tunneling technology with 231 the L2TPv3 Session ID as the PW demultiplexer will be referred to as 232 L2TP-IP PSN. 234 If LSP-Ping [RFC4379] is run over a PW as described in [RFC4377], it 235 will be referred to as VCCV-Ping. 237 If BFD is run over a PW as described in [RFC4377], it will be 238 referred to as VCCV-BFD [VCCV-BFD]. 240 In the context of this document a PE forwards packets between an AC 241 and a PW. The other PE that terminates the PW is the peer PE or 242 remote PE and the attachment circuit associated with the far-end PW 243 termination is the remote AC. 245 Defects are discussed in the context of defect states, and the 246 criteria to enter and exit the defect state. The direction of defects 247 is discussed from the perspective of the observing PE. 249 A forward defect is one that impacts information transfer to the 250 observing PE. It impacts the observing PEs ability to receive 251 information. 253 A reverse defect is one that uniquely impacts information sent or 254 relayed by the observing PE. 256 A forward defect generally also impacts information sent or relayed 257 by the observing PE. Therefore the forward defect state is considered 258 to be a superset of the two defect states. Thus, when a PE enters 259 both forward and reverse defect states related to the same PW 260 service, the forward defect takes precedence over reverse defect in 261 terms of the consequent actions. 263 A forward defect indication is sent in the same direction as the user 264 traffic impacted by the defect. A reverse defect indication is sent 265 in the opposite direction of the traffic impacted by the defect. 267 When a PE enters a defect state, it always sends a defect indication 268 that corresponds to that defect to notify nodes which are downstream 269 of the defect. For example, a local PE sends a forward defect 270 indication downstream to the CE when it enters the PW forward defect 271 state. However, in some cases the PE enters this defect state without 272 receiving a defect indication from the peer PE. In this case, the 273 local PE will also send a defect indication to the remote PE to 274 synchronize the states. In the example above, the local PE will send 275 a reverse defect indication to the remote PE. The exact procedures 276 are described later in the document. 278 5. Reference Model and Defect Locations 280 Figure 1 illustrates the PWE3 network reference model with an 281 indication of the possible defect locations. This model will be 282 referenced in the remainder of this document for describing the OAM 283 procedures. 285 ACs PSN tunnel ACs 286 +----+ +----+ 287 +----+ | PE1|==================| PE2| +----+ 288 | |---(a)---(b)..(c)......PW1..(d)..(c)..(f)---(e)---| | 289 | CE1| (N1) | | | | (N2) |CE2 | 290 | |----------|............PW2.............|----------| | 291 +----+ | |==================| | +----+ 292 ^ +----+ +----+ ^ 293 | Provider Edge 1 Provider Edge 2 | 294 | | 295 |<-------------- Emulated Service ---------------->| 296 Customer Customer 297 Edge 1 Edge 2 298 Figure 1: PWE3 Network Defect Locations 300 In all interworking scenarios described in this document, it is 301 assumed the AC and the PW are of the same type at PE1. The procedures 302 described in this document apply to PE1. PE2 implements the identical 303 functionality for a homogeneous service (although it is not required 304 to as long as the notifications across the PWs are consistent). 306 The following is a brief description of the defect locations: 308 a. Defect in the first L2 network (N1). This covers any defect 309 in the N1 which impacts all or a subset of ACs terminating in 310 PE1. The defect is conveyed to PE1 and to the remote L2 311 network (N2) using the native service specific OAM defect 312 indication. 313 b. Defect on a PE1 AC interface. 314 c. Defect on a PE1 PSN interface. 315 d. Defect in the PSN network. This covers any defect in the PSN 316 which impacts all or a subset of PWs terminating in a PE. The 317 defect is conveyed to the PE using a PSN and/or a PW specific 318 OAM defect indication. Note that both data plane defects and 319 control plane defects must be taken into consideration. Even 320 though control messages may follow a different path than the 321 PW data plane traffic, a control plane failure may affect the 322 PW status. 323 e. Defect in the second L2 network (N2). This covers any defect 324 in N2 which impacts all or a subset of ACs terminating in PE2 325 (which is considered a remote AC defect in the context of 326 procedures outlined in this draft). The defect is conveyed to 327 PE2 and to the remote L2 network (N1) using the native 328 service OAM defect indication. 329 f. Defect on a PE2 AC interface (which is also considered a 330 remote AC defect in the context of this draft). 332 6. Abstract Defect States 334 PE1 must track four defect states that reflect the observed states of 335 both directions of the PW service on both the AC and the PW sides. 336 Defects may impact one or both directions of the PW service. 338 The observed state is a combination of defects directly detected by 339 PE1 and defects it has been made aware of via notifications. 341 +-----+ 342 ----AC forward---->| |-----PW reverse----> 343 CE1 | PE1 | PE2/CE2 344 <---AC reverse-----| |<----PW forward----- 345 +-----+ 347 (arrows indicate direction of user traffic impacted by a defect) 348 Figure 2: Forward and Reverse Defect States and Notifications 350 PE1 will directly detect or be notified of AC forward or PW forward 351 defects as they occur upstream of PE1 and impact traffic being sent 352 to PE1. As a result, PE1 enters the AC forward defect state. 354 In Figure 2, PE1 may be notified of a forward defect in the AC by 355 receiving a Forward Defect indication, e.g., ATM AIS, from an ATM 356 switch in L2 network N1. This defect notification indicates that user 357 traffic sent by CE1 may not be received by PE1 due to a defect. PE1 358 can also directly detect an AC Forward Defect if it resulted from a 359 failure of the receive side in the local port or link over which the 360 AC is configured. 362 Similarly, PE1 may detect or be notified of a forward defect in the 363 PW by receiving a Forward Defect indication from PE2. If PW status is 364 used for fault notification, this message will indicate a Local PSN- 365 facing PW (egress) Transmit Fault or a Local Attachment Circuit 366 (ingress) Receive Fault at PE2, as described in Section 8.1.1. . This 367 defect notification indicates that user traffic sent by CE2 may not 368 be received by PE1 due to a defect. As a result, PE1 enters the PW 369 forward defect state. 371 Note that a Forward Defect notification is sent in the same direction 372 as the user traffic impacted by the defect. 374 PE1 will only be notified of AC reverse or PW reverse defects as they 375 universally will be detected by other devices and only impact traffic 376 that has already been relayed by PE1. As a result, PE1 enters the AC 377 reverse defect state. 379 In Figure 2, PE1 may be notified of a reverse defect in the AC by 380 receiving a Reverse Defect indication, e.g., ATM RDI, from CE1. This 381 defect impacts the traffic sent by PE1 to CE1 on the AC. 383 Similarly, PE1 may be notified of a reverse defect in the PW by 384 receiving a Reverse Defect indication from PE2. If PW status is used 385 for fault notification, this message will indicate a Local PSN-facing 386 PW (ingress) Receive Fault or a Local Attachment Circuit (egress) 387 Transmit Fault at PE2, as described in Section 8.1.1. . This defect 388 impacts the traffic sent by PE1 to CE2. As a result, PE1 enters the 389 PW reverse defect state. 391 Note that a Reverse Defect notification is sent in the reverse 392 direction to the user traffic impacted by the defect. 394 The procedures outlined in this document define the entry and exit 395 criteria for each of the four states with respect to the set of PW 396 services within the document scope and the consequent actions that 397 PE1 must perform. 399 When a PE enters both forward and reverse defect states related to 400 the same PW service, then the forward defect takes precedence over 401 reverse defect in terms of the consequent actions. 403 7. OAM Models 405 A homogeneous PW service forwards packets between an AC and a PW of 406 the same type. It thus implements both a Native Service OAM 407 mechanism and a PW OAM mechanism. PW OAM defect notification 408 messages are described in Section 8.1. . NS OAM messages are 409 described in Appendix A. 411 This document defines two different modes for operating OAM on a PW 412 service which dictate the mapping between the NS OAM the PW OAM 413 defect notification messages. 415 The first one operates a single emulated OAM loop end-to-end between 416 the endpoints of the PW service. This is referred to as "single 417 emulated OAM loop" mode and is illustrated in Figure 3. 419 |<----- AC ----->|<----- PW ----->|<----- AC ----->| 420 | | | | 421 ___ ===============_ 422 |CE|---=NS-OAM=>---(---=NS-OAM=>---)---=NS-OAM=>---|CE| 423 =============== / 424 \ / 425 ---=PW-OAM=>--- 427 Figure 3: Single Emulated OAM Loop mode 429 This mode implements the following behavior: 430 a. A PE node MUST transparently relay NS OAM messages over the 431 PW. 432 b. A PE node MUST signal local failures affecting the AC using a 433 NS defect notification OAM message sent over the PW. 434 c. A PE MUST signal local failures affecting the AC using a PW 435 defect notification OAM message when the defect interferes 436 with NS OAM message generation, e.g., NS processing line card 437 removed. 438 d. A PE node MUST signal local failures affecting the PW using a 439 PW defect notification OAM message. 440 e. A PE node MUST insert a NS defect notification OAM message 441 into the AC when it detects or is notified of a defect in the 442 PW or remote AC. This includes support receiving a PW defect 443 notification message and translating it into a NS defect 444 notification OAM message over the AC. The latter is required 445 for handling defects signaled by a peer PE with PW OAM 446 messaging. 448 The "single emulated OAM loop" mode is suitable for PW services 449 which have a widely deployed NS OAM mechanism that operates within 450 the AC. This document specifies the use of this mode for ATM PW, TDM 451 PW, and CEP PW services. It is the default mode of operation for an 452 ATM PW service and the only mode specified for TDM and CEP PW 453 services. 455 The second mode operates three OAM loops which join at the AC/PW 456 boundary of a PE. This is referred to as "coupled OAM loops" mode 457 and is illustrated in Figure 4 458 |<----- AC ----->|<----- PW ----->|<----- AC ----->| 459 | | | | 460 __ ===============__ 461 |CE|---=NS-OAM=>---(---------------)---=NS-OAM=>---|CE| 462 \ =============== / 463 \ / 464 \ / 465 -------=PW-OAM=>------ 467 Figure 4: Coupled OAM Loops mode 469 This mode implements the following behavior: 470 a. A PE node MUST terminate and translate a received NS defect 471 notification OAM message to a PW defect notification message. 472 b. A PE node MUST signal local failures affecting the AC using 473 using a PW defect notification OAM message. 474 c. A PE node MUST signal local failures affecting the PW using a 475 PW defect notification OAM message. 476 d. A PE node MUST insert a NS defect notification OAM message 477 into the AC when it detects or is notified of a defect in the 478 PW or remote AC. This includes support receiving a PW defect 479 notification message and translating it into a NS defect 480 notification OAM message over the AC. 482 This document specifies the use of the "coupled OAM loops" mode for 483 a FR PW service and for ATM PW services of type ATM VCC and AAL5 484 SDU. It does not specify the use of this mode for TDM PW, CEP PW, 485 and the ATM VPC cell mode PW services. In the latter case, a PE node 486 must pass transparently VC-level (F5) ATM OAM cells over the PW 487 while terminating and translating VP-level (F4) OAM cells. Thus, it 488 cannot operate a pure "coupled OAM loops" mode. 490 8. PW Defect States and Defect Notifications 492 8.1. PW Defect Notification Mechanisms 494 For a MPLS PSN and a MPLS-IP PSN, a PE node which establishes a PW 495 using LDP SHALL use LDP status TLV as the mechanism for AC and PW 496 status and defect notification [RFC4447]. Additionally, a PE node MAY 497 use VCCV-BFD Connectivity Verification (CV) types for fault detection 498 only but SHOULD notify the remote PE using LDP Status TLV. These CV 499 types are 0x04 and 0x10 [VCCV-BFD]. 501 A PE node which establishes a PW using other means than LDP, e.g., 502 static configuration, MAY use VCCV-BFD CV types for AC and PW status 503 and defect notification. These CV types are 0x08 and 0x20 [VCCV-BFD]. 505 These CV types SHOULD NOT be used when the PW is established with the 506 LDP control plane. 508 For a L2TP-IP PSN, A PE node SHOULD use the Circuit Status AVP as the 509 mechanism for AC and PW status and defect notification. In its most 510 basic form, the Circuit Status AVP [RFC3931] in a Set-Link-Info (SLI) 511 message can signal active/inactive AC status. The Circuit Status AVP 512 is proposed to be extended to convey status and defects in the AC and 513 the PSN-facing PW in both ingress and egress directions, i.e., four 514 independent status bits without the need to tear down the sessions or 515 control connection [L2TP-Status]. 517 When a PE does not support the Circuit Status AVP, it MAY use the 518 StopCCN and the CDN message to bring down L2TP sessions in a similar 519 way LDP uses the Label Withdrawal to bring down a PW. A PE node may 520 use the StopCCN to shutdown the L2TP control connection, and 521 implicitly all L2TP sessions associated with that control connection 522 without any explicit session control messages. This is in the case of 523 a failure which impacts all L2TP sessions, i.e., all PWs, managed by 524 the control connection. It may use the CDN message to disconnect a 525 specific L2TP session when a failure affects a specific PW. 527 Additionally, a PE node MAY use VCCV-BFD CV types 0x04 and 0x10 for 528 fault detection only but SHOULD notify the remote PE using the 529 Circuit Status AVP. A PE node which establishes a PW using other 530 means than L2TP control plane MAY use VCCV-BFD CV types 0x08 and 0x20 531 for AC and PW status and defect notification. These CV types SHOULD 532 NOT be used when the PW is established with the L2TP control plane. 534 8.1.1. LDP Status TLV 536 [RFC4446] defines the following PW status code points: 538 0x00000000 - Pseudo Wire forwarding (clear all failures) 539 0x00000001 - Pseudo Wire Not Forwarding 540 0x00000002 - Local Attachment Circuit (ingress) Receive Fault 541 0x00000004 - Local Attachment Circuit (egress) Transmit Fault 542 0x00000008 - Local PSN-facing PW (ingress) Receive Fault 543 0x00000010 - Local PSN-facing PW (egress) Transmit Fault 545 [RFC4447] specifies that "Pseudo Wire forwarding" code point is used 546 to clear all faults. It also specifies that "Pseudo Wire Not 547 Forwarding" code is used to convey any other defect that cannot be 548 represented by the other code points. In general, this applies to a 549 defect that does not cause the PW to be torn down. 551 The code points used in the LDP status TLV in a PW status 552 notification message convey the defect view of the originating PE. 554 The originating PE conveys this state in the form of a forward defect 555 or a reverse defect indication. 557 The forward and reverse defect indication definitions used in this 558 document map to the LDP Status TLV codes as follows: 560 Forward defect indication - corresponds to the logical OR of 562 Local Attachment Circuit (ingress) 564 Receive Fault, Local PSN-facing 566 PW (egress) Transmit Fault, and PW not 568 Forwarding Fault 570 Reverse defect indication - corresponds to the logical OR of 572 Local Attachment Circuit (egress) 574 Transmit Fault and Local PSN-facing 576 PW (ingress) Receive Fault 578 A PE SHALL thus use PW status notification messages to report all 579 failures affecting the PW service including, but not restricted, to 580 the following: 582 - Failures detected through defect detection mechanisms in 583 the MPLS and MPLS-IP PSN 585 - Failures detected through VCCV-Ping or VCCV-BFD CV types 586 0x04 and 0x10 for fault detection only 588 - Failures within the PE that result in an inability to 589 forward traffic between the AC and the PW 591 - Failures of the AC or in the L2 network affecting the AC 592 as per the rules detailed in Section 7. for the "single 593 emulated OAM loop" mode and "coupled OAM loops" mode. 595 Note that there are a couple of situations which require PW label 596 withdrawal as opposed to a PW status notification by the PE. The 597 first one is when the PW is taken administratively down in accordance 598 to [RFC4447]. The second one is when the Target LDP session 599 established between the two PEs is lost. In the latter case, the PW 600 labels will need to be re-signaled when the Targeted LDP session is 601 re-established. 603 8.1.2. L2TP Circuit Status AVP 605 [RFC3931] defines the Circuit Status AVP in the Set-Link-Info (SLI) 606 message to exchange initial status and status changes in the circuit 607 to which the pseudowire is bound. [L2TP-Status] defines extensions to 608 the Circuit Status AVP that are analogous to the PW Status TLV 609 defined for LDP. Consequently, for L2TP-IP, the Circuit Status AVP 610 is used in the same fashion as the PW Status described in the 611 previous section. 613 If the extended Circuit Status bits are not supported, and instead 614 only the "A-bit" (Active) is used as described in [RFC3931], a PE MAY 615 use CDN messages to clear L2TPv3 sessions in the presence of session- 616 level failures detected in the L2TP-IP PSN. 618 A PE MUST set the Active bit in the Circuit Status to clear all 619 faults, and it MUST clear the Active bit in the Circuit Status to 620 convey any defect that cannot be represented explicitly with specific 621 Circuit Status flags from [RFC3931] or [L2TP-Status]. 623 The forward and reverse defect indication definitions used in this 624 document map to the L2TP Circuit Status AVP as follows: 626 Forward defect indication - corresponds to the logical OR of 628 Local Attachment Circuit (ingress) 630 Receive Fault and Local PSN-facing 632 PW (egress) Transmit Fault 634 Reverse defect indication- corresponds to the logical OR of 636 Local Attachment Circuit (egress) 638 Transmit Fault and Local PSN-facing 640 PW (ingress) Receive Fault 642 The status notification conveys the defect view of the originating 643 LCCE (PE). 645 When the extended Circuit Status definition of [L2TP-Status] is 646 supported, a PE SHALL use the Circuit Status to report all failures 647 affecting the PW service including, but not restricted, to the 648 following: 650 - Failures detected through defect detection mechanisms in 651 the L2TP-IP PSN. 653 - Failures detected through VCCV-Ping or VCCV-BFD CV types 654 0x04 and 0x10 for fault detection only 656 - Failures within the PE that result in an inability to 657 forward traffic between the AC and the PW 659 - Failures of the AC or in the L2 network affecting the AC 660 as per the rules detailed in Section 7. for the "single 661 emulated OAM loop" mode and the "coupled OAM loops" mode. 663 When the extended Circuit Status definition of [L2TP-Status] is not 664 supported, a PE SHALL use the A-bit in the Circuit Status AVP in SLI 665 to report: 667 - Failures of the AC or in the L2 network affecting the AC 668 as per the rules detailed in Section 7. for the "single 669 emulated OAM loop" mode and the "coupled OAM loops" mode. 671 When the extended Circuit Status definition of [L2TP-Status] is not 672 supported, a PE MAY use the CDN and StopCCN messages in a similar way 673 to an MPLS PW label withdrawal to report: 675 - Failures detected through defect detection mechanisms in 676 the L2TP-IP PSN (using StopCCN) 678 - Failures detected through VCCV (pseudowire level) (using 679 CDN) 681 - Failures within the PE that result in an inability to 682 forward traffic between ACs and PW (using CDN) 684 For ATM L2TPv3 pseudowires, in addition to the Circuit Status AVP, a 685 PE MAY use the ATM Alarm Status AVP [RFC4454] to indicate the reason 686 for the ATM circuit status and the specific alarm type, if any. This 687 AVP is sent in the SLI message to indicate additional information 688 about the ATM circuit status. 690 L2TP control connections use Hello messages as a keepalive facility. 691 It is important to note that if a PSN failure is such that the loss 692 of conectivity is detected when it triggers a keepalive timeouts, the 693 control connection is cleared. L2TP Hello messages are sent in-band 694 with the dataplane, with respect to the source and destination 695 addresses, IP protocol number and UDP port (when UDP is used). 697 8.1.3. BFD Diagnostic Codes 699 [BFD] defines a set of diagnostic codes that partially overlap with 700 failures that can be communicated through LDP Status TLV or L2TP 701 Circuit Status AVP. This section describes the behavior of the PE 702 nodes with respect to using one or both methods for detecting and 703 propagating defect state. 705 For a MPLS-PSN, the PEs negotiate the use of the VCCV capabilities 706 when the label mapping messages are exchanged to establish the two 707 directions of the PW. An OAM capability TLV is signaled as part of 708 the PW FEC interface parameters TLV. For L2TP-IP PSNs, the PEs 709 negotiate the use of VCCV during the pseudowire session 710 initialization using the VCCV AVP [RFC5085]. 712 The CV Type Indicators field in this TLV defines a bitmask used to 713 indicate the specific OAM capabilities that the PE can make use of 714 over the PW being established. 716 A CV type of 0x04 or 0x10 indicates that BFD is used for PW fault 717 detection only [VCCV-BFD]. These CV types MAY be used any time the PW 718 is established using LDP or L2TP control planes. 720 In this mode, only the following diagnostic (Diag) codes specified in 721 [BFD] will be used, they are: 723 0 - No diagnostic: 725 1 - Control detection time expired 727 7 - Administratively Down 729 A PE MUST use code 0 to indicate to its peer PE that is correctly 730 receiving BFD control messages. It MUST use the second code to 731 indicate that to its peer it has stopped receiving BFD control 732 messages. A PE shall use "Administrative down" to bring down the BFD 733 session when the PW is brought down administratively. All other 734 defects, such as AC/PW defects and PE internal failures that prevent 735 it from forwarding traffic, MUST be communicated through LDP Status 736 TLV in the case of MPLS PSN or MPLS-IP PSN, or through the 737 appropriate L2TP codes in the Circuit Status AVP in the case of L2TP- 738 IP PSN. 740 A CV type of 0x08 or 0x20 in the OAM capabilities TLV indicates that 741 BFD is used for both PW fault detection and Fault Notification. In 742 addition to the above diagnostic codes, a PE used the following codes 743 to signal AC defects and other defects impacting forwarding over the 744 PW service: 746 6 -- Concatenated Path Down 748 8 -- Reverse Concatenated Path Down 750 TBD -- PW not forwarding 752 A PE MAY use the "PW not forwarding" code to convey any other defect 753 that cannot be represented by code points 6 and 8. In general, this 754 applies to a defect that does not cause the PW to be torn down. This 755 implies the BFD session must not be brought down when this defect 756 exists. 758 The forward and reverse defect indication definitions used in this 759 document map to the BFD codes as follows: 761 Forward defect indication - corresponds to the logical OR of 763 Concatenated Path Down and PW not forwarding 765 Reverse defect indication- corresponds to Reverse 767 Concatenated Path Down 769 These diagnostic codes are used to signal forward and reverse defect 770 states respectively when the PEs negotiated the use of BFD as the 771 mechanism for AC and PW fault detection and status signaling 772 notification. As stated in Section 8.1. , these CV types SHOULD NOT 773 be used when the PW is established with the LDP or L2TP control 774 plane. 776 8.2. PW Defect State Entry/Exit 778 8.2.1. PW Forward Defect State Entry/Exit Criteria 780 PE1 will enter the PW forward defect state if one or more of the 781 following occurs: 783 - It receives a forward defect indication from PE2, which 784 indicates PE2 detected or was notified of a PW fault 785 downstream of it or that there was a forward defect on 786 remote AC. 788 - It detects loss of connectivity on the PSN tunnel 789 upstream of PE1 which affects the traffic it receives 790 from PE2. 792 - It detects a loss of PW connectivity through VCCV-BFD or 793 VCCV-PING which affects the traffic it receives from PE2. 795 Note that if the PW control session between the PEs fails, the PW is 796 torn down and needs to be re-established. This includes failure of 797 the T-LDP session, the L2TP session, or the L2TP control connection. 798 However, the consequent actions towards the ACs are the same as if 799 the PW entered the forward defect state. 801 PE1 will exit the PW forward defect state when the following 802 conditions are true. Note that this may result in a transition to the 803 PW operational state or the PW reverse defect state. 805 - All defects it had previously detected have disappeared, 806 and 808 - PE2 cleared the forward defect indication if applicable. 810 8.2.2. PW Reverse Defect State Entry/Exit Criteria 812 PE1 will enter the PW reverse defect state if the following 813 conditions are true: 815 - it receives a reverse defect indication from PE2 which 816 indicates that PE2 detected or was notified of a PW fault 817 upstream of it or that there was a reverse fault on the 818 remote AC, and 820 - it is not already in the PW forward defect state. 822 PE1 will exit the reverse defect state if it receives an OAM message 823 from PE2 clearing the reverse defect indication, or it has entered 824 the PW forward defect state. 826 For a PWE3 over a L2TP-IP PSN using the basic Circuit Status AVP 827 [RFC3931], the PW reverse defect state is not valid and a PE can only 828 enter the PW forward defect state. 830 9. Procedures for ATM PW Service 832 9.1. AC forward defect state entry/exit criteria 834 When operating in the "coupled OAM loops" mode, PE1 enters the AC 835 forward defect state if any of the following conditions are met: 837 a. It detects or is notified of a physical layer fault on 838 the ATM interface. 840 b. It receives a segment or end-to-end F4 AIS OAM flow on 841 a VP AC, or a segment or end-to-end F5 AIS OAM flow on 842 a VC AC, indicating that the ATM VPC or VCC is down in 843 the adjacent L2 ATM network. 845 c. It detects loss of connectivity on the ATM VPC/VCC 846 while terminating segment or end-to-end ATM continuity 847 check (ATM CC) cells with the local ATM network and 848 CE. 850 When operating in the "coupled OAM loops" mode, PE1 exits the AC 851 Forward Defect state when all defects it had previously detected have 852 disappeared. 854 When operating in the "single emulated OAM loop" mode, PE1 enters the 855 AC forward defect state if any of the following conditions are met: 857 a. It detects or is notified of a physical layer fault on 858 the ATM interface. 860 b. It receives a segment F4 AIS OAM flow on a VP AC, or a 861 segment F5 AIS OAM flow on a VC AC, indicating that 862 the ATM VPC or VCC is down in the adjacent L2 ATM 863 network. 865 c. It detects loss of connectivity on the ATM VPC/VCC 866 while terminating segment ATM continuity check (ATM 867 CC) cells with the local ATM network and CE. 869 When operating in the "single emulated OAM loop" mode, PE1 exits the 870 AC Forward Defect state when all defects it had previously detected 871 have disappeared. 873 The exact conditions under which a PE enters and exits the AIS state, 874 or declares that connectivity is restored via ATM CC are defined in 875 Section 9.2 of ITU-T Recommendation I.610 [ITU-T I.610]. 877 9.2. AC reverse defect state entry/exit criteria 879 PE1 enters the AC reverse defect state if any of the following 880 conditions are met: 882 a. It terminates an F4 RDI OAM flow, in the case of a 883 VPC, or an F5 RDI OAM flow, in the case of a VCC, 884 indicating that the ATM VPC or VCC is down in the 885 adjacent L2 ATM. 887 PE1 exits the AC Reverse Defect state if the AC state transitions to 888 working or to the AC forward defect state. The exact conditions for 889 exiting the RDI state are described in Section 9.2 of ITU-T 890 Recommendation I.610 [ITU-T I.610]. 892 Note that the AC reverse defect state is not valid when operating in 893 the "single emulated OAM loop" mode as PE1 transparently forwards the 894 received RDI cells as user cells over the ATM PW to the remote CE. 896 9.3. Consequent Actions 898 In the reminder of this section, the text refers to AIS, RDI and CC 899 without specifying whether it is an F4 (VP-level) flow or an F5 (VC- 900 level) flow, or whether it is an end-to-end or a segment flow. 901 Precise ATM OAM procedures for each type of flow are specified in 902 Section 9.2 of ITU-T Recommendation I.610 [ITU-T I.610]. 904 9.3.1. PW forward defect state entry/exit 906 On entry to the PW forward defect state: 908 a. PE1 MUST commence AIS insertion into the corresponding 909 AC. 911 b. PE1 MUST terminate any CC cell generation on the 912 corresponding AC. 914 c. If the PW failure was detected by PE1 without 915 receiving a forward defect notification from PE2, PE1 916 MUST assume PE2 has no knowledge of the defect and 917 MUST notify PE2 in the form of a reverse defect 918 notification. 920 On exit from the PW forward defect state: 922 a. PE1 MUST cease AIS insertion into the corresponding 923 AC. 925 b. PE1 MUST resume any CC cell generation on the 926 corresponding AC. 928 c. PE1 MUST clear the reverse defect notification to PE2 929 if applicable. 931 9.3.2. PW reverse defect state entry/exit 933 On entry to the PW Reverse Defect State: 935 a. PE1 MUST commence RDI insertion into the corresponding 936 AC. 938 b. If the PW failure was detected by PE1 without 939 receiving a reverse defect notification from PE2, PE1 940 MUST assume PE2 has no knowledge of the defect and 941 MUST notify PE2 in the form of a forward defect 942 notification. 944 On exit from the PW Reverse Defect State: 946 a. PE1 MUST cease RDI insertion into the corresponding 947 AC. 949 b. PE1 MUST clear the forward defect notification to PE2 950 if applicable. 952 9.3.3. PW defect state in ATM Port Mode PW Service 954 In case of transparent cell transport PW service, i.e., "port mode", 955 where the PE does not keep track of the status of individual ATM VPCs 956 or VCCs, a PE cannot relay PW defect state over these VCCs and VPCs. 957 If ATM CC is run on the VCCs and VPCs end-to-end (CE1 to CE2), or on 958 a segment originating and terminating in the ATM network and spanning 959 the PSN network, it will timeout and cause the CE or ATM switch to 960 enter the ATM AIS state. 962 9.3.4. AC forward defect state entry/exit 964 On entry to the AC forward defect state and when operating in the 965 "coupled OAM loops" mode: 967 a. PE1 MUST send a forward defect notification to PE2. 969 b. PE1 MUST commence insertion of ATM RDI cells into the 970 AC towards CE1. 972 On entry to the AC forward defect state and when operating in the 973 "single emulated OAM loop" mode: 975 a. PE1 MUST commence insertion of ATM AIS cells into the 976 corresponding PW towards CE2. 978 b. If the defect interferes with NS OAM message 979 generation, PE1 must send a forward defect 980 notification to PE2. 982 c. PE1 MUST terminate any CC cell generation on the 983 corresponding PW. 985 On exit from the AC forward defect state and when operating in the 986 "coupled OAM loops" mode: 988 a. PE1 MUST clear the forward defect notification to PE2. 990 b. PE1 MUST cease insertion of ATM RDI cells into the AC. 992 On exit from the AC forward defect state and when operating in the 993 "single emulated OAM loop" mode: 995 a. PE1 MUST cease insertion of ATM AIS cells into the 996 corresponding PW. 998 b. PE1 MUST clear the forward defect notification to PE2 999 if applicable. 1001 c. PE1 MUST resume any CC cell generation on the 1002 corresponding PW if applicable. 1004 9.3.5. AC reverse defect state entry/exit 1006 On entry to the AC reverse defect state and when operating in the 1007 "coupled OAM loops" mode: 1009 a. PE1 MUST send a reverse defect notification to PE2. 1011 On exit from the AC reverse defect state and when operating in the 1012 "coupled OAM loops" mode: 1014 a. PE1 MUST clear the reverse defect notification to PE2. 1016 10. Procedures for Frame Relay PW Service 1018 10.1. AC forward defect state entry/exit criteria 1020 PE1 enters the AC Forward Defect state if one or more of the 1021 following conditions are true: 1023 a. A PVC is not deleted from the Frame Relay network and 1024 the Frame Relay network explicitly indicates in a full 1025 status report (and optionally by the asynchronous 1026 status message) that this Frame Relay PVC is inactive 1027 [ITU-T Q.933]. In this case, this status maps across 1028 the PE to the corresponding PW only. 1030 b. The Link Integrity Verification (LIV) indicates that 1031 the link from the PE to the Frame Relay network is 1032 down [ITU-T Q.933]. In this case, the link down 1033 indication maps across the PE to all corresponding 1034 PWs. 1036 c. A physical layer alarm is detected on the FR 1037 interface. In this case, this status maps across the 1038 PE to all corresponding PWs. 1040 PE1 exits the AC Forward Defect state when all defects it had 1041 previously detected have disappeared. 1043 10.2. AC reverse defect state entry/exit criteria 1045 The AC reverse defect state is not valid for a FR AC. 1047 10.3. Consequent Actions 1049 10.3.1. PW forward defect state entry/exit 1051 On entry to the PW forward defect state: 1053 a. PE1 MUST set the Active bit = 0 for the corresponding 1054 FR AC in a full status report, and optionally in an 1055 asynchronous status message, as per Q.933 annex A 1056 [ITU-T Q.933]. 1058 b. If the PW failure was detected by PE1 without 1059 receiving a forward defect notification from PE2, PE1 1060 MUST assume PE2 has no knowledge of the defect and 1061 MUST notify PE2 in the form of a reverse defect 1062 notification. 1064 On exit from the PW Forward defect state: 1066 a. PE1 MUST set the Active bit = 1 for the corresponding 1067 FR AC in a full status report, and optionally in an 1068 asynchronous status message, as per Q.933 annex A. PE1 1069 does not apply this procedure on a transition from the 1070 PW forward defect state to the PW reverse defect 1071 state. 1073 b. PE1 MUST clear the reverse defect notification to PE2 1074 if applicable. 1076 10.3.2. PW reverse defect state entry/exit 1078 On entry to the PW reverse defect state: 1080 a. PE1 MUST set the Active bit = 0 for the corresponding 1081 FR AC in a full status report, and optionally in an 1082 asynchronous status message, as per Q.933 annex A. 1084 b. If the PW failure was detected by PE1 without 1085 receiving a reverse defect notification from PE2, PE1 1086 MUST assume PE2 has no knowledge of the defect and 1087 MUST notify PE2 in the form of a forward defect 1088 notification. 1090 On exit from the PW reverse defect state: 1092 a. PE1 MUST set the Active bit = 1 for the corresponding 1093 FR AC in a full status report, and optionally in an 1094 asynchronous status message, as per Q.933 annex A. PE1 1095 does not apply this procedure on a transition from the 1096 PW reverse defect state to the PW forward defect 1097 state. 1099 b. PE1 MUST clear the forward defect notification to PE2 1100 if applicable. 1102 10.3.3. PW defect state in the FR Port Mode PW service 1104 In case of port mode PW service, STATUS ENQUIRY and STATUS messages 1105 are transported transparently over the PW. A PW Failure will 1106 therefore result in timeouts of the Q.933 link and PVC management 1107 protocol at the Frame Relay devices at one or both sites of the 1108 emulated interface. 1110 10.3.4. AC forward defect state entry/exit 1112 On entry to the AC forward defect: 1114 a. PE1 MUST send a forward defect notification to PE2. 1116 On exit from the AC forward defect state: 1118 a. PE1 MUST clear the forward defect notification to PE2. 1120 10.3.5. AC reverse defect state entry/exit 1122 The AC reverse defect state is not valid for a FR AC. 1124 11. Procedures for TDM PW Service 1126 From an OAM perspective, the PSN carrying a TDM PW provides the same 1127 function as that of SONET/SDH or ATM network carrying the same low- 1128 rate TDM stream. Hence the interworking of defect OAM is similar. 1130 For structure-agnostic TDM PWs, the TDM stream is to be carried 1131 transparently across the PSN, and this requires TDM OAM indications 1132 to be transparently transferred along with the TDM data. 1134 For structure-aware TDM PWs the TDM structure alignment is terminated 1135 at ingress to the PSN and regenerated at egress, and hence OAM 1136 indications may need to be signaled by special means. In both cases 1137 generation of the appropriate emulated OAM indication may be required 1138 when the PSN is at fault. 1140 Since TDM is a real-time signal, defect indications and performance 1141 measurements may be classified into two classes, urgent and 1142 deferrable. Urgent messages are those whose contents may not be 1143 significantly delayed with respect to the TDM data that they 1144 potentially impact, while deferrable messages may arrive at the far 1145 end delayed with respect to simultaneously generated TDM data. For 1146 example, a forward indication signifying that the TDM data is invalid 1147 (e.g. TDM loss of signal, or MPLS loss of packets) is only of use 1148 when received before the TDM data is to be played out towards the far 1149 end TDM system. It is hence classified as an urgent message, and we 1150 can not delegate its signaling to a separate maintenance or 1151 management flow. On the other hand, the forward loss of multi-frame 1152 synchronization, and most reverse indications do not need to be acted 1153 upon before a particular TDM frame is played out. 1155 From the above discussion it is evident that the complete solution to 1156 OAM for TDM PWs needs to have at least two, and perhaps three 1157 components. The required functionality is transparent transfer of 1158 native TDM OAM and urgent transfer of indications (by flags) along 1159 with the impacted packets. Optionally there may be mapping between 1160 TDM and PSN OAM flows. 1162 TDM AIS generated in the TDM network due to a fault in that network 1163 is generally carried unaltered, although the TDM encapsulations allow 1164 for its suppression for bandwidth conservation purposes. Similarly, 1165 when the TDM loss of signal is detected at the PE, it will generally 1166 emulate TDM AIS. 1168 SAToP and the two structure-aware TDM encapsulations have converged 1169 on a common set of defect indication flags in the PW control word. 1171 When the PE detects or is informed of lack of validity of the TDM 1172 signal, it raises the local ("L") defect flag, uniquely identifying 1173 the defect as originating in the TDM network. The remote PE must 1174 ensure that TDM AIS is delivered to the remote TDM network. When the 1175 defect lies in the MPLS network, the remote PE fails to receive 1176 packets. The remote PE generates TDM AIS towards its TDM network, and 1177 in addition raises the remote defect ("R") flag in its PSN-bound 1178 packets, uniquely identifying the defect as originating in the PSN. 1180 Finally, defects in the remote TDM network that cause RDI generation 1181 in that network, may optionally be indicated by proper setting of the 1182 field of valid packets in the opposite direction. 1184 12. Procedures for CEP PW Service 1186 Loss of Connectivity and other SONET/SDH protocol failures on the PW 1187 are translated to alarms on the ACs and vice versa. In essence, all 1188 defect management procedures are handled entirely in the emulated 1189 protocol. There is no need for an interaction between PW defect 1190 management and SONET layer defect management. 1192 13. Informative Appendix A: Native Service Management 1194 13.1. Frame Relay Management 1196 The management of Frame Relay Bearer Service (FRBS) connections can 1197 be accomplished through two distinct methodologies: 1199 a. Based on ITU-T Q.933 Annex A, Link Integrity Verification 1200 procedure, where STATUS and STATUS ENQUIRY signaling messages 1201 are sent using DLCI=0 over a given UNI and NNI physical link. 1202 [ITU-T Q.933] 1204 b. Based on FRBS LMI, and similar to ATM ILMI where LMI is 1205 common in private Frame Relay networks. 1207 In addition, ITU-T I.620 addresses Frame Relay loopback, but the 1208 deployment of this standard is relatively limited [ITU-T I.620]. 1210 It is possible to use either, or both, of the above options to 1211 manage Frame Relay interfaces. This document will refer exclusively 1212 to Q.933 messages. 1214 The status of any provisioned Frame Relay PVC may be updated 1215 through: 1217 a. STATUS messages in response to STATUS ENQUIRY messages, these 1218 are mandatory. 1220 b. Optional unsolicited STATUS updates independent of STATUS 1221 ENQUIRY (typically under the control of management system, 1222 these updates can be sent periodically (continuous 1223 monitoring) or only upon detection of specific defects based 1224 on configuration. 1226 In Frame Relay, a DLC is either up or down. There is no distinction 1227 between different directions. To achieve commonality with other 1228 technologies, down is represented as a forward defect. 1230 Frame relay connection management is not implemented over the PW 1231 using either of the techniques native to FR, therefore PW mechanisms 1232 are used to synchronize the view each PE has of the remote NS/AC. A 1233 PE will treat a remote NS/AC failure in the same way it would treat 1234 a PW or PSN failure; that is using AC facing FR connection 1235 management to notify the CE that FR is down. 1237 13.2. ATM Management 1239 ATM management and OAM mechanisms are much more evolved than those 1240 of Frame Relay. There are five broad management-related categories, 1241 including fault management (FT), Performance management (PM), 1242 configuration management (CM), Accounting management (AC), and 1243 Security management (SM). ITU-T Recommendation I.610 describes the 1244 functions for the operation and maintenance of the physical layer 1245 and the ATM layer, that is, management at the bit and cell levels 1246 [ITU-T I.610]. Because of its scope, this document will concentrate 1247 on ATM fault management functions. Fault management functions 1248 include the following: 1250 a. Alarm indication signal (AIS) 1251 b. Remote Defect indication (RDI). 1252 c. Continuity Check (CC). 1253 d. Loopback (LB) 1255 Some of the basic ATM fault management functions are described as 1256 follows: Alarm indication signal (AIS) sends a message in the same 1257 direction as that of the signal, to the effect that an error has 1258 been detected. 1260 Remote defect indication (RDI) sends a message to the transmitting 1261 terminal that an error has been detected. RDI is also referred to as 1262 the far-end reporting failure. Alarms related to the physical layer 1263 are indicated using path AIS/RDI. Virtual path AIS/RDI and virtual 1264 channel AIS/RDI are also generated for the ATM layer. 1266 OAM cells (F4 and F5 cells) are used to instrument virtual paths and 1267 virtual channels respectively with regard to their performance and 1268 availability. OAM cells in the F4 and F5 flows are used for 1269 monitoring a segment of the network and end-to-end monitoring. OAM 1270 cells in F4 flows have the same VPI as that of the connection being 1271 monitored. OAM cells in F5 flows have the same VPI and VCI as that 1272 of the connection being monitored. The AIS and RDI messages of the 1273 F4 and F5 flows are sent to the other network nodes via the VPC or 1274 the VCC to which the message refers. The type of error and its 1275 location can be indicated in the OAM cells. Continuity check is 1276 another fault management function. To check whether a VCC that has 1277 been idle for a period of time is still functioning, the network 1278 elements can send continuity-check cells along that VCC. 1280 14. Informative Appendix B: PW Defects and Detection tools 1282 14.1. PW Defects 1284 Possible defects that impact PWs are the following: 1286 a. Physical layer defect in the PSN interface 1288 b. PSN tunnel failure which results in a loss of connectivity 1289 between ingress and egress PE. 1291 c. Control session failures between ingress and egress PE 1293 In case of an MPLS PSN and an MPLS-IP PSN there are additional 1294 defects: 1296 a. PW labeling error, which is due to a defect in the ingress 1297 PE, or to an over-writing of the PW label value somewhere 1298 along the LSP path. 1300 b. LSP tunnel Label swapping errors or LSP tunnel label merging 1301 errors in the MPLS network. This could result in the 1302 termination of a PW at the wrong egress PE. 1304 c. Unintended self-replication; e.g., due to loops or denial- 1305 of-service attacks. 1307 14.1.1. Packet Loss 1309 Persistent congestion in the PSN or in a PE could impact the proper 1310 operation of the emulated service. 1312 A PE can detect packet loss resulting from congestion through several 1313 methods. If a PE uses the sequence number field in the PWE3 Control 1314 Word for a specific Pseudo Wire [RFC3985], it has the ability to 1315 detect packet loss. Translation of congestion detection to PW defect 1316 states is outside the scope of this specification. 1318 Generally, there are congestion alarms which are raised in the node 1319 and to the management system when congestion occurs. The decision to 1320 declare the PW Down and to select another path is usually at the 1321 discretion of the network operator. 1323 14.2. PW Defect Detection Tools 1325 To detect the defects listed above, Service Providers have a variety 1326 of options available. 1328 Physical Layer defect detection and notification mechanisms such as 1329 SONET/SDH LOS, LOF,and AIS/FERF. 1331 PSN Defect Detection Mechanisms: 1333 For PWE3 over an L2TP-IP PSN, with L2TP as encapsulation protocol, 1334 the defect detection mechanisms described in [RFC3931] apply. This 1335 includes for example the keepalive mechanism performed with Hello 1336 messages for detection of loss of connectivity between a pair of 1337 LCCEs (i.e., dead PE peer and path detection). Furthermore, the 1338 tools Ping and Traceroute, based on ICMP Echo Messages apply [RFC792] 1339 and can be used to detect defects on the IP PSN. Additionally, ICMP 1340 Ping [RFC5085] and BFD [VCCV-BFD] can also be used with VCCV to 1341 detect defects at the individual pseudowire level. 1343 For PWE3 over an MPLS PSN and an MPLS-IP PSN, several tools can be 1344 used. 1346 a. LSP-Ping and LSP-Traceroute( [RFC4379]) for LSP tunnel 1347 connectivity verification. 1349 b. LSP-Ping with Bi-directional Forwarding Detection ([BFD]) 1350 for LSP tunnel continuity checking. 1352 c. Furthermore, if RSVP-TE is used to setup the PSN Tunnels 1353 between ingress and egress PE, the hello protocol can be 1354 used to detect loss of connectivity [RFC3209], but only at 1355 the control plane. 1357 PW specific defect detection mechanisms: 1359 [RFC4377] describes how LSP-Ping and BFD can be used over individual 1360 PWs for connectivity verification and continuity checking 1361 respectively. When used as such, we will refer to them as VCCV-Ping 1362 and VCCV-BFD respectively. 1364 Furthermore, the detection of a fault could occur at different points 1365 in the network and there are several ways the observing PE determines 1366 a fault exists: 1368 a. egress or ingress PE detection of failure (e.g. BFD) 1370 b. ingress PE detection of failure (e.g. LSP-PING) 1372 c. ingress PE notification of failure (e.g. RSVP Path-err) 1374 15. Security Considerations 1376 The mapping messages described in this document do not change the 1377 security functions inherent in the actual messages. 1379 16. IANA Considerations 1381 There is none at this time. 1383 17. References 1385 17.1. Normative References 1387 [BFD] Katz, D., Ward, D., "Bidirectional Forwarding Detection", 1389 [FRF.19] Frame Relay Forum, "Frame Relay Operations, Administration, 1390 and Maintenance Implementation Agreement", March 2001 1392 [ICMP] Postel, J. "Internet Control Message Protocol" RFC 792 1394 [ITU-T I.610] Recommendation I.610 "B-ISDN operation and maintenance 1395 principles and functions", February 1999 1397 [ITU-T I.620] Recommendation I.620 "Frame relay operation and 1398 maintenance principles and functions", October 1996 1400 [ITU-T Q.933] Recommendation Q.933 "ISDN Digital Subscriber 1401 Signalling System No. 1 (DSS1) Signalling specifications for 1402 frame mode switched and permanent virtual connection control and 1403 status monitoring" February 2003 1405 [RFC3931] Lau, J., et. al. "Layer Two Tunneling Protocol (Version 3", 1406 RFC 3931, March 2005 1408 [RFC4023] Worster. T., et al., "Encapsulating MPLS in IP or Generic 1409 Routing Encapsulation (GRE)", RFC 4023, March 2005 1411 [RFC4379] Kompella, K., et. al., "Detecting MPLS Data Plane 1412 Failures", RFC4379, February 2006 1414 [RFC4447] Martini, L., Rosen, E., Smith, T., "Pseudowire Setup and 1415 Maintenance using LDP", RFC4447, April 2006 1417 [RFC5085] Nadeau, T., et al., "Pseudo Wire Virtual Circuit Connection 1418 Verification (VCCV)", RFC 5085, December 2007 1420 [VCCV-BFD] Nadeau, T., Pignataro, C., "Bidirectional Forwarding 1421 Detection (BFD) for the Pseudowire Virtual Circuit Connectivity 1422 Verification (VCCV)", draft-ietf-pwe3-vccv-bfd-02, June 2008 1424 17.2. Informative References 1426 [CONGESTION] Rosen, E., Bryant, S., Davie, B., "PWE3 Congestion 1427 Control Framework", draft-ietf-pwe3-congestion-frmwk-01.txt, May 1428 2008 1430 [ETH-OAM-IWK] Mohan, D., et al., "MPLS and Ethernet OAM 1431 Interworking", draft-mohan-pwe3-mpls-eth-oam-iwk-01, July 2008 1433 [L2TP-Status] McGill, N. Pignataro, C., "L2TPv3 Extended Circuit 1434 Status Values", draft-nmcgill-l2tpext-circuit-status-extensions- 1435 01 (work in progress), June 2008. 1437 [RFC3916] Xiao, X., McPherson, D., Pate, P., "Requirements for 1438 Pseudo Wire Emulation Edge to-Edge (PWE3)", RFC 3916, September 1439 2004 1441 [RFC3985] Bryant, S., Pate, P., "PWE3 Architecture", RFC 3985, March 1442 2005 1444 [RFC4377] Nadeau, T. et.al., "OAM Requirements for MPLS Networks", 1445 RFC4377, February 2006 1447 [RFC4446] Martini, L., et al., "IANA Allocations for pseudo 1448 Wire Edge to Edge Emulation (PWE3)", RFC4446, 1449 April 2006 1451 [RFC4454] Singh, S., Townsley, M., and C. Pignataro, "Asynchronous 1452 Transfer Mode (ATM) over Layer 2 Tunneling Protocol 1453 Version 3 (L2TPv3)", RFC 4454, May 2006 1455 [RFC4717] Martini, L., et al., "Encapsulation Methods for Transport 1456 of ATM Cells/Frame Over IP and MPLS Networks", RFC4717, 1457 December 2006 1459 [RFC4842] Malis, A., et. al., "SONET/SDH Circuit Emulation over 1460 Packet (CEP)", RFC 4842, April 2007 1462 18. Editor's Addresses 1464 Mustapha Aissaoui 1465 Alcatel-lucent 1466 600 March Rd 1467 Kanata, ON, Canada K2K 2E6 1468 Email: mustapha.aissaoui@alcatel-lucent.com 1470 Peter B. Busschbach 1471 Alcatel-Lucent 1472 67 Whippany Road 1473 Whippany, NJ, 07981 1474 Email: busschbach@alcatel-lucent.com 1476 David Allan 1477 Nortel Networks 1478 3500 Carling Ave., 1479 Ottawa, Ontario, CANADA 1480 Email: dallan@nortel.com 1481 Luca Martini 1482 Cisco Systems, Inc. 1483 9155 East Nichols Avenue, Suite 400 1484 Englewood, CO, 80112 1485 Email: lmartini@cisco.com 1487 Thomas D. Nadeau 1488 BT 1489 BT Centre 1490 81 Newgate Street 1491 London EC1A 7AJ 1492 United Kingdom 1493 EMail: tom.nadeau@bt.com 1495 Monique Morrow 1496 Cisco Systems, Inc. 1497 Glatt-com 1498 CH-8301 Glattzentrum 1499 Switzerland 1500 EMail: mmorrow@cisco.com 1502 Full Copyright Statement 1504 Copyright (C) The IETF Trust (2008). 1506 This document is subject to the rights, licenses and restrictions 1507 contained in BCP 78, and except as set forth therein, the authors 1508 retain all their rights. 1510 This document and the information contained herein are provided on 1511 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1512 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1513 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1514 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1515 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1516 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1517 FOR A PARTICULAR PURPOSE. 1519 Intellectual Property Statement 1521 The IETF takes no position regarding the validity or scope of any 1522 Intellectual Property Rights or other rights that might be claimed to 1523 pertain to the implementation or use of the technology described in 1524 this document or the extent to which any license under such rights 1525 might or might not be available; nor does it represent that it has 1526 made any independent effort to identify any such rights. Information 1527 on the procedures with respect to rights in RFC documents can be 1528 found in BCP 78 and BCP 79. 1530 Copies of IPR disclosures made to the IETF Secretariat and any 1531 assurances of licenses to be made available, or the result of an 1532 attempt made to obtain a general license or permission for the use of 1533 such proprietary rights by implementers or users of this 1534 specification can be obtained from the IETF on-line IPR repository at 1535 http://www.ietf.org/ipr. 1537 The IETF invites any interested party to bring to its attention any 1538 copyrights, patents or patent applications, or other proprietary 1539 rights that may cover technology that may be required to implement 1540 this standard. Please address the information to the IETF at 1541 ietf-ipr@ietf.org. 1543 Acknowledgment 1545 Funding for the RFC Editor function is currently provided by the 1546 Internet Society.