idnits 2.17.1 draft-ietf-pwe3-oam-msg-map-02.txt: -(95): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(102): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(115): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(116): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(117): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(121): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(122): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(123): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(126): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(127): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(128): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(132): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(133): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(134): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(248): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(271): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(334): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(566): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(580): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(666): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(667): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(696): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(712): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(718): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(758): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(783): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(843): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(850): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(886): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(892): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(894): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(924): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(945): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(972): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(978): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(979): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(985): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(988): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1004): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1011): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1017): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1020): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1027): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1050): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1065): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1073): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1075): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1087): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1196): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1290): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1316): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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.a on line 29. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. == In addition to a regular copyright notice, the document also has a copyright notice embedded in the text. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 75 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 29 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 3 Scope' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 15 Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 9 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([PWEARCH]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2005) is 7003 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 section? 'PWEARCH' on line 1323 looks like a reference -- Missing reference section? 'MPLS-in-IP' on line 1315 looks like a reference -- Missing reference section? 'L2TPv3' on line 1306 looks like a reference -- Missing reference section? 'VCCV' on line 1337 looks like a reference -- Missing reference section? 'IANA' on line 273 looks like a reference -- Missing reference section? 'CONGESTION' on line 1281 looks like a reference -- Missing reference section? 'ICMP' on line 1293 looks like a reference -- Missing reference section? 'LSPPING' on line 1310 looks like a reference -- Missing reference section? 'BFD' on line 1275 looks like a reference -- Missing reference section? 'RSVP-TE' on line 1334 looks like a reference -- Missing reference section? 'PWE3-CONTROL' on line 575 looks like a reference -- Missing reference section? 'PWE3-ATM' on line 560 looks like a reference -- Missing reference section? 'CEP' on line 1277 looks like a reference -- Missing reference section? 'ITU-T I.620' on line 1298 looks like a reference -- Missing reference section? 'ITU-T I.610' on line 1295 looks like a reference -- Missing reference section? 'CONTROL' on line 1285 looks like a reference -- Missing reference section? 'ITU-T Q.933' on line 1301 looks like a reference -- Missing reference section? 'OAM REQ' on line 1319 looks like a reference -- Missing reference section? 'PWEATM' on line 1326 looks like a reference -- Missing reference section? 'PWREQ' on line 1330 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 5 warnings (==), 23 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Pseudo-Wire Edge-to-Edge(PWE3) Thomas D. Nadeau 3 Internet Draft Monique Morrow 4 Expiration Date: August 2005 Cisco Systems 6 Peter Busschbach 7 Dave Allan Lucent Technologies 8 Nortel Networks 9 Mustapha Aissaoui 10 Alcatel 12 Editors 14 February 2005 16 Pseudo Wire (PW) OAM Message Mapping 17 draft-ietf-pwe3-oam-msg-map-02.txt 19 Status of this Memo 21 This document is an Internet-Draft and is subject to all 22 provisions of section 3 of RFC 3667. By submitting this Internet- 23 Draft, each author represents that any applicable patent or other 24 IPR claims of which he or she is aware have been or will be 25 disclosed, and any of which he or she become aware will be 26 disclosed, in accordance with RFC 3668. This document may not be 27 modified, and derivative works of it may not be created, except to 28 publish it as an RFC and to translate it into languages other than 29 English. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six 37 months and may be updated, replaced, or obsoleted by other 38 documents at any time. It is inappropriate to use Internet-Drafts 39 as reference material or to cite them other than as "work in 40 progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 Abstract 49 This document specifies the mapping of defect states between a 50 Pseudo Wire and the Attachment Circuits (AC) of the end-to-end 51 emulated service. This document covers the case whereby the ACs 52 and the PWs are of the same type in accordance to the PWE3 53 architecture [PWEARCH] such that a homogenous PW service can be 54 constructed. 56 Table of Contents 58 Status of this Memo.............................................1 59 Abstract........................................................1 60 Table of Contents...............................................2 61 1 Conventions used in this document.............................4 62 2 Contributors..................................................4 63 3 Scope.........................................................4 64 4 Terminology...................................................5 65 5 Reference Model and Defect Locations..........................6 66 6 Abstract Defect States........................................7 67 7 PW Status and Defects.........................................8 68 7.1 PW Defects.................................................8 69 7.1.1 Packet Loss...........................................9 70 7.2 Defect Detection and Notification..........................9 71 7.2.1 Defect Detection Tools................................9 72 7.2.2 Defect Detection Mechanism Applicability.............10 73 7.3 Overview of fault notifications...........................11 74 7.3.1 Use of Native Service notifications..................11 75 7.3.2 The Use of PW Status for MPLS and MPLS-IP PSNs.......12 76 7.3.3 The Use of L2TP STOPCCN and CDN......................12 77 7.3.4 The Use of BFD Diagnostic Codes......................12 78 8 PW Defect State Entry/Exit...................................14 79 8.1 PW Forward Defect Entry/Exit..............................14 80 8.2 PW reverse defect state entry/exit........................15 81 8.2.1 PW reverse defects that are treated as AC Forward 82 Defects....................................................15 83 9 AC Defect States.............................................15 84 9.1 FR ACs....................................................15 85 9.2 ATM ACs...................................................16 86 9.2.1 AC Forward Defect State Entry/Exit...................16 87 9.2.2 AC Reverse Defect State Entry/Exit...................16 88 9.3 Ethernet AC State.........................................17 89 10 PW Forward Defect Entry/Exit procedures.....................17 90 10.1 PW Forward Defect Entry Procedures.......................17 91 10.1.1 FR AC procedures....................................17 92 10.1.2 Ethernet AC Procedures..............................17 93 10.1.3 ATM AC procedures...................................17 94 10.1.4 Additional procedures for a FR PW, an ATM PW in the 95 ��out-of-band ATM OAM over PW method��, and an Ethernet PW...17 97 10.2 PW Forward Defect Exit Procedures........................18 98 10.2.1 FR AC procedures....................................18 99 10.2.2 Ethernet AC Procedures..............................18 100 10.2.3 ATM AC procedures...................................18 101 10.2.4 Additional procedures for a FR PW, an ATM PW in the 102 ��out-of-band ATM OAM over PW�� method, and an Ethernet PW...18 103 10.3 PW Reverse Defect Entry Procedures.......................19 104 10.3.1 FR AC procedures....................................19 105 10.3.2 Ethernet AC Procedures..............................19 106 10.3.3 ATM AC procedures...................................19 107 10.4 PW Reverse Defect Exit Procedures........................19 108 10.4.1 FR AC procedures....................................19 109 10.4.2 Ethernet AC Procedures..............................19 110 10.4.3 ATM AC procedures...................................19 111 10.5 Procedures in FR Port Mode...............................19 112 10.6 Procedures in ATM Port Mode..............................20 113 11 AC Defect Entry/Exit Procedures.............................20 114 11.1 AC Forward defect entry:.................................20 115 11.1.1 Procedures for a FR PW, an ATM PW in the ��out-of-band 116 ATM OAM over PW�� method, or an Ethernet PW.................20 117 11.1.2 Procedures for a ATM PW in the ��inband ATM OAM over PW�� 118 method.....................................................20 119 11.1.3 Additional procedures for ATM ACs...................20 120 11.2 AC Reverse defect entry..................................21 121 11.2.1 Procedures for a FR PW, an ATM PW in the ��out-of-band 122 ATM OAM over PW�� method, or an Ethernet PW.................21 123 11.2.2 Procedures for a ATM PW in the ��inband ATM OAM over PW�� 124 method.....................................................21 125 11.3 AC Forward Defect Exit...................................21 126 11.3.1 Procedures for a FR PW, an ATM PW in the ��out-of-band 127 ATM OAM over PW�� method, or an Ethernet PW.................21 128 11.3.2 Procedures for a ATM PW in the ��inband ATM OAM over PW�� 129 method.....................................................22 130 11.3.3 Additional procedures for ATM ACs...................22 131 11.4 AC Reverse Defect Exit...................................22 132 11.4.1 Procedures for a FR PW, an ATM PW in the ��out-of-band 133 ATM OAM over PW�� method, or an Ethernet PW.................22 134 11.4.2 Procedures for a ATM PW in the ��inband ATM OAM over PW�� 135 method.....................................................22 136 12 SONET Encapsulation (CEP)...................................22 137 13 TDM Encapsulation...........................................23 138 14 Appendix A: Native Service Management.......................24 139 14.1 Frame Relay Management...................................24 140 14.2 ATM Management...........................................25 141 14.3 Ethernet Management......................................25 142 15 Security Considerations.....................................26 143 16 Acknowledgments.............................................26 144 17 References..................................................26 145 18 Intellectual Property Disclaimer............................27 146 19 Full Copyright Statement....................................28 147 20 Authors' Addresses..........................................28 149 1 150 Conventions used in this document 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 153 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 154 in this document are to be interpreted as described in RFC 2119. 156 2 Contributors 158 Thomas D. Nadeau, tnadeau@cisco.com 160 Monique Morrow, mmorrow@cisco.com 162 Peter B. Busschbach, busschbach@lucent.com 164 Mustapha Aissaoui, mustapha.aissaoui@alcatel.com 166 Matthew Bocci, matthew.bocci@alcatel.co.uk 168 David Watkinson, david.watkinson@alcatel.com 170 Yuichi Ikejiri, y.ikejiri@ntt.com 172 Kenji Kumaki, kekumaki@kddi.com 174 Satoru Matsushima, satoru@ft.solteria.net 176 David Allan, dallan@nortelnetworks.com 178 Himanshu Shah, hshah@ciena.com 180 Simon Delord, simon.delord@francetelecom.com 182 3 Scope 184 This document specifies the mapping of defect states between a 185 Pseudo Wire and the Attachment Circuits (AC) of the end-to-end 186 emulated service. This document covers the case whereby the ACs 187 and the PWs are of the same type in accordance to the PWE3 188 architecture [PWEARCH] such that a homogenous PW service can be 189 constructed. 191 Ideally only PW and AC defects need be propagated into the Native 192 Service (NS), and NS OAM mechanisms are transported transparently 193 over the PW. Some homogenous scenarios use PW specific OAM 194 mechanisms to synchronize defect state between PEs due to 195 discontinuities in native service OAM between the AC and the PW 196 (e.g. FR LMI), or lack of native service OAM (e.g. Ethernet). 198 The objective of this document is to standardize the behavior of 199 PEs with respects to failures on PWs and ACs, so that there is no 200 ambiguity about the alarms generated and consequent actions 201 undertaken by PEs in response to specific failure conditions. 203 This document covers PWE over MPLS PSN, PWE over IP PSN and PWE 204 over L2TP PSN. 206 4 Terminology 208 AIS Alarm Indication Signal 209 AC Attachment circuit 210 AOM Administration, Operation and Maintenance 211 BDI Backward Defect Indication 212 CC Continuity Check 213 CE Customer Edge 214 CPCS Common Part Convergence Sublayer 215 DLC Data Link Connection 216 FDI Forward Defect Indication 217 FRBS Frame Relay Bearer Service 218 IWF Interworking Function 219 LB Loopback 220 NE Network Element 221 NS Native Service 222 OAM Operations and Maintenance 223 PE Provider Edge 224 PW Pseudowire 225 PSN Packet Switched Network 226 RDI Remote Defect Indicator 227 SDU Service Data Unit 228 VCC Virtual Channel Connection 229 VPC Virtual Path Connection 231 The rest of this document will follow the following convention: 233 The PW can ride over three types of Packet Switched Network (PSN). 234 A PSN which makes use of LSPs as the tunneling technology to 235 forward the PW packets will be referred to as an MPLS PSN. A PSN 236 which makes use of MPLS-in-IP tunneling [MPLS-in-IP], with a MPLS 237 shim header used as PW demultiplexer, will be referred to as an 238 MPLS-IP PSN. A PSN, which makes use of L2TPv3 [L2TPv3] as the 239 tunneling technology, will be referred to as L2TP-IP PSN. 241 If LSP-Ping is run over a PW as described in [VCCV] it will be 242 referred to as VCCV-Ping. 244 If BFD is run over a PW as described in [VCCV] it will be referred 245 to as VCCV-BFD. 247 In the context of this document a PE forwards packets between an 248 AC and a PW. The other PE that terminates the PW is the ��peer�� PE 249 and the attachment circuit associated with the far end PW 250 termination is the ��remote AC��. 252 Defects are discussed in the context of defect states, and the 253 criteria to enter and exit the defect state. 255 The direction of defects is discussed from the perspective of the 256 observing PE and what the PE may explicitly know about information 257 transfer capabilities of the PW service. 259 A forward defect is one that impacts information transfer to the 260 observing PE. It impacts the observing PE�s ability to receive 261 information. A forward defect MAY also imply impact on information 262 sent or relayed by the observer (and as it cannot receive is 263 therefore unknowable) and so the forward defect state is 264 considered to be a superset of the two defect states. 266 A reverse defect is one that uniquely impacts information sent or 267 relayed by observer. 269 At the present time code points for forward defect and reverse 270 defect have not been specified for BFD and LDP PW control. These 271 are referred to as ��forward defect�� and ��reverse defect�� 272 indications as placeholders for code point assignment. However, a 273 mapping to existing PW status code points [IANA] may be performed: 275 Forward defect - corresponds to the logical OR of 276 Local Attachment Circuit ( ingress ) Receive Fault 277 AND 278 Local PSN-facing PW ( egress ) Transmit Fault 280 Reverse defect - corresponds to the logical OR of 281 Local Attachment Circuit ( egress ) Transmit Fault 282 AND 283 Local PSN-facing PW ( egress ) Receive Fault 285 5 Reference Model and Defect Locations 287 Figure 1 illustrates the PWE3 network reference model with an 288 indication of the possible defect locations. This model will be 289 referenced in the remainder of this document for describing the 290 OAM procedures. 292 ACs PSN tunnel ACs 293 +----+ +----+ 294 +----+ | PE1|==================| PE2| +----+ 295 | |---(a)---(b)..(c)......PW1..(d)..(c)..(f)---(e)---| | 296 | CE1| (N1) | | | | (N2) |CE2 | 297 | |----------|............PW2.............|----------| | 298 +----+ | |==================| | +----+ 299 ^ +----+ +----+ ^ 300 | Provider Edge 1 Provider Edge 2 | 301 | | 302 |<-------------- Emulated Service ---------------->| 303 Customer Customer 304 Edge 1 Edge 2 305 Figure 1: PWE3 Network Defect Locations 306 In all interworking scenarios described in this document, it is 307 assumed that at PE1 the AC and the PW are of the same type. The 308 procedures described in this document exclusively apply to PE1. 309 PE2 for a homogenous service implements the identical 310 functionality (although it is not required to as long as the 311 notifications across the PWs are consistent). 313 The following is a brief description of the defect locations: 315 (a) Defect in the first L2 network (N1). This covers any defect 316 in the N1 which impacts all or a subset of ACs terminating in 317 PE1. The defect is conveyed to PE1 and to the remote L2 318 network (N2) using the native service specific OAM defect 319 indication. 320 (b) Defect on a PE1 AC interface. 321 (c) Defect on a PE PSN interface. 322 (d) Defect in the PSN network. This covers any defect in the PSN 323 which impacts all or a subset of the PSN tunnels and PWs 324 terminating in a PE. The defect is conveyed to the PE using a 325 PSN and/or a PW specific OAM defect indication. Note that 326 control plane, i.e., signaling and routing, messages do not 327 necessarily follow the path of the user plane messages. 328 Defect in the control plane are detected and conveyed 329 separately through control plane mechanisms. However, in some 330 cases, they have an impact on the status of the PW as 331 explained in the next section. 332 (e) Defect in the second L2 network (N2). This covers any defect 333 in N2 which impacts all or a subset of ACs terminating in PE2 334 (which is considered a ��remote AC defect�� in the context of 335 procedures outlined in this draft). The defect is conveyed to 336 PE2 and to the remote L2 network (N1) using the native 337 service OAM defect indication. 338 (f) Defect on a PE2 AC interface (which is also considered a 339 ��remote AC defect�� in the context of this draft). 341 6 Abstract Defect States 343 PE1 is obliged to track four abstract defect states that reflect 344 the observed state of both directions of the PW service on both 345 the AC and the PW sides. Faults may impact only one or both 346 directions of the PW. 348 The observed state is a combination of faults directly detected by 349 PE1, or faults it has been made aware of via notifications. 351 +-----+ 352 ----AC forward---->| |-----PW reverse----> 353 CE1 | PE1 | PE2/CE2 354 <---AC reverse-----| |<----PW forward----- 355 +-----+ 357 (arrows indicate direction of traffic) 358 Figure 2: Forward and Reverse Defect States 359 PE1 will directly detect or be notified of AC forward and PW 360 forward defects as they occur upstream of PE1 and impact traffic 361 being sent to PE1. PE1 will only be notified of AC reverse and PW 362 reverse defects as they universally will be detected by other 363 devices and only impact traffic that has already been relayed by 364 PE1. 366 The procedures outlined in this document define the entry and exit 367 criteria for each of the four states with respect to the set of 368 potential ACs and PWs within the document scope and the consequent 369 actions that PE1 must perform to properly interwork those 370 notifications. The abstract defect states used by PE1 are common 371 to all potential interworking combinations of PWs and ACs. 373 When a PE has multiple sources of notifications from a peer (e.g. 374 PSN and LDP control plane), it is obliged to track all sources, 375 but with respect to consequent actions the forward state ALWAYS 376 has precedence over the reverse state. 378 7 PW Status and Defects 380 This section describes possible PW defects, ways to detect them 381 and consequent actions. 383 7.1 PW Defects 385 Possible defects that impact PWs are the following. 387 . Physical layer defect in the PSN interface 389 . PSN tunnel failure which results in a loss of connectivity 390 between ingress and egress PE. 392 . Control session failures between ingress and egress PE 394 In case of an MPLS PSN and an MPLS-IP PSN there are additional 395 defects: 397 . PW labeling error, which is due to a defect in the ingress PE,or 398 to an over-writing of the PW label value somewhere along the LSP 399 path. 401 . LSP tunnel Label swapping errors or LSP tunnel label merging 402 errors in the MPLS network. This could result in the termination 403 of a PW at the wrong egress PE. 405 . Unintended self-replication; e.g., due to loops or denial-of- 406 service attacks. 408 7.1.1 Packet Loss 410 Persistent congestion in the PSN or in a PE could impact the 411 proper operation of the emulated service. 413 A PE can detect packet loss resulting from congestion through 414 several methods. If a PE uses the sequence number field in the 415 PWE3 Control Word for a specific Pseudo Wire [PWEARCH], it has the 416 ability to detect packet loss. [CONGESTION] discusses other 417 possible mechanisms to detect congestion between PWs. 419 Generally, there are congestion alarms which are raised in the 420 node and to the management system when congestion occurs. The 421 decision to declare the PW Down and to re-signal it through 422 another path is usually at the discretion of the network operator. 424 7.2 Defect Detection and Notification 426 7.2.1 Defect Detection Tools 428 To detect the defects listed in 7.1, Service Providers have a 429 variety of options available: 431 Physical Layer defect detection and notification mechanisms such 432 as SONET/SDH LOS, LOF,and AIS/FERF. 434 PSN Defect Detection Mechanisms: 436 For PWE3 over an L2TP-IP PSN, with L2TP as encapsulation protocol, 437 the defect detection mechanisms described in [L2TPv3] apply. 438 Furthermore, the tools Ping and Traceroute, based on ICMP Echo 439 Messages apply [ICMP]. 441 For PWE3 over an MPLS PSN and an MPLS-IP PSN, several tools can be 442 used. 443 . LSP-Ping and LSP-Traceroute( [LSPPING]) for LSP tunnel 444 connectivity verification. 446 . LSP-Ping with Bi-directional Forwarding Detection ([BFD]) for 447 LSP tunnel continuity checking. 449 .Furthermore, if RSVP-TE is used to setup the PSN Tunnels between 450 ingress and egress PE, the hello protocol can be used to detect 451 loss of connectivity (see [RSVP-TE]), but only at the control 452 plane. 454 PW specific defect detection mechanisms: 456 [VCCV] describes how LSP-Ping and BFD can be used over individual 457 PWs for connectivity verification and continuity checking 458 respectively. When used as such, we will refer to them as VCCV- 459 Ping and VCCV-BFD respectively. 461 Furthermore, the detection of a fault could occur at different 462 points in the network and there are several ways the observing PE 463 determines a fault exists: 465 a. egress PE detection of failure (e.g. BFD) 466 b. ingress PE detection of failure (e.g. LSP-PING) 467 c. ingress PE notification of failure (e.g. RSVP Path-err) 469 7.2.2 Defect Detection Mechanism Applicability 471 The discussion below is intended to give some perspective how 472 tools mentioned in the previous section can be used to detect 473 failures. 475 Observations: 477 . Tools like LSP-Ping and BFD can be run periodically or on 478 demand. If used for defect detection, as opposed to diagnostic 479 usage, they must be run periodically. 481 . Control protocol failure indications, e.g. detected through L2TP 482 Keep-alive messages or the RSVP-TE Hello messages, can be used to 483 detect many network failures. However, control protocol failures 484 do not necessarily coincide with data plane failures. Therefore, a 485 defect detection mechanism in the data plane is required to 486 protect against all potential data plane failures. Furthermore, 487 fault diagnosis mechanisms for data plane failures are required to 488 further analyze detected failures. 490 . For PWE3 over an MPLS PSN and an MPLS-IP PSN, it is effective to 491 run a defect detection mechanism over a PSN Tunnel frequently and 492 run one over every individual PW within that PSN Tunnel less 493 frequently. However in case the PSN traffic is distributed over 494 Equal Cost Multi Paths (ECMP), it may be difficult to guarantee 495 that PSN OAM messages follow the same path as a specific PW. A 496 Service Provider might therefore decide to focus on defect 497 detection over PWs. 499 . In MPLS networks, execution of LSP Ping would detect MPLS label 500 errors, since it requests the receiving node to match the label 501 with the original FEC that was used in the LSP set up. BFD can 502 also be used since it relies on discriminators. A label error 503 would result in a mismatch between the expected discriminator and 504 the actual discriminator in the BFD control messages. 506 . For PWE3 over an MPLS PSN and an MPLS-IP PSN, PEs could detect 507 PSN label errors through the execution of LSP-Ping. However, use 508 of VCCV is preferred as it is a more accurate detection tool for 509 pseudowires. 510 Furthermore, it can be run using a BFD mode, i.e., VCCV-BFD, which 511 allows it to be used as a light-weight detection mechanism for 512 PWs. If, due to a label error in the PSN, a PW would be terminated 513 on the wrong egress PE, PEs would detect this through the 514 execution of VCCV. LSP ping and/or LSP trace could then be used to 515 diagnose the detected failure. 517 Based on these observations, it is clear that a service provider 518 has the disposal of a variety of tools. There are many factors 519 that influence which combination of tools best meets its needs. 521 7.3 Overview of fault notifications 522 For a MPLS PSN and a IP PSN using MPLS-in-IP (MPLS-IP PSN), PW 523 status signaling messages are used as the default mechanism for AC 524 and PW status and defect indication [PWE3-CONTROL]. 526 For a IP PSN using L2TPv3, i.e., a L2TP-IP PSN, StopCCN and CDN 527 messages are used for conveying defects in the PSN and PW 528 respectively, while the Set-Link-Info (SLI) messages are used to 529 convey status and defects in the AC and local L2 network. 531 Optionally, PEs can negotiate the use of VCCV-BFD for both PW 532 fault detection and AC/PW fault notifications as explained in 533 [VCCV]. What BFD is used for is negotiated: 534 i. not used 535 ii. used for PW fault detection (which implies reverse 536 notifications) 537 iii. used for PW fault detection and all PW/AC fault 538 notifications 540 When BFD is to be used for all fault notifications, then BFD is 541 the preferred mechanism of exchanging fault notifications. 543 PE1 will translate the PW defect states to the appropriate failure 544 indications on the affected ACs. The exact procedures depend on 545 the emulated protocols and will be discussed in the next sections. 547 7.3.1 Use of Native Service notifications 548 In the context of this document, ATM and unstructured SONET/TDM 549 PWs are the only examples of a PW that has native service 550 notification capability. Frame relay does have the FR OAM 551 specification [FRF.19], but this is not commonly deployed. All 552 other PWs use PW specific notification mechanisms. 554 ATM PWs may optionally also use PW specific notification 555 mechanisms. 557 In normal, i.e., defect-free, operation, all the types of ATM OAM 558 cells described in Section 14.2 are either terminated at the PE, 559 for OAM segments terminating in the AC endpoint, or transparently 560 carried over the PSN tunnel [PWE3-ATM]. This is referred to as 561 ��inband ATM OAM over PW�� and is the default method. 563 An optional out-of band method based on relaying the ATM defect 564 state over a PW specific defect indication mechanism is provided 565 for PE�s which cannot generate and/or transmit ATM OAM cells over 566 the ATM PW. This is referred to as ��Out-of-band ATM OAM over PW��. 568 7.3.2 The Use of PW Status for MPLS and MPLS-IP PSNs 569 This document specifies the use of PW status signaling as the 570 default mechanism for the purpose of conveying the status of a PW 571 and ACs between PEs. 573 For a MPLS PSN and a IP PSN using MPLS-in-IP (MPLS-IP PSN), PW 574 status signaling messages are used as the default mechanism for AC 575 and PW status and defect indication [PWE3-CONTROL]. 577 PW status is used to convey the defect view of the PW local to the 578 originating PE. This is the local PW state, and when the NS does 579 not have native OAM capability or emulation of native capability 580 is prohibitive, the AC state. This is in the form of a ��forward 581 defect�� or a ��reverse defect��. 583 7.3.3 The Use of L2TP STOPCCN and CDN 585 [L2TPv3] describes the use of STOPCCN and CDN messages to exchange 586 alarm information between PEs. Like PW Status, STOPCCN and CDN 587 messages shall be used to report the following failures: 589 . Failures detected through defect detection mechanisms in the 590 L2TP-IP PSN 592 . Failures detected through VCCV (except for VCCV-BFD) 594 . Failures within the PE that result in an inability to forward 595 traffic between ACs and PW 597 In L2TP, the Set-Link-Info (SLI) message is used to convey 598 failures on the ACs. 600 7.3.4 The Use of BFD Diagnostic Codes 602 If the PEs have negotiated the use of VCCV-BFD for both PW fault 603 detection and AC/PW fault notifications as explained in [VCCV] 604 then BFD is the preferred mechanism of exchanging fault 605 notifications. 607 [BFD] defines a set of diagnostic codes that partially overlap 608 with failures that can be communicated through PW Status messages 609 or L2TP STOPCCN and CDN messages. To avoid ambiguous situations, 610 these messages SHOULD be used for all failures that are detected 611 through means other than BFD. 613 For VCCV-BFD, therefore, only the following diagnostic codes 614 apply: 616 Code Message 617 ---- ------------------------------ 618 0 No Diagnostic 619 1 Control Detection Time Expired 620 3 Neighbor Signaled Session Down 621 7 Administratively Down 623 [VCCV] states that, when used over PWs, the asynchronous mode of 624 BFD should be used. Diagnostic code 2 (Echo Function Failed) does 625 not apply to the asynchronous mode, but to the Demand Mode. 627 All other BFD diagnostic codes refer to failures that can be 628 communicated through PW Status or L2TP STOPCCN and CDN. 630 The VCCV-BFD procedures are as follows: 632 When the downstream PE (PE1) does not receive control messages 633 from the upstream PE (PE2) during a certain number of transmission 634 intervals (a number provisioned by the operator), it declares that 635 the PW in its receive direction is down. PE1 sends a message to 636 PE2 with H=0 (i.e. "I do not hear you") and with diagnostic code 637 1. In turn, PE2 declares the PW is down in its transmit direction 638 and it uses diagnostic code 3 in its control messages to PE2. 640 When a PW is taken administratively down, the PEs will exchange PW 641 Status messages with code "Pseudo Wire Not Forwarding" or L2TP CDN 642 messages with code "Session disconnected for administrative 643 reasons". In addition, exchange of BFD control messages MUST be 644 suspended. To that end, the PEs MUST send control messages with 645 H=0 and diagnostic code 7. 647 In conclusion, one would communicate PW defects through PW Status 648 messages, or L2TP STOPCCN and CDN messages in all cases, except 649 for a well-defined set of exceptions where BFD is used. How PW 650 defects that can be detected through the use of BFD or through 651 other means, are mapped to defect indications on the ACs is 652 described in section Error! Reference source not found. and in 653 subsequent sections. 655 8 PW Defect State Entry/Exit 657 8.1 PW Forward Defect Entry/Exit 659 A PE will enter the PW forward defect state if one of the 660 following occurs 662 . It detects loss of connectivity on the PSN tunnel over which the 663 PW is riding. This includes label swapping errors and label 664 merging errors. 666 . It receives a message from PE2 indicating PW ��forward defect�� or 667 ��PW not forwarding��, which indicates PE2 detected or was notified 668 of a PW fault downstream of it or that there was a remote AC 669 fault. 671 In the case of an L2TP-IP, this is a L2TP StopCCN or CDN message. 672 A StopCCN message indicates that the control connection has been 673 shut down by the remote PE [L2TPv3]. This is typically used for 674 defects in the PSN which impact both the co 675 ntrol connection and the individual data plane sessions. On 676 reception of this message, a PE closes the control connection and 677 will clear all the sessions managed by this control connection. 678 Since each session carries a single PW, the state of the 679 corresponding PWs is changed to DOWN. A CDN message indicates that 680 the remote peer requests the disconnection of a specific session 681 [L2TPv3]. In this case only the state of the corresponding PW is 682 changed to DOWN. This is typically used for local defects in a PE 683 which impact only a specific session and the corresponding PW. 685 . It detects a loss of PW connectivity, including label errors, 686 through VCCV-BFD or VCCV-PING in no reply mode. 688 Note that if the PW control session between the PEs fails, the PW 689 is torn down and needs to be re-established. However, the 690 consequent actions towards the ACs are the same as if the PW 691 entered the forward defect state. Precise details of AC defect 692 state entry and exit criteria are specified elsewhere (e.g. I.610) 693 and such references will supersede the descriptions herein. 695 PE1 will exit the forward defect state if the notified PW status 696 from the PE2 has the ��forward defect�� indication clear, and it has 697 established that PW/PSN connectivity is working in the forward 698 direction. Note that this may result in a transition to the PW 699 working or PW reverse defect states. 700 For a PWE3 over a L2TP-IP PSN, a PE will exit the PW forward 701 defect state when the following conditions are true: 703 . All defects it had previously detected have disappeared, and 704 . A L2TPv3 session is successfully established to carry the PW 705 packets. 707 8.2 PW reverse defect state entry/exit 709 A PE will enter the PW reverse defect state if one of the 710 following occurs 712 . It receives a message from PE2 indicating PW ��reverse defect�� 713 which indicates PE2 detected or was notified of a PW/PSN fault 714 upstream of it or that there was a remote AC fault and it is not 715 already in the PW forward defect state. 717 PE1 will exit the reverse defect state if the notified PW status 718 from the PE2 has the ��reverse defect�� indication clear, or it has 719 entered the PW forward defect state. 721 For a PWE3 over a L2TP-IP PSN, a PE will exit the PW reverse 722 defect state when the following conditions are true: 724 . All defects it had previously detected have disappeared, and 726 . A L2TPv3 session is successfully established to carry the PW 727 packets. 729 8.2.1 PW reverse defects that are treated as AC Forward Defects 731 Some PW mechanisms will result in PW defects being detected by or 732 notified to PE1 when PE1 is upstream of the fault but the 733 notification did not originate with PE2. The resultant actions are 734 identical to that of entering the AC forward defect state as PE1 735 needs to synchronize state with PE2 and the PW state communicated 736 from PE1 to PE2 needs to indicate state accordingly. 738 When the PSN uses RSVP-TE or proactively uses LSP-PING as a PW 739 fault detection mechanism, PE1 must consider entry to the AC 740 forward defect state to be the logical or of the AC entry criteria 741 outlined for each AC type in the subsequent sections, and that of 742 the known PW state in the direction of PE2 downstream of PE1 743 (indicated via RSVP patherr or LSP-PINGs). 745 The exit criteria being when the logical AND of the RSVP fault 746 state, LSP-PING fault state and the actual AC forward defect exit 747 criteria has been met, indicating no forward defects. 749 9 AC Defect States 751 9.1 FR ACs 752 PE1 enters the AC Forward Defect state if any of the following 753 conditions are met: 755 (i) A PVC is not �deleted� from the Frame Relay network and 756 the Frame Relay network explicitly indicates in a full 757 status report (and optionally by the asynchronous status 758 message) that this Frame Relay PVC is �inactive�. In this 759 case, this status maps across the PE to the corresponding 760 PW only. 761 (ii) The LIV indicates that the link from the PE to the Frame 762 Relay network is down. In this case, the link down 763 indication maps across the PE to all corresponding PWs. 764 (iii) A physical layer alarm is detected on the FR interface. In 765 this case, this status maps across the PE to all 766 corresponding PWs. 767 A PE exits the AC Forward Defect state when all defects it had 768 previously detected have disappeared. 770 The AC reverse defect state is not valid for FR ACs. 772 9.2 ATM ACs 774 9.2.1 AC Forward Defect State Entry/Exit 776 PE1 enters the AC forward defect state if any of the following 777 conditions are met: 778 (i) It detects or is notified of a physical layer fault on the 779 ATM interface and/or it terminates an F4 AIS flow or has 780 loss of F4 CC for a VP carrying VCC�s. 781 (ii) It terminates an F4/F5 AIS OAM flow indicating that the 782 ATM VP/VC is down in the adjacent L2 ATM network (e.g., N1 783 for PE1). This is applicable to the case of the ��out-of- 784 band ATM OAM over PW�� method only. 785 (iii) It detects loss of connectivity on the NS ATM VPC/VCC 786 while terminating ATM continuity checking (ATM CC) with 787 the local ATM network and CE. 789 A PE exits the AC Forward Defect state when all defects it had 790 previously detected have disappeared. The exact conditions under 791 which a PE exits the AIS state, or declares that connectivity is 792 restored via ATM CC are defined in I.610 [I.610]. 794 9.2.2 AC Reverse Defect State Entry/Exit 796 A PE enters the AC reverse defect state if any of the following 797 conditions are met: 798 (i) It terminates an F4/F5 RDI OAM flow indicating that the 799 ATM VP/VC AC is down in the adjacent L2 ATM network (e.g., 800 N1 for PE1). This is applicable to the case of out-of-band 801 ATM OAM over PW only. 803 A PE exits the AC Reverse Defect state if the AC state transitions 804 to working or to the AC forward defect state. The criteria for 805 exiting the RDI state are described in I.610. 807 9.3 Ethernet AC State 809 PE1 enters the forward defect state if any of the following 810 conditions are met: 812 (i) A physical layer alarm is detected on the Ethernet 813 interface. 815 A PE exits the Ethernet AC forward defect state when all defects 816 it had previously detected have disappeared. 818 10 PW Forward Defect Entry/Exit procedures 820 10.1 PW Forward Defect Entry Procedures 822 10.1.1 FR AC procedures 823 These procedures are applicable only if the transition from the 824 working state to the PW Forward defect state. A transition from PW 825 reverse defect state to the forward defect state does not require 826 any additional notification procedures to the FR AC as it has 827 already been told the peer is down. 828 (i) PE1 MUST generate a full status report with the Active bit 829 = 0 (and optionally in the asynchronous status message), 830 as per Q.933 annex A, into N1 for the corresponding FR 831 ACs. 833 10.1.2 Ethernet AC Procedures 834 No procedures are currently defined. 836 10.1.3 ATM AC procedures 837 On entry to the PW Forward Defect State 838 (i) PE1 MUST commence F5 AIS insertion into the corresponding 839 AC. 840 (ii) PE1 MUST terminate any F5 CC generation on the 841 corresponding AC. 843 10.1.4 Additional procedures for a FR PW, an ATM PW in the ��out-of- 844 band ATM OAM over PW method��, and an Ethernet PW 845 If the PW failure was explicitly detected by PE1, it MUST assume 846 PE2 has no knowledge of the defect and MUST notify PE2 in the form 847 of a reverse defect notification: 849 For PW over MPLS PSN or MPLS-IP PSN 850 (i) A PW Status message indicating a ��reverse defect��, or 851 (ii) A VCCV-BFD diagnostic code if the optional use of VCCV-BFD 852 notification has been negotiated 854 For PW over L2TP-IP PSN 855 (i) An L2TP Set-Link Info (LSI) message with a Circuit Status 856 AVP indicating "active" Or, 857 (ii) A VCCV-BFD diagnostic code if the optional use of VCCV-BFD 858 notification has been negotiated 860 Otherwise the entry to the defect state was the result of a 861 notification from PE2 (indicating that PE2 already had knowledge 862 of the fault) or loss of the control adjacency (similarly visible 863 to PE2). 865 10.2 PW Forward Defect Exit Procedures 867 10.2.1 FR AC procedures 868 On transition from the PW forward defect state to the reverse 869 defect state PE1 takes no action w.r.t. the AC. 871 On exit from the PW Forward defect state 872 (i) PE1 MUST generate a full status report with the Active bit 873 = 1 (and optionally in the asynchronous status message), 874 as per Q.933 annex A, into N1 for the corresponding FR 875 ACs. 877 10.2.2 Ethernet AC Procedures 878 No procedures are currently defined 880 10.2.3 ATM AC procedures 881 On exit from the PW Forward Defect State 882 (i) PE1 MUST cease F5 AIS insertion into the corresponding AC. 883 (ii) PE1 MUST resume any F5 CC generation on the corresponding 884 AC. 886 10.2.4 Additional procedures for a FR PW, an ATM PW in the ��out-of- 887 band ATM OAM over PW�� method, and an Ethernet PW 888 If the PW failure was explicitly detected by PE1, it MUST notify 889 PE2 in the form of clearing the reverse defect notification: 891 For PW over MPLS PSN or MPLS-IP PSN 892 (i) A PW Status message with the ��reverse defect�� indication 893 clear, and the remaining indicators showing either working 894 or a transition to the ��forward defect�� state. Or, 895 (ii) A VCCV-BFD diagnostic code with the same attribute as (i) 896 if the optional use of VCCV-BFD notification has been 897 negotiated 899 For PW over L2TP-IP PSN 900 (i) An L2TP Set-Link Info (LSI) message with a Circuit Status 901 AVP indicating "active" Or, 902 (ii) A VCCV-BFD diagnostic code with the same attributes as (i) 903 if the optional use of VCCV-BFD notification has been 904 negotiated 906 10.3 PW Reverse Defect Entry Procedures 908 10.3.1 FR AC procedures 909 On transition from the PW forward defect state to the reverse 910 defect state PE1 takes no action w.r.t. the AC. 912 On entry to the PW reverse defect state 913 (i) PE1 MUST generate a full status report with the Active bit 914 = 0 (and optionally in the asynchronous status message), 915 as per Q.933 annex A, into N1 for the corresponding FR 916 ACs. 918 10.3.2 Ethernet AC Procedures 919 No procedures are currently defined 921 10.3.3 ATM AC procedures 922 On entry to the PW Reverse Defect State 923 (i) PE1 MUST commence F5 RDI insertion into the corresponding 924 AC. This applies to the case of an ATM PW in the ��out-of- 925 band ATM OAM over PW�� method only. 927 10.4 PW Reverse Defect Exit Procedures 929 10.4.1 FR AC procedures 930 On transition from the PW reverse defect state to the PW forward 931 defect state PE1 takes no action with respect to the AC. 933 On exit from the PW Reverse defect state 934 (i) PE1 MUST generate a full status report with the Active bit 935 = 1 (and optionally in the asynchronous status message), 936 as per Q.933 annex A, into N1 for the corresponding FR 937 ACs. 939 10.4.2 Ethernet AC Procedures 940 No procedures are currently defined 942 10.4.3 ATM AC procedures 943 On exit from the PW Reverse Defect State 944 (i) PE1 MUST cease F5 RDI insertion into the corresponding AC. 945 This applies to the case of an ATM PW in the ��out-of-band ATM OAM 946 over PW�� method only. 948 10.5 Procedures in FR Port Mode 950 In case of pure port mode, STATUS ENQUIRY and STATUS messages are 951 transported transparently over the PW. A PW Failure will therefore 952 result in timeouts of the Q.933 link and PVC management protocol 953 at the Frame Relay devices at one or both sites of the emulated 954 interface. 956 10.6 Procedures in ATM Port Mode 958 In case of transparent cell transport, i.e., "port mode", where 959 the PE does not keep track of the status of individual ATM VPCs or 960 VCCs, a PE cannot relay PW defect state over these VCCs and VPCs. 961 If ATM CC is run on the VCCs and VPCs end-to-end (CE1 to CE2), or 962 on a segment originating and terminating in the ATM network and 963 spanning the PSN network, it will timeout and cause the CE or ATM 964 switch to enter the ATM AIS state. 966 11 AC Defect Entry/Exit Procedures 968 11.1 AC Forward defect entry: 969 On entry to the forward defect state, PE1 may need to perform 970 procedures on both the PW and the AC. 972 11.1.1 Procedures for a FR PW, an ATM PW in the ��out-of-band ATM OAM 973 over PW�� method, or an Ethernet PW 974 On entry to the AC forward defect state, PE1 notifies PE2 of a 975 forward defect: 977 For PW over MPLS PSN or MPLS-IP PSN 978 (i) A PW Status message indicating ��forward defect��, or 979 (ii) A VCCV-BFD diagnostic code of ��forward defect�� if the 980 optional use of VCCV-BFD notification has been negotiated. 982 For PW over L2TP-IP PSN 983 (i) An L2TP Set-Link Info (LSI) message with a Circuit Status 984 AVP indicating "inactive", or 985 (ii) A VCCV-BFD diagnostic code of ��forward defect�� if the 986 optional use of VCCV-BFD notification has been negotiated. 988 11.1.2 Procedures for a ATM PW in the ��inband ATM OAM over PW�� 989 method 990 On entry to the AC forward defect state, PE1 MUST: 991 a. Commence insertion of ATM AIS cells into the corresponding 992 PW. 993 b. If PE1 is originating F4 or F5 I.610 CC cells, PE1 will 994 suspend CC generation for the duration of the defect 995 state. 997 11.1.3 Additional procedures for ATM ACs 998 On entry to the AC forward defect state PE1 will commence RDI 999 insertion into the AC as per I.610. This procedure is applicable 1000 to the ��out-of-band ATM OAM over PW�� method only. 1002 11.2 AC Reverse defect entry 1004 11.2.1 Procedures for a FR PW, an ATM PW in the ��out-of-band ATM OAM 1005 over PW�� method, or an Ethernet PW 1006 On entry to the AC reverse defect state, PE1 notifies PE2 of a 1007 reverse defect: 1009 For PW over MPLS PSN or MPLS-IP PSN 1010 (iii) A PW Status message indicating ��reverse defect��,or 1011 (iv) A VCCV-BFD diagnostic code of ��reverse defect�� if the 1012 optional use of VCCV-BFD notification has been negotiated. 1014 For PW over L2TP-IP PSN 1015 (iii) An L2TP Set-Link Info (LSI) message with a Circuit Status 1016 AVP indicating "inactive", or 1017 (iv) A VCCV-BFD diagnostic code of ��reverse defect�� if the 1018 optional use of VCCV-BFD notification has been negotiated. 1020 11.2.2 Procedures for a ATM PW in the ��inband ATM OAM over PW�� 1021 method 1022 There are no procedures in this case as the AC reverse defect 1023 state is not valid for PE1 operating in this method. 1025 11.3 AC Forward Defect Exit 1027 11.3.1 Procedures for a FR PW, an ATM PW in the ��out-of-band ATM OAM 1028 over PW�� method, or an Ethernet PW 1030 On exit from the AC forward defect state PE1 notifies PE2 that the 1031 forward defect state has cleared (note that this may be a direct 1032 state transition to either the working state or the reverse defect 1033 state): 1035 For PW over MPLS PSN or MPLS-IP PSN 1036 (i) A PW Status message with forward defect clear and the 1037 remaining indicators showing either working or reverse 1038 defect state, or 1039 (ii) A VCCV-BFD diagnostic code with the same attributes as (i) 1040 if the optional use of VCCV-BFD notification has been 1041 negotiated. 1043 For PW over L2TP-IP PSN 1044 (i) An L2TP Set-Link Info (LSI) message with a Circuit Status 1045 AVP indicating "active", or 1046 (ii) A VCCV-BFD diagnostic code with the same attributes as (i) 1047 if the optional use of VCCV-BFD notification has been 1048 negotiated. 1050 11.3.2 Procedures for a ATM PW in the ��inband ATM OAM over PW�� 1051 method 1052 On exit from the AC forward defect state, PE1 MUST: 1053 (i) Cease insertion of ATM AIS cells into the corresponding 1054 PW. 1055 (ii) If PE1 is originating F4 or F5 I.610 CC cells, PE1 will 1056 resume CC generation for the duration of the defect state. 1058 11.3.3 Additional procedures for ATM ACs 1059 On exit from the AC forward defect state PE1 will cease RDI 1060 insertion into the AC as per I.610. This procedure is applicable 1061 to the ��out-of-band ATM OAM over PW�� method only. 1063 11.4 AC Reverse Defect Exit 1065 11.4.1 Procedures for a FR PW, an ATM PW in the ��out-of-band ATM OAM 1066 over PW�� method, or an Ethernet PW 1067 On exit from the AC reverse defect state, PE1 notifies PE2 that 1068 the reverse defect state has cleared (note that this may be a 1069 direct state transition to either the working state or the forward 1070 defect state): 1072 For PW over MPLS PSN or MPLS-IP PSN 1073 (i) A PW Status message with the ��reverse defect�� indicator 1074 cleared and the remaining indicators showing either 1075 working or a transition to the ��forward defect�� state, or 1076 (ii) A VCCV-BFD diagnostic code with the same information as 1077 (i) if the optional use of VCCV-BFD notification has been 1078 negotiated. 1080 For PW over L2TP-IP PSN 1081 (i) An L2TP Set-Link Info (LSI) message with a Circuit Status 1082 AVP indicating "active", or 1083 (ii) A VCCV-BFD diagnostic code with the same information as 1084 (i) if the optional use of VCCV-BFD notification has been 1085 negotiated. 1087 11.4.2 Procedures for a ATM PW in the ��inband ATM OAM over PW�� 1088 method 1089 There are no procedures in this case as the AC reverse defect 1090 state is not valid for PE1 operating in this method. 1092 12 SONET Encapsulation (CEP) 1094 [CEP] discusses how Loss of Connectivity and other SONET/SDH 1095 protocol failures on the PW are translated to alarms on the ACs 1096 and vice versa. In essence, all defect management procedures are 1097 handled entirely in the emulated protocol. There is no need for an 1098 interaction between PW defect management and SONET layer defect 1099 management. 1101 13 TDM Encapsulation 1103 From an OAM perspective, the PSN carrying a TDM PW provides the 1104 same function as that of SONET/SDH or ATM network carrying the 1105 same low-rate TDM stream. Hence the interworking of defect OAM is 1106 similar. 1108 For structure-agnostic TDM PWs, the TDM stream is to be carried 1109 transparently across the PSN, and this requires TDM OAM 1110 indications to be transparently transferred along with the TDM 1111 data. For structure-aware TDM PWs the TDM structure alignment is 1112 terminated at ingress to the PSN and regenerated at egress, and 1113 hence OAM indications may need to be signaled by special means. In 1114 both cases generation of the appropriate emulated OAM indication 1115 may be required when the PSN is at fault. 1117 Since TDM is a real-time signal, defect indications and 1118 performance measurements may be classified into two classes, 1119 urgent and deferrable. Urgent messages are those whose contents 1120 may not be significantly delayed with respect to the TDM data that 1121 they potentially impact, while deferrable messages may arrive at 1122 the far end delayed with respect to simultaneously generated TDM 1123 data. For example, a forward indication signifying that the TDM 1124 data is invalid (e.g. TDM loss of signal, or MPLS loss of packets) 1125 is only of use when received before the TDM data is to be played 1126 out towards the far end TDM system. It is hence classified as an 1127 urgent message, and we can not delegate its signaling to a 1128 separate maintenance or management flow. On the other hand, the 1129 forward loss of multiframe synchronization, and most reverse 1130 indications do not need to be acted upon before a particular TDM 1131 frame is played out. 1133 From the above discussion it is evident that the complete solution 1134 to OAM for TDM PWs needs to have at least two, and perhaps three 1135 components. The required functionality is transparent transfer of 1136 native TDM OAM and urgent transfer of indications (by flags) along 1137 with the impacted packets. Optionally there may be mapping between 1138 TDM and PSN OAM flows. 1140 TDM AIS generated in the TDM network due to a fault in that 1141 network is generally carried unaltered, although the TDM 1142 encapsulations allow for its suppression for bandwidth 1143 conservation purposes. Similarly, when the TDM loss of signal is 1144 detected at the PE, it will generally emulate TDM AIS. 1146 SAToP and the two structure-aware TDM encapsulations have 1147 converged on a common set of defect indication flags in the PW 1148 control word. When the PE detects or is informed of lack of 1149 validity of the TDM signal, it raises the local ("L") defect flag, 1150 uniquely identifying the defect as originating in the TDM network. 1151 The remote PE must ensure that TDM AIS is delivered to the remote 1152 TDM network. When the defect lies in the MPLS network, the remote 1153 PE fails to receive packets. The remote PE generates TDM AIS 1154 towards its TDM network, and in addition raises the remote defect 1155 ("R") flag in its PSN-bound packets, uniquely identifying the 1156 defect as originating in the PSN. Finally, defects in the remote 1157 TDM network that cause RDI generation in that network, may 1158 optionally be indicated by proper setting of the field of valid 1159 packets in the opposite direction. 1161 14 Appendix A: Native Service Management 1163 14.1 Frame Relay Management 1165 The management of Frame Relay Bearer Service (FRBS) connections 1166 can be accomplished through two distinct methodologies: 1168 1. Based on ITU-T Q.933 Annex A, Link Integrity Verification 1169 procedure, where STATUS and STATUS ENQUIRY signaling messages are 1170 sent using DLCI=0 over a given UNI and NNI physical link. [ITU-T 1171 Q.933] 1173 2. Based on FRBS LMI, and similar to ATM ILMI where LMI is common 1174 in private Frame Relay networks. 1176 In addition, ITU-T I.620 addresses Frame Relay loopback, but the 1177 deployment of this standard is relatively limited. [ITU-T I.620] 1179 It is possible to use either, or both, of the above options to 1180 manage Frame Relay interfaces. This document will refer 1181 exclusively to Q.933 messages. 1183 The status of any provisioned Frame Relay PVC may be updated 1184 through: 1186 . STATUS messages in response to STATUS ENQUIRY messages, these 1187 are mandatory. 1189 . Optional unsolicited STATUS updates independent of STATUS 1190 ENQUIRY (typically under the control of management system, these 1191 updates can be sent periodically (continuous monitoring) or only 1192 upon detection of specific defects based on configuration. 1194 In Frame Relay, a DLC is either up or down. There is no 1195 distinction between different directions. TO achieve commonality 1196 with other technologies, ��down�� is represented as a forward 1197 defect. 1199 Frame relay connection management is not implemented over the PW 1200 using either of the techniques native to FR, therefore PW 1201 mechanisms are used to synchronize the view each PE has of the 1202 remote NS/AC. A PE will treat a remote NS/AC failure in the same 1203 way it would treat a PW or PSN failure, that is using AC facing FR 1204 connection management to notify the CE that FR is ��down��. 1206 14.2 ATM Management 1208 ATM management and OAM mechanisms are much more evolved than those 1209 of Frame Relay. There are five broad management-related 1210 categories, including fault management (FT), Performance 1211 management (PM), configuration management (CM), Accounting 1212 management (AC), and Security management (SM). ITU-T 1213 Recommendation I.610 describes the functions for the operation and 1214 maintenance of the physical layer and the ATM layer, that is, 1215 management at the bit and cell levels ([ITU-T I.610]). Because of 1216 its scope, this document will concentrate on ATM fault management 1217 functions. Fault management functions include the following: 1219 1) Alarm indication signal (AIS) 1220 2) Remote Defect indication (RDI). 1221 3) Continuity Check (CC). 1222 4) Loopback (LB) 1224 Some of the basic ATM fault management functions are described as 1225 follows: Alarm indication signal (AIS) sends a message in the same 1226 direction as that of the signal, to the effect that an error has 1227 been detected. 1229 Remote defect indication (RDI) sends a message to the transmitting 1230 terminal that an error has been detected. RDI is also referred to 1231 as the far-end reporting failure. Alarms related to the physical 1232 layer are indicated using path AIS/RDI. Virtual path AIS/RDI and 1233 virtual channel AIS/RDI are also generated for the ATM layer. 1235 OAM cells (F4 and F5 cells) are used to instrument virtual paths 1236 and virtual channels respectively with regard to their performance 1237 and availability. OAM cells in the F4 and F5 flows are used for 1238 monitoring a segment of the network and end-to-end monitoring. OAM 1239 cells in F4 flows have the same VPI as that of the connection 1240 being monitored. OAM cells in F5 flows have the same VPI and VCI 1241 as that of the connection being monitored. The AIS and RDI 1242 messages of the F4 and F5 flows are sent to the other network 1243 nodes via the VPC or the VCC to which the message refers. The type 1244 of error and its location can be indicated in the OAM cells. 1245 Continuity check is another fault management function. To check 1246 whether a VCC that has been idle for a period of time is still 1247 functioning, the network elements can send continuity-check cells 1248 along that VCC. 1250 14.3 Ethernet Management 1252 At this point in time, inband Ethernet OAM standards are being 1253 specified in the International Telecommunications Union - 1254 - 1255 Telecommunications (ITU-T) and the Institute of Electrical and 1256 Electronics Engineers (IEEE). However, it will take some time 1257 before they are widely deployed. Therefore, this document 1258 specifies only the procedures for mapping a defect due to a 1259 Ethernet physical layer fault. Defects on a remote Ethernet AC or 1260 defects in a PW cannot be mapped back to the local Ethernet 1261 network. 1263 15 Security Considerations 1265 The mapping messages described in this document do not change the 1266 security functions inherent in the actual messages. 1268 16 Acknowledgments 1270 Hari Rakotoranto, Eric Rosen, Mark Townsley, Michel Khouderchah, 1271 Bertrand Duvivier, Vanson Lim and Chris Metz Cisco Systems 1273 17 References 1275 [BFD] Katz, D., Ward, D., "Bidirectional Forwarding Detection", 1277 [CEP] Malis, A., et.al., "SONET/SDH Circuit Emulation over Packet 1278 (CEP)", Internet Draft , August 1279 2004 1281 [CONGESTION] Rosen, E., Bryant, S., Davie, B., "PWE3 Congestion 1282 Control Framework", Internet Draft , December 2004 1289 [FRF.19] Frame Relay Forum, ��Frame Relay Operations, 1290 Administration, and Maintenance Implementation Agreement��, 1291 March 2001. 1293 [ICMP] Postel, J. "Internet Control Message Protocol" RFC 792 1295 [ITU-T I.610] Recommendation I.610 "B-ISDN operation and 1296 maintenance principles and functions", February 1999 1298 [ITU-T I.620] Recommendation I.620 "Frame relay operation and 1299 maintenance principles and functions", October 1996 1301 [ITU-T Q.933] Recommendation Q.933 " ISDN Digital Subscriber 1302 Signalling System No. 1 (DSS1) � Signalling specifications 1303 for frame mode switched and permanent virtual connection 1304 control and status monitoring" February 2003 1306 [L2TPv3] Lau, J., et.al. " Layer Two Tunneling Protocol (Version 1307 3", Internet Draft , 1308 December 2004 1310 [LSPPING] Kompella, K., Pan, P., Sheth, N., Cooper, D., Swallow, 1311 G., Wadhwa, S., Bonica, R., " Detecting MPLS Data Plane 1312 Failures", Internet Draft < draft-ietf-mpls-lsp-ping-07.txt>, 1313 October 2004 1315 [MPLS-in-IP] Worster. T., et al., ��Encapsulating MPLS in IP or 1316 Generic Routing Encapsulation (GRE)��, draft-ietf-mpls-in-ip- 1317 or-gre-08.txt, June 2004. 1319 [OAM REQ] T. Nadeau et.al., "OAM Requirements for MPLS Networks", 1320 Internet Draft , 1321 December 2004 1323 [PWEARCH] Bryant, S., Pate, P., "PWE3 Architecture", Internet 1324 Draft, < draft-ietf-pwe3-arch-07.txt>, March 2004 1326 [PWEATM] Martini, L., et al., "Encapsulation Methods for Transport 1327 of ATM Cells/Frame Over IP and MPLS Networks", Internet Draft 1328 , Ocotber 2004 1330 [PWREQ] Xiao, X., McPherson, D., Pate, P., "Requirements for 1331 Pseudo Wire Emulation Edge to-Edge (PWE3)", RFC 3916, 1332 September 2004 1334 [RSVP-TE] Awduche, D., et.al. " RSVP-TE: Extensions to RSVP for 1335 LSP Tunnels", RFC 3209, December 2001 1337 [VCCV] Nadeau, T., et al."Pseudo Wire Virtual Circuit Connection 1338 Verification (VCCV)", Internet Draft , February 2005. 1341 18 Intellectual Property Disclaimer 1343 The IETF takes no position regarding the validity or scope of any 1344 intellectual property or other rights that might be claimed to 1345 pertain to the implementation or use of the technology described 1346 in this document or the extent to which any license under such 1347 rights might or might not be available; neither does it represent 1348 that it has made any effort to identify any such rights. 1349 Information on the IETF's procedures with respect to rights in 1350 standards-track and standards-related documentation can be found 1351 in BCP-11. Copies of claims of rights made available for 1352 publication and any assurances of licenses to be made available, 1353 or the result of an attempt made to obtain a general license or 1354 permission for the use of such proprietary rights by implementers 1355 or users of this specification can be obtained from the IETF 1356 Secretariat. 1358 The IETF invites any interested party to bring to its attention 1359 any copyrights, patents or patent applications, or other 1360 proprietary rights which may cover technology that may be required 1361 to practice this standard. Please address the information to the 1362 IETF Executive Director. 1364 19 Full Copyright Statement 1366 "Copyright (C) The Internet Society (2004). This document is 1367 subject to the rights, licenses and restrictions contained in BCP 1368 78, and except as set forth therein, the authors retain all their 1369 rights." 1371 "This document and the information contained herein are provided 1372 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1373 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 1374 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1375 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1376 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1377 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1378 PARTICULAR PURPOSE." 1380 20 Authors' Addresses 1382 Thomas D. Nadeau 1383 Cisco Systems, Inc. 1384 300 Beaverbrook Drive 1385 Boxborough, MA 01824 1386 Phone: +1-978-936-1470 1387 Email: tnadeau@cisco.com 1389 Monique Morrow 1390 Cisco Systems, Inc. 1391 Glatt-com 1392 CH-8301 Glattzentrum 1393 Switzerland 1394 Email: mmorrow@cisco.com 1396 Peter B. Busschbach 1397 Lucent Technologies 1398 67 Whippany Road 1399 Whippany, NJ, 07981 1400 Email: busschbach@lucent.com 1402 Mustapha Aissaoui 1403 Alcatel 1404 600 March Rd 1405 Kanata, ON, Canada. K2K 2E6 1406 Email: mustapha.aissaoui@alcatel.com 1408 Matthew Bocci 1409 Alcatel 1410 Voyager Place, Shoppenhangers Rd 1411 Maidenhead, Berks, UK SL6 2PJ 1412 Email: matthew.bocci@alcatel.co.uk 1413 David Watkinson 1414 Alcatel 1415 600 March Rd 1416 Kanata, ON, Canada. K2K 2E6 1417 Email: david.watkinson@alcatel.com 1419 Yuichi Ikejiri 1420 NTT Communications Corporation 1421 1-1-6, Uchisaiwai-cho, Chiyoda-ku 1422 Tokyo 100-8019, JAPAN 1423 Email: y.ikejiri@ntt.com 1425 Kenji Kumaki 1426 KDDI Corporation 1427 KDDI Bldg. 2-3-2 1428 Nishishinjuku, Shinjuku-ku 1429 Tokyo 163-8003,JAPAN 1430 E-mail : kekumaki@kddi.com 1432 Satoru Matsushima 1433 Japan Telecom 1434 JAPAN 1435 Email: satoru@ft.solteria.net 1437 David Allan 1438 Nortel Networks 1439 3500 Carling Ave., 1440 Ottawa, Ontario, CANADA 1441 Email: dallan@nortelnetworks.com 1443 Simon Delord 1444 France Telecom 1445 2 av, Pierre Marzin 1446 22300 LANNION, France 1447 E-mail: simon.delord@francetelecom.com