idnits 2.17.1 draft-ietf-pwe3-oam-msg-map-06.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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1486. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1452. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1459. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1465. 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 -- 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 (March 2008) is 5879 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) == Unused Reference: 'ITU-T Q.933' is defined on line 1315, 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) == Outdated reference: A later version (-16) exists of draft-ietf-pwe3-oam-msg-map-06 -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Thomas D. Nadeau, Ed. 2 Internet Draft Monique Morrow, Ed. 3 Proposed Status: Standards Track Cisco Systems, Inc. 4 Expiration Date: September 2008 5 Peter Busschbach, Ed. 6 Mustapha Aissaoui, Ed. 7 Alcatel-Lucent 9 Dave Allan, Ed. 10 Nortel Networks 12 March 2008 14 Pseudo Wire (PW) OAM Message Mapping 15 draft-ietf-pwe3-oam-msg-map-06.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that other 26 groups may also distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 This document specifies the mapping of defect states between a 46 Pseudo Wire and the Attachment Circuits (AC) of the end-to-end 47 emulated service. This document covers the case whereby the ACs 48 and the PWs are of the same type in accordance to the PWE3 49 architecture [RFC3985] such that a homogenous PW service can be 50 constructed. 52 draft-ietf-pwe3-oam-msg-map-06 August 2008 54 Table of Contents 56 1 Introduction .................................................2 57 2 Terminology...................................................5 58 3 Reference Model and Defect Locations..........................6 59 4 Abstract Defect States........................................7 60 5 PW Status and Defects.........................................8 61 6 PW Defect State Entry/Exit...................................16 62 7 AC Defect States.............................................17 63 8 PW Forward Defect Entry/Exit procedures......................19 64 9 AC Defect Entry/Exit Procedures..............................22 65 10 SONET Encapsulation (CEP)...................................24 66 11 TDM Encapsulation...........................................24 67 12 Appendix A: Native Service Management.......................26 68 13 Security Considerations.....................................27 69 14 Acknowledgments.............................................28 70 15 IANA Considerations ........................................28 71 16 References..................................................28 72 17 Authors' Addresses..........................................30 73 18 Intellectual Property Statement ............................31 75 1. Introduction 77 This document specifies the mapping of defect states between a 78 Pseudo Wire and the Attachment Circuits (AC) of the end-to-end 79 emulated service. This document covers the case whereby the ACs 80 and the PWs are of the same type in accordance to the PWE3 81 architecture [RFC3985] such that a homogenous PW service can be 82 constructed. This document is motivated by the requirements put 83 forth in [RFC4377] and [RFC3916]. 85 Ideally only PW and AC defects need be propagated into the Native 86 Service (NS), and NS OAM mechanisms are transported transparently 87 over the PW. Some homogenous scenarios use PW specific OAM 88 mechanisms to synchronize defect state between PEs due to 89 discontinuities in native service OAM between the AC and the PW 90 (e.g. FR LMI). 92 The objective of this document is to standardize the behavior of 93 PEs with respects to failures on PWs and ACs, so that there is no 94 ambiguity about the alarms generated and consequent actions 95 undertaken by PEs in response to specific failure conditions. 97 This document covers PWE over MPLS PSN, PWE over IP PSN and PWE 98 over L2TP PSN. 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 101 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 102 in this document are to be interpreted as described in RFC 2119. 104 draft-ietf-pwe3-oam-msg-map-06 August 2008 106 2. Terminology 108 AIS Alarm Indication Signal 109 AC Attachment circuit 110 BDI Backward Defect Indication 111 CC Continuity Check 112 CE Customer Edge 113 CPCS Common Part Convergence Sublayer 114 DLC Data Link Connection 115 FDI Forward Defect Indication 116 FRBS Frame Relay Bearer Service 117 IWF Interworking Function 118 LB Loopback 119 NE Network Element 120 NS Native Service 121 OAM Operations and Maintenance 122 PE Provider Edge 123 PW Pseudowire 124 PSN Packet Switched Network 125 RDI Remote Defect Indication 126 SDU Service Data Unit 127 VCC Virtual Channel Connection 128 VPC Virtual Path Connection 130 The rest of this document will follow the following conventions: 132 The PW can ride over three types of Packet Switched Network (PSN). 133 A PSN which makes use of LSPs as the tunneling technology to 134 forward the PW packets will be referred to as an MPLS PSN. A PSN 135 which makes use of MPLS-in-IP tunneling [RFC4023], with an MPLS 136 shim header used as PW demultiplexer, will be referred to as an 137 MPLS-IP PSN. A PSN, which makes use of L2TPv3 [RFC3931] as the 138 tunneling technology, will be referred to as L2TP-IP PSN. 140 If LSP-Ping [RFC4379] is run over a PW as described in [RFC4377], 141 it will be referred to as VCCV-Ping. 143 If BFD is run over a PW as described in [RFC4377], it will be 144 referred to as VCCV-BFD. 146 In the context of this document a PE forwards packets between an 147 AC and a PW. The other PE that terminates the PW is the peer PE 148 and the attachment circuit associated with the far end PW 149 termination is the remote AC. 151 Defects are discussed in the context of defect states, and the 152 criteria to enter and exit the defect state. 154 The direction of defects is discussed from the perspective of 155 draft-ietf-pwe3-oam-msg-map-06 August 2008 157 the observing PE and what the PE may explicitly know about 158 information transfer capabilities of the PW service. 160 A forward defect is one that impacts information transfer to 161 the observing PE. It impacts the observing PEs ability to 162 receive information. A forward defect MAY also imply impact 163 on information sent or relayed by the observer (and as it 164 cannot receive is therefore unknowable) and so the forward 165 defect state is considered to be a superset of the two 166 defect states. 168 A reverse defect is one that uniquely impacts information sent or 169 relayed by observer. 171 3. Reference Model and Defect Locations 173 Figure 1 illustrates the PWE3 network reference model with an 174 indication of the possible defect locations. This model will be 175 referenced in the remainder of this document for describing the 176 OAM procedures. 178 ACs PSN tunnel ACs 179 +----+ +----+ 180 +----+ | PE1|==================| PE2| +----+ 181 | |---(a)---(b)..(c)......PW1..(d)..(c)..(f)---(e)---| | 182 | CE1| (N1) | | | | (N2) |CE2 | 183 | |----------|............PW2.............|----------| | 184 +----+ | |==================| | +----+ 185 ^ +----+ +----+ ^ 186 | Provider Edge 1 Provider Edge 2 | 187 | | 188 |<-------------- Emulated Service ---------------->| 190 Customer Customer 191 Edge 1 Edge 2 192 Figure 1: PWE3 Network Defect Locations 193 In all interworking scenarios described in this document, it is 194 assumed that at PE1 the AC and the PW are of the same type. The 195 procedures described in this document exclusively apply to PE1. 196 PE2 for a homogenous service implements the identical 197 functionality (although it is not required to as long as the 198 notifications across the PWs are consistent). 200 The following is a brief description of the defect locations: 202 (a) Defect in the first L2 network (N1). This covers any defect 203 in the N1 which impacts all or a subset of ACs terminating in 204 PE1. The defect is conveyed to PE1 and to the remote L2 205 network (N2) using the native service specific OAM defect 206 draft-ietf-pwe3-oam-msg-map-06 August 2008 208 indication. 209 (b) Defect on a PE1 AC interface. 210 (c) Defect on a PE PSN interface. 211 (d) Defect in the PSN network. This covers any defect in the PSN 212 which impacts all or a subset of the PSN tunnels and PWs 213 terminating in a PE. The defect is conveyed to the PE using a 214 PSN and/or a PW specific OAM defect indication. Note that 215 control plane, i.e., signaling and routing, messages do not 216 necessarily follow the path of the user plane messages. 217 Defect in the control plane are detected and conveyed 218 separately through control plane mechanisms. However, in some 219 cases, they have an impact on the status of the PW as 220 explained in the next section. 221 (e) Defect in the second L2 network (N2). This covers any defect 222 in N2 which impacts all or a subset of ACs terminating in PE2 223 (which is considered a remote AC defect in the context of 224 procedures outlined in this draft). The defect is conveyed to 225 PE2 and to the remote L2 network (N1) using the native 226 service OAM defect indication. 227 (f) Defect on a PE2 AC interface (which is also considered a 228 remote AC defect in the context of this draft). 230 4. Abstract Defect States 232 PE1 is obliged to track four abstract defect states that reflect 233 the observed state of both directions of the PW service on both 234 the AC and the PW sides. Faults may impact only one or both 235 directions of the PW. 237 The observed state is a combination of faults directly detected by 238 PE1, or faults it has been made aware of via notifications. 240 +-----+ 241 ----AC forward---->| |-----PW reverse----> 242 CE1 | PE1 | PE2/CE2 243 <---AC reverse-----| |<----PW forward----- 244 +-----+ 246 (arrows indicate direction of user traffic impacted by a defect) 247 Figure 2: Forward and Reverse Defect States and Notifications 248 PE1 will directly detect or be notified of AC forward and PW 249 forward defects as they occur upstream of PE1 and impact traffic 250 being sent to PE1. 251 In Figure 2, PE1 may be notified of a forward defect in the AC by 252 receiving a Forward Defect indication, e.g., ATM AIS, from CE1. 253 This defect impacts the ability of PE1 to receive user traffic 254 from CE1 on the AC. PE1 can also directly detect this defect if it 255 resulted from a failure of the receive side in the local port or 256 link over which the AC is configured. 257 Similarly, PE1 may detect or be notified of a forward defect in 258 draft-ietf-pwe3-oam-msg-map-06 August 2008 260 the PW by receiving a Forward Defect indication from PE2. This 261 notification can either be a Local PSN-facing PW (egress) 262 Transmit Fault or a Local Attachment Circuit (ingress) Receive 263 Fault. This defect impacts the ability of PE1 to receive user 264 traffic from CE2. 265 Note that the AC or PW Forward Defect notification is sent in the 266 same direction as the user traffic impacted by the defect. 268 PE1 will only be notified of AC reverse and PW reverse defects as 269 they universally will be detected by other devices and only impact 270 traffic that has already been relayed by PE1. In Figure 2, PE1 may 271 be notified of a reverse defect in the AC by receiving a Reverse 272 Defect indication, e.g., ATM RDI, from CE1. This defect impacts 273 the ability of PE1 to send user traffic to CE1 on the AC. 274 Similarly, PE1 may be notified of a reverse defect in the PW by 275 receiving a Reverse Defect indication from PE2. This notification 276 can either be a Local PSN-facing PW (ingress) Receive Fault or a 277 Local Attachment Circuit (egress) Transmit Fault. This defect 278 impacts the ability of PE1 to send user traffic to CE2. 279 Note that the AC or PW Reverse Defect notification is sent in the 280 reverse direction to the user traffic impacted by the defect. 282 The procedures outlined in this document define the entry and exit 283 criteria for each of the four states with respect to the set of 284 potential ACs and PWs within the document scope and the consequent 285 actions that PE1 must perform to properly interwork those 286 notifications. The abstract defect states used by PE1 are common 287 to all potential interworking combinations of PWs and ACs. 289 When a PE has multiple sources of notifications from a peer (e.g. 290 PSN control plane, LDP control plane, BFD), it is obliged to track 291 all sources, but with respect to consequent actions the forward 292 state ALWAYS has precedence over the reverse state. 294 5. PW Status and Defects 296 This section describes possible PW defects, ways to detect them 297 and consequent actions. 299 5.1 PW Defects 301 Possible defects that impact PWs are the following. 303 - Physical layer defect in the PSN interface 305 - PSN tunnel failure which results in a loss of connectivity 306 between ingress and egress PE. 308 - Control session failures between ingress and egress PE 309 draft-ietf-pwe3-oam-msg-map-06 August 2008 311 In case of an MPLS PSN and an MPLS-IP PSN there are additional 312 defects: 314 - PW labeling error, which is due to a defect in the ingress PE, 315 or to an over-writing of the PW label value somewhere along the 316 LSP path. 318 - LSP tunnel Label swapping errors or LSP tunnel label merging 319 errors in the MPLS network. This could result in the termination 320 of a PW at the wrong egress PE. 322 - Unintended self-replication; e.g., due to loops or denial-of- 323 service attacks. 325 5.1.1 Packet Loss 327 Persistent congestion in the PSN or in a PE could impact the 328 proper operation of the emulated service. 330 A PE can detect packet loss resulting from congestion through 331 several methods. If a PE uses the sequence number field in the 332 PWE3 Control Word for a specific Pseudo Wire [RFC3985], it has the 333 ability to detect packet loss. Translation of congestion detection 334 ato PW defect states is outside the scope of this specification. 336 Generally, there are congestion alarms which are raised in the 337 node and to the management system when congestion occurs. The 338 decision to declare the PW Down and to select another path is 339 usually at the discretion of the network operator. 341 5.2 Defect Detection and Notification 343 5.2.1 Defect Detection Tools 345 To detect the defects listed in 7.1, Service Providers have a 346 variety of options available: 348 Physical Layer defect detection and notification mechanisms such 349 as SONET/SDH LOS, LOF,and AIS/FERF. 351 PSN Defect Detection Mechanisms: 353 For PWE3 over an L2TP-IP PSN, with L2TP as encapsulation protocol, 354 the defect detection mechanisms described in [RFC3931] apply. 355 Furthermore, the tools Ping and Traceroute, based on ICMP Echo 356 Messages apply [RFC792]. 358 For PWE3 over an MPLS PSN and an MPLS-IP PSN, several tools can be 359 used. 361 draft-ietf-pwe3-oam-msg-map-06 August 2008 363 - LSP-Ping and LSP-Traceroute( [RFC4379]) for LSP tunnel 364 connectivity verification. 366 - LSP-Ping with Bi-directional Forwarding Detection ([BFD]) for 367 LSP tunnel continuity checking. 369 - Furthermore, if RSVP-TE is used to setup the PSN Tunnels between 370 ingress and egress PE, the hello protocol can be used to detect 371 loss of connectivity [RFC3209], but only at the control 372 plane. 374 PW specific defect detection mechanisms: 376 [RFC4377] describes how LSP-Ping and BFD can be used over 377 individual PWs for connectivity verification and continuity 378 checking respectively. When used as such, we will refer to them 379 as VCCV-Ping and VCCV-BFD respectively. 381 Furthermore, the detection of a fault could occur at different 382 points in the network and there are several ways the observing PE 383 determines a fault exists: 385 a. egress PE detection of failure (e.g. BFD) 386 b. ingress PE detection of failure (e.g. LSP-PING) 387 c. ingress PE notification of failure (e.g. RSVP Path-err) 389 5.2.2 Defect Detection Mechanism Applicability 391 The discussion below is intended to give some perspective how 392 tools mentioned in the previous section can be used to detect 393 failures. 395 Observations: 397 - Tools like LSP-Ping and BFD can be run periodically or on 398 demand. If used for defect detection, as opposed to diagnostic 399 usage, they must be run periodically. 401 Control protocol failure indications, e.g. detected through L2TP 402 Keep-alive messages or the RSVP-TE Hello messages, can be used to 404 detect many network failures. However, control protocol failures 405 do not necessarily coincide with data plane failures. Therefore, 406 a defect detection mechanism in the data plane is required to 407 protect against all potential data plane failures. Furthermore, 408 fault diagnosis mechanisms for data plane failures are required 409 to further analyze detected failures. 411 - For PWE3 over an MPLS PSN and an MPLS-IP PSN, it is effective to 412 run a defect detection mechanism over a PSN Tunnel frequently and 413 draft-ietf-pwe3-oam-msg-map-06 August 2008 415 run one over every individual PW within that PSN Tunnel less 416 frequently. However in case the PSN traffic is distributed over 417 Equal Cost Multi Paths (ECMP), it may be difficult to guarantee 418 that PSN OAM messages follow the same path as a specific PW. A 419 Service Provider might therefore decide to focus on defect 420 detection over PWs. 422 - In MPLS networks, execution of LSP Ping would detect MPLS label 423 errors, since it requests the receiving node to match the label 424 with the original FEC that was used in the LSP set up. BFD can 425 also be used since it relies on discriminators. A label error 426 would result in a mismatch between the expected discriminator and 427 the actual discriminator in the BFD control messages. 429 - For PWE3 over an MPLS PSN and an MPLS-IP PSN, PEs could detect 430 PSN label errors through the execution of LSP-Ping. However, use 431 of VCCV is preferred as it is a more accurate detection tool for 432 pseudowires. 434 Furthermore, it can be run using a BFD mode, i.e., VCCV-BFD, 435 which allows it to be used as a light-weight detection mechanism 436 for PWs. If, due to a label error in the PSN, a PW would be 437 terminated on the wrong egress PE, PEs would detect this through 438 the execution of VCCV. LSP ping and/or LSP trace could then be 439 used to diagnose the detected failure. 441 Based on these observations, it is clear that a service provider 442 has the disposal of a variety of tools. There are many factors 443 that influence which combination of tools best meets its needs. 445 5.3 Overview of fault notifications 447 For a MPLS PSN and a IP PSN using MPLS-in-IP [RFC4023], a 448 PW that are established and maintained using LDP SHOULD use 449 LDP status signaling messages as the default mechanism 450 for AC, PW status and defect notification [RFC4447]. If 451 a combination of VCCV+BFD [RFC4377] status and LDP status are 452 used, LDP status MUST take precidence over VCCV-BFD status 453 as as outlined below in Section 5.3.4. For PWs established 454 using other means such as static configuration, inband signaling 455 using VCCV-BFD [RFC5085] SHOULD be used to convey AC and PW 456 status. 458 For a IP PSN using L2TPv3, i.e., a L2TP-IP PSN, StopCCN and CDN 459 messages are used for conveying defects in the PSN and PW 460 respectively, while the Set-Link-Info (SLI) messages are used to 461 convey status and defects in the AC and local L2 network. 463 5.3.1 Use of Native Service notifications 464 draft-ietf-pwe3-oam-msg-map-06 August 2008 466 In the context of this document, ATM and unstructured SONET/TDM 467 PWs are the only examples of a PW that has native service 468 notification capability. Frame relay does have the FR OAM 469 specification [FRF.19], but this is not commonly deployed. All 470 other PWs use PW specific notification mechanisms. 472 ATM PWs may optionally also use PW specific notification 473 mechanisms. 475 In normal, i.e., defect-free, operation, all the types of ATM OAM 476 cells described in Section 12.2 are either terminated at the PE, 477 for OAM segments terminating in the AC endpoint, or transparently 478 carried over the PSN tunnel [RFC4714]. This is referred to as 479 inband ATM OAM over PW and is the default method. 481 An optional out-of band method based on relaying the ATM defect 482 state over a PW specific defect indication mechanism is provided 483 for PEs which cannot generate and/or transmit ATM OAM cells over 484 the ATM PW. This is referred to as Out-of-band ATM OAM over PW. 486 Ethernet OAm is not covered in this specification. 488 5.3.2 The Use of PW Status for MPLS and MPLS-IP PSNs 490 For a MPLS PSN and a IP PSN using MPLS-in-IP [RFC4023], a 491 PW that are established and maintained using LDP SHOULD use 492 LDP status signaling messages as the default mechanism 493 for AC, PW status and defect notification [RFC4447]. If 494 a combination of VCCV+BFD [RFC4377] status and LDP status are 495 used, LDP status MUST take precidence over VCCV-BFD status 496 as as outlined below in Section 5.3.4. For PWs established 497 using other means such as static configuration, inband signaling 498 using VCCV-BFD [RFC4377] SHOULD be used to convey AC and PW 499 status. 501 [RFC4446] defines the following valid PW status codepoints. 502 [RFC4447] specifies that Pseudo Wire forwarding is used to 503 clear all faults and that Pseudo Wire Not Forwarding is used to 504 convey any other defects that cannot be represented by the other 505 codepoints. The remaining codepoints map to the forward defect 506 and reverse defect defined in this document as follows: 508 Forward defect - corresponds to the logical OR of 509 Local Attachment Circuit (ingress) 510 Receive Fault and Local PSN-facing 511 PW (egress) Transmit Fault 513 Reverse defect - corresponds to the logical OR of 514 Local Attachment Circuit (egress) 515 Transmit Fault and Local PSN-facing 517 draft-ietf-pwe3-oam-msg-map-06 August 2008 519 PW (ingress) Receive Fault 521 PW status is used to convey the defect view of the PW local to the 522 originating PE. This is the local PW state. This state is conveyed 523 in the form of a forward defect or a reverse defect. 525 Thus PW status (when available) shall be used to report the 526 following failures: 528 - Failures detected through defect detection mechanisms in the 529 MPLS and MPLS-IP PSN 531 - Failures detected through VCCV-Ping 533 - Failures within the PE that result in an inability to forward 534 traffic between ACs and PW 536 - State of the AC when the PE does not have native service OAM 537 capability or emulation of native service OAM capability is 538 prohibitive. This state is conveyed in the form of a forward 539 defect or a reverse defect. 541 Note that there are a couple of situations which require PW label 542 withdrawal as opposed to a PW status notification by the PE. The 543 first one is when the PW is taken administratively down in 544 accordance to [RFC4447]. The second one is when the Target 545 LDP session established between the two PEs is lost. In the 546 latter case, the PW labels will need to be re-signaled when the 547 Targeted LDP session is re-established. 549 5.3.3 The Use of L2TP STOPCCN and CDN 551 [RFC3931] describes the use of STOPCCN and CDN messages to exchange 552 alarm information between PEs. A StopCCN message indicates that 553 the control connection has been shut down by the remote PE 554 [RFC3931]. This is typically used for defects in the PSN which 555 impact both the control connection and the individual data plane 556 sessions. On reception of this message, a PE closes the control 557 connection and will clear all the sessions managed by this control 558 connection. Since each session carries a single PW, the state of 559 the corresponding PWs is changed to DOWN. A CDN message indicates 560 that the remote peer requests the disconnection of a specific 561 session [RFC3931]. In this case only the state of the corresponding 562 PW is changed to DOWN. This is typically used for local defects in 563 a PE which impact only a specific session and the corresponding 564 PW. 566 Like PW Status, STOPCCN and CDN messages shall be used to report 567 the following failures: 569 draft-ietf-pwe3-oam-msg-map-06 August 2008 571 - Failures detected through defect detection mechanisms in the 572 L2TP-IP PSN 574 - Failures detected through VCCV-Ping 576 - Failures within the PE that result in an inability to forward 577 traffic between ACs and PW 579 In L2TP, the Set-Link-Info (SLI) message is used to convey 580 failures on the ACs. 582 5.3.4 The Use of BFD Diagnostic Codes 584 [BFD] defines a set of diagnostic codes that partially overlap 585 with failures that can be communicated through PW Status messages 586 or L2TP STOPCCN and CDN messages. This section describes the 587 behavior of the PE nodes with respect to using one or both methods 588 for detecting and propagating defect state. 590 For a MPLS-PSN, the PEs negotiate the use of the VCCV 591 capabilities when the label mapping messages are exchanged to 592 establish the two directions of the PW. An OAM capability TLV 593 is signaled as part of the PW FEC interface parameters TLV. 595 The CV Type Indicators field in this TLV defines a bitmask used 596 to indicate the specific OAM capabilities that the PE can make 597 use of over the PW being established. A CV type of 0x04 indicates 598 that BFD is used for PW fault detection only. 600 In this mode, only two of the diagnostics codes specified in [BFD] 601 will be used: They are: 603 0 - No diagnostic: 604 1 - Control detection time expired 605 7 - Administratively Down 607 The first code indicates that the peer PE is correcty receiving 608 BFD control messages. The second code indicates that the peer has 609 stopped receiving BFD control messages. A PE shall use 610 "Administrative down" to bring down the BFD session when the PW is 611 brought down administratively. All other defects - such as AC 612 defects and PE internal failures that prevent it from forwarding 613 traffic - must be communicated through PW Status messages, in 614 the case of MPLS PSN or MPLS-IP PSN, or the appropriate L2TP 615 codes in the case of L2TP-IP PSN, as defined in 5.3.2 and 5.3.3. 617 A CV type of 0x08 in the OAM capabilities TLS indicates that BFD 618 is used for both PW fault detection and AC/PW Fault Notification. 619 In this case, all defects - including AC defects and PE internal 620 failures - are signaled through BFD. 622 draft-ietf-pwe3-oam-msg-map-06 August 2008 624 6. PW Defect State Entry/Exit 626 6.1 PW Forward Defect Entry/Exit 628 A PE will enter the PW forward defect state if one of the 629 following occurs 631 - It detects loss of connectivity on the PSN tunnel over which the 632 PW is riding. This includes label swapping errors and label 633 merging errors. 635 - It receives a message from PE2 indicating PW forward defect or 636 PW not forwarding, which indicates PE2 detected or was notified 637 of a PW fault downstream of it or that there was a remote AC 638 fault. 640 - It detects a loss of PW connectivity, including label errors, 641 through VCCV-BFD or VCCV-PING in no reply mode. 643 Note that if the PW control session between the PEs fails, the PW 644 is torn down and needs to be re-established. However, the 645 consequent actions towards the ACs are the same as if the PW 646 entered the forward defect state. 648 PE1 will exit the forward defect state if the PW status 649 received from PE2 has the forward defect indication cleared, 650 and it has established that PW/PSN connectivity is working 651 in the forward direction. Note that this may result in a 652 transition to the PW operational or PW reverse defect states. 654 For a PWE3 over a L2TP-IP PSN, a PE will exit the PW forward 655 defect state when the following conditions are true: 657 - All defects it had previously detected have disappeared, and 659 - A L2TPv3 session is successfully established to carry the PW 660 packets. 662 6.2 PW reverse defect state entry/exit 664 A PE will enter the PW reverse defect state if 665 it receives a message from PE2 indicating PW reverse defect 666 which indicates PE2 detected or was notified of a PW/PSN fault 667 upstream of it or that there was a remote AC fault and it is not 668 already in the PW forward defect state. 670 PE1 will exit the reverse defect state if the PW status 671 received from PE2 contains the reverse defect indication 672 draft-ietf-pwe3-oam-msg-map-06 August 2008 674 cleared, or it has entered the PW forward defect state. 676 For a PWE3 over a L2TP-IP PSN, the PW reverse defect state is not 677 valid and a PE can only enter the PW forward defect state. 679 6.2.1 PW reverse defects that require PE state synchronization 681 Some PW mechanisms will result in PW defects being detected by or 682 notified to PE1 when PE1 is upstream of the fault but the 683 notification did not originate with PE2. The resultant actions are 684 identical to that of entering the PW reverse defect state with the 685 addition that PE1 needs to synchronize state with PE2 and the PW 686 state communicated from PE1 to PE2 needs to indicate state 687 accordingly. 689 When the PSN uses RSVP-TE or proactively uses LSP-PING as a PW 690 fault detection mechanism, PE1 must enter to the PW reverse defect 691 state. 693 The exit criteria being when, the RSVP fault state or the LSP-PING 694 fault state exit criteria has been met, indicating no PW reverse 695 defects. 697 7 AC Defect States 699 7.1 FR ACs 700 PE1 enters the AC Forward Defect state if any of the following 701 conditions are met: 702 (i) A PVC is not deleted from the Frame Relay network and 703 the Frame Relay network explicitly indicates in a full 704 status report (and optionally by the asynchronous status 705 message) that this Frame Relay PVC is inactive. In this 706 case, this status maps across the PE to the corresponding 707 PW only. 708 (ii) The LIV indicates that the link from the PE to the Frame 709 Relay network is down. In this case, the link down 710 indication maps across the PE to all corresponding PWs. 711 (iii) A physical layer alarm is detected on the FR interface. In 712 this case, this status maps across the PE to all 713 corresponding PWs. 714 A PE exits the AC Forward Defect state when all defects it had 715 previously detected have disappeared. 717 The AC reverse defect state is not valid for FR ACs. 719 7.2 ATM ACs 721 7.2.1 AC Forward Defect State Entry/Exit 723 PE1 enters the AC forward defect state if any of the following 724 draft-ietf-pwe3-oam-msg-map-06 August 2008 726 conditions are met: 728 (i) It detects or is notified of a physical layer fault on the 729 ATM interface and/or it terminates an F4 AIS flow or has 730 loss of F4 CC for a VP carrying VCCs. 732 (ii) It terminates an F4 AIS OAM flow, in the case of a VPC, 733 or an F5 AIS OAM flow, in the case of a VCC, indicating 734 that the ATM VPC or VCC is down in the adjacent L2 ATM 735 network (e.g., N1 for PE1). This is applicable to the 736 case of the out-of-band ATM OAM over PW method only. 738 (iii) It detects loss of connectivity on the NS ATM VPC/VCC 739 while terminating ATM continuity checking (ATM CC) with 740 the local ATM network and CE. 742 A PE exits the AC Forward Defect state when all defects it had 743 previously detected have disappeared. The exact conditions under 744 which a PE exits the AIS state, or declares that connectivity is 745 restored via ATM CC are defined in I.610 [I.610]. 747 7.2.2 AC Reverse Defect State Entry/Exit 749 A PE enters the AC reverse defect state if any of the following 750 conditions are met: 751 (i) It terminates an F4 RDI OAM flow, in the case of a 752 VPC, or an F5 RDI OAM flow, in the case of a VCC, 753 indicating that the ATM VPC or VCC is down in the 754 adjacent L2 ATM network (e.g., N1 for PE1). This is 755 applicable to the case of the out-of-band ATM OAM over 756 PW method only. 758 A PE exits the AC Reverse Defect state if the AC state transitions 759 to working or to the AC forward defect state. The criteria for 760 exiting the RDI state are described in I.610. 762 7.3 Ethernet AC State 764 PE1 enters the forward defect state if any of the following 765 conditions are met: 767 (i) A physical layer alarm is detected on the Ethernet 768 interface. 770 A PE exits the Ethernet AC forward defect state when all defects 771 it had previously detected have disappeared. 773 8. PW Forward Defect Entry/Exit procedures 775 8.1 PW Forward Defect Entry Procedures 776 draft-ietf-pwe3-oam-msg-map-06 August 2008 778 8.1.1 FR AC procedures 780 These procedures are applicable only if the transition from the 781 working state to the PW Forward defect state. A transition from PW 782 reverse defect state to the forward defect state does not require 783 any additional notification procedures to the FR AC as it has 784 already been told the peer is down. 785 (i) PE1 MUST generate a full status report with the Active bit 786 = 0 (and optionally in the asynchronous status message), 787 as per Q.933 annex A, into N1 for the corresponding FR 788 ACs. 790 8.1.2 Ethernet AC Procedures 792 No procedures are currently defined. 794 8.1.3 ATM AC procedures 796 The following text refers to AIS, RDI and CC without specifying 797 whether it it is an F4 (VP-level) flow or an F5 (VC-level) 798 flow, or whether it is an end-to-end or a segment flow. 799 Precise ATM OAM procedures are specified elsewhere (e.g. I.610) 800 and such references complement the descriptions below. 802 Note that it is a network operator option to support segment 803 OAM and to identify and provision PEs as segment end points. 805 On entry to the PW Forward Defect State 807 (i) PE1 MUST commence AIS insertion into the corresponding 808 AC. 810 (ii) PE1 MUST terminate any CC generation on the 811 corresponding AC. 813 8.1.4 Additional procedures for a FR PW, an ATM PW in the 814 out-of-band ATM OAM over PW method, and an Ethernet PW 816 If the PW failure was explicitly detected by PE1, it MUST assume 817 PE2 has no knowledge of the defect and MUST notify PE2 in the form 818 of a reverse defect notification: 820 For PW over MPLS PSN or MPLS-IP PSN 821 (i) A PW Status message indicating a reverse defect, or 822 (ii) A VCCV-BFD diagnostic code if the optional use of VCCV-BFD 823 notification has been negotiated 825 For PW over L2TP-IP PSN 826 draft-ietf-pwe3-oam-msg-map-06 August 2008 828 (i) An L2TP Set-Link Info (LSI) message with a Circuit Status 829 AVP indicating "active" Or, 830 (ii) A VCCV-BFD diagnostic code if the optional use of VCCV-BFD 831 notification has been negotiated 833 Otherwise the entry to the defect state was the result of a 834 notification from PE2 (indicating that PE2 already had knowledge 835 of the fault) or loss of the control adjacency (similarly visible 836 to PE2). 838 8.2 PW Forward Defect Exit Procedures 840 8.2.1 FR AC procedures 842 On transition from the PW forward defect state to the reverse 843 defect state PE1 takes no action w.r.t. the AC. 844 On exit from the PW Forward defect state 845 (i) PE1 MUST generate a full status report with the Active bit 846 = 1 (and optionally in the asynchronous status message), 847 as per Q.933 annex A, into N1 for the corresponding FR 848 ACs. 850 8.2.2 Ethernet AC Procedures 852 No procedures are currently defined 854 8.2.3 ATM AC procedures 856 On exit from the PW Forward Defect State 858 (i) PE1 MUST cease AIS insertion into the corresponding AC. 860 (ii) PE1 MUST resume any CC generation on the corresponding 861 AC. 863 8.2.4 Additional procedures for a FR PW, an ATM PW in the 864 out-of-band ATM OAM over PW method, and an Ethernet PW 866 If the PW failure was explicitly detected by PE1, it MUST notify 867 PE2 in the form of clearing the reverse defect notification: 869 For PW over MPLS PSN or MPLS-IP PSN 871 (i) A PW Status message with the reverse defect indication 872 clear, and the remaining indicators showing either working 873 or a transition to the forward defect state. Or, 875 (ii) A VCCV-BFD diagnostic code with the same attribute as (i) 876 if the optional use of VCCV-BFD notification has been 877 negotiated 878 draft-ietf-pwe3-oam-msg-map-06 August 2008 880 For PW over L2TP-IP PSN 882 (i) An L2TP Set-Link Info (LSI) message with a Circuit Status 883 AVP indicating "active" Or, 885 (ii) A VCCV-BFD diagnostic code with the same attributes as (i) 886 if the optional use of VCCV-BFD notification has been 887 negotiated 889 8.3 PW Reverse Defect Entry Procedures 891 8.3.1 FR AC procedures 893 On transition from the PW forward defect state to the reverse 894 defect state PE1 takes no action w.r.t. the AC. 896 On entry to the PW reverse defect state 898 (i) PE1 MUST generate a full status report with the Active bit 899 = 0 (and optionally in the asynchronous status message), 900 as per Q.933 annex A, into N1 for the corresponding FR 901 ACs. 903 8.3.2 Ethernet AC Procedures 905 No procedures are currently defined 907 8.3.3 ATM AC procedures 909 On entry to the PW Reverse Defect State 910 (i) PE1 MUST commence RDI insertion into the corresponding 911 AC. This applies to the case of an ATM PW in the out-of- 912 band ATM OAM over PW method only. 914 8.4 PW Reverse Defect Exit Procedures 916 8.4.1 FR AC procedures 918 On transition from the PW reverse defect state to the PW forward 919 defect state PE1 takes no action with respect to the AC. 921 On exit from the PW Reverse defect state 922 (i) PE1 MUST generate a full status report with the Active bit 923 = 1 (and optionally in the asynchronous status message), 924 as per Q.933 annex A, into N1 for the corresponding FR 925 ACs. 927 8.4.2 Ethernet AC Procedures 928 draft-ietf-pwe3-oam-msg-map-06 August 2008 930 No procedures are currently defined 932 8.4.3 ATM AC procedures 934 On exit from the PW Reverse Defect State 935 (i) PE1 MUST cease RDI insertion into the corresponding AC. 936 This applies to the case of an ATM PW in the out-of-band ATM OAM 937 over PW method only. 939 8.5 Procedures in FR Port Mode 941 In case of pure port mode, STATUS ENQUIRY and STATUS messages are 942 transported transparently over the PW. A PW Failure will therefore 943 result in timeouts of the Q.933 link and PVC management protocol 944 at the Frame Relay devices at one or both sites of the emulated 945 interface. 947 8.6 Procedures in ATM Port Mode 949 In case of transparent cell transport, i.e., "port mode", where 950 the PE does not keep track of the status of individual ATM VPCs or 951 VCCs, a PE cannot relay PW defect state over these VCCs and VPCs. 952 If ATM CC is run on the VCCs and VPCs end-to-end (CE1 to CE2), or 953 on a segment originating and terminating in the ATM network and 954 spanning the PSN network, it will timeout and cause the CE or ATM 955 switch to enter the ATM AIS state. 957 9 AC Defect Entry/Exit Procedures 959 9.1 AC Forward defect entry: 961 On entry to the forward defect state, PE1 may need to perform 962 procedures on both the PW and the AC. 964 9.1.1 Procedures for a FR PW, an ATM PW in the out-of-band ATM OAM 965 over PW method, or an Ethernet PW 966 On entry to the AC forward defect state, PE1 notifies PE2 of a 967 forward defect: 969 For PW over MPLS PSN or MPLS-IP PSN 970 (i) A PW Status message indicating forward defect, or 971 (ii) A VCCV-BFD diagnostic code of forward defect if the 972 optional use of VCCV-BFD notification has been negotiated. 974 For PW over L2TP-IP PSN 975 (i) An L2TP Set-Link Info (LSI) message with a Circuit Status 976 AVP indicating "inactive", or 977 (ii) A VCCV-BFD diagnostic code of forward defect if the 978 optional use of VCCV-BFD notification has been negotiated. 980 draft-ietf-pwe3-oam-msg-map-06 August 2008 982 9.1.2 Procedures for a ATM PW in the inband ATM OAM over PW 983 method 985 On entry to the AC forward defect state, PE1 MUST: 986 a. Commence insertion of ATM AIS cells into the corresponding 987 PW. 988 b. If PE1 is originating F4 or F5 I.610 CC cells, PE1 will 989 suspend CC generation for the duration of the defect 990 state. 992 9.1.3 Additional procedures for ATM ACs 994 On entry to the AC forward defect state PE1 will commence RDI 995 insertion into the AC as per I.610. This procedure is applicable 996 to the out-of-band ATM OAM over PW method only. 998 9.2 AC Reverse defect entry 1000 9.2.1 Procedures for a FR PW, an ATM PW in the out-of-band ATM OAM 1001 over PW method, or an Ethernet PW 1003 On entry to the AC reverse defect state, PE1 notifies PE2 of a 1004 reverse defect: 1006 For PW over MPLS PSN or MPLS-IP PSN 1007 (iii) A PW Status message indicating reverse defect,or 1009 (iv) A VCCV-BFD diagnostic code of reverse defect if the 1010 optional use of VCCV-BFD notification has been negotiated. 1012 For PW over L2TP-IP PSN 1013 (iii) An L2TP Set-Link Info (LSI) message with a Circuit Status 1014 AVP indicating "inactive", or 1015 (iv) A VCCV-BFD diagnostic code of reverse defect if the 1016 optional use of VCCV-BFD notification has been negotiated. 1018 9.2.2 Procedures for a ATM PW in the inband ATM OAM over PW 1019 method 1021 There are no procedures in this case as the AC reverse defect 1022 state is not valid for PE1 operating in this method. 1024 9.3 AC Forward Defect Exit 1026 9.3.1 Procedures for a FR PW, an ATM PW in the out-of-band ATM OAM 1027 over PW method, or an Ethernet PW 1029 On exit from the AC forward defect state PE1 notifies PE2 that the 1030 draft-ietf-pwe3-oam-msg-map-06 August 2008 1032 forward defect state has cleared (note that this may be a direct 1033 state transition to either the working state or the reverse defect 1034 state): 1036 For PW over MPLS PSN or MPLS-IP PSN 1037 (i) A PW Status message with forward defect clear and the 1038 remaining indicators showing either working or reverse 1039 defect state, or 1041 (ii) A VCCV-BFD diagnostic code with the same attributes as (i) 1042 if the optional use of VCCV-BFD notification has been 1043 negotiated. 1045 For PW over L2TP-IP PSN 1046 (i) An L2TP Set-Link Info (LSI) message with a Circuit Status 1047 AVP indicating "active", or 1048 (ii) A VCCV-BFD diagnostic code with the same attributes as (i) 1049 if the optional use of VCCV-BFD notification has been 1050 negotiated. 1052 9.3.2 Procedures for a ATM PW in the inband ATM OAM over PW 1053 method 1055 On exit from the AC forward defect state, PE1 MUST: 1056 (i) Cease insertion of ATM AIS cells into the corresponding 1057 PW. 1058 (ii) If PE1 is originating F4 or F5 I.610 CC cells, PE1 will 1059 resume CC generation for the duration of the defect state. 1061 9.3.3 Additional procedures for ATM ACs 1063 On exit from the AC forward defect state PE1 will cease RDI 1064 insertion into the AC as per I.610. This procedure is applicable 1065 to the out-of-band ATM OAM over PW method only. 1067 9.4 AC Reverse Defect Exit 1069 9.4.1 Procedures for a FR PW, an ATM PW in the out-of-band ATM OAM 1070 over PW method, or an Ethernet PW 1072 On exit from the AC reverse defect state, PE1 notifies PE2 that 1073 the reverse defect state has cleared (note that this may be a 1074 direct state transition to either the working state or the forward 1075 defect state): 1077 For PW over MPLS PSN or MPLS-IP PSN 1078 (i) A PW Status message with the reverse defect indicator 1079 cleared and the remaining indicators showing either 1080 working or a transition to the forward defect state, or 1081 (ii) A VCCV-BFD diagnostic code with the same information as 1082 draft-ietf-pwe3-oam-msg-map-06 August 2008 1084 (i) if the optional use of VCCV-BFD notification has been 1085 negotiated. 1087 For PW over L2TP-IP PSN 1088 (i) An L2TP Set-Link Info (LSI) message with a Circuit Status 1089 AVP indicating "active", or 1091 (ii) A VCCV-BFD diagnostic code with the same information as 1093 (iii) if the optional use of VCCV-BFD notification has been 1094 negotiated. 1096 9.4.2 Procedures for a ATM PW in the inband ATM OAM over PW 1097 method 1099 There are no procedures in this case as the AC reverse defect 1100 state is not valid for PE1 operating in this method. 1102 10 SONET Encapsulation (CEP) 1104 Loss of Connectivity and other SONET/SDH protocol failures on 1105 the PW are translated to alarms on the ACs and vice versa. 1106 In essence, all defect management procedures are 1107 handled entirely in the emulated protocol. There is no need for an 1108 interaction between PW defect management and SONET layer defect 1109 management. 1111 11 TDM Encapsulation 1113 From an OAM perspective, the PSN carrying a TDM PW provides the 1114 same function as that of SONET/SDH or ATM network carrying the 1115 same low-rate TDM stream. Hence the interworking of defect OAM is 1116 similar. 1118 For structure-agnostic TDM PWs, the TDM stream is to be carried 1119 transparently across the PSN, and this requires TDM OAM 1120 indications to be transparently transferred along with the TDM 1121 data. For structure-aware TDM PWs the TDM structure alignment is 1122 terminated at ingress to the PSN and regenerated at egress, and 1123 hence OAM indications may need to be signaled by special means. In 1124 both cases generation of the appropriate emulated OAM indication 1125 may be required when the PSN is at fault. 1127 Since TDM is a real-time signal, defect indications and 1128 performance measurements may be classified into two classes, 1129 urgent and deferrable. Urgent messages are those whose contents 1130 may not be significantly delayed with respect to the TDM data that 1131 they potentially impact, while deferrable messages may arrive at 1132 the far end delayed with respect to simultaneously generated TDM 1133 data. For example, a forward indication signifying that the TDM 1134 draft-ietf-pwe3-oam-msg-map-06 August 2008 1136 data is invalid (e.g. TDM loss of signal, or MPLS loss of packets) 1137 is only of use when received before the TDM data is to be played 1138 out towards the far end TDM system. It is hence classified as an 1139 urgent message, and we can not delegate its signaling to a 1140 separate maintenance or management flow. On the other hand, the 1141 forward loss of multiframe synchronization, and most reverse 1142 indications do not need to be acted upon before a particular TDM 1143 frame is played out. 1145 From the above discussion it is evident that the complete solution 1146 to OAM for TDM PWs needs to have at least two, and perhaps three 1147 components. The required functionality is transparent transfer of 1148 native TDM OAM and urgent transfer of indications (by flags) along 1149 with the impacted packets. Optionally there may be mapping between 1150 TDM and PSN OAM flows. 1152 TDM AIS generated in the TDM network due to a fault in that 1153 network is generally carried unaltered, although the TDM 1154 encapsulations allow for its suppression for bandwidth 1155 conservation purposes. Similarly, when the TDM loss of signal is 1156 detected at the PE, it will generally emulate TDM AIS. 1158 SAToP and the two structure-aware TDM encapsulations have 1159 converged on a common set of defect indication flags in the PW 1160 control word. When the PE detects or is informed of lack of 1161 validity of the TDM signal, it raises the local ("L") defect flag, 1162 uniquely identifying the defect as originating in the TDM network. 1163 The remote PE must ensure that TDM AIS is delivered to the remote 1164 TDM network. When the defect lies in the MPLS network, the remote 1165 PE fails to receive packets. The remote PE generates TDM AIS 1166 towards its TDM network, and in addition raises the remote defect 1167 ("R") flag in its PSN-bound packets, uniquely identifying the 1168 defect as originating in the PSN. Finally, defects in the remote 1169 TDM network that cause RDI generation in that network, may 1170 optionally be indicated by proper setting of the field of valid 1171 packets in the opposite direction. 1173 12 Appendix A: Native Service Management 1175 12.1 Frame Relay Management 1177 The management of Frame Relay Bearer Service (FRBS) connections 1178 can be accomplished through two distinct methodologies: 1180 1. Based on ITU-T Q.933 Annex A, Link Integrity Verification 1181 procedure, where STATUS and STATUS ENQUIRY signaling messages are 1182 sent using DLCI=0 over a given UNI and NNI physical link. [ITU-T 1183 Q.933] 1185 2. Based on FRBS LMI, and similar to ATM ILMI where LMI is common 1186 draft-ietf-pwe3-oam-msg-map-06 August 2008 1188 in private Frame Relay networks. 1190 In addition, ITU-T I.620 addresses Frame Relay loopback, but the 1191 deployment of this standard is relatively limited. [ITU-T I.620] 1193 It is possible to use either, or both, of the above options to 1194 manage Frame Relay interfaces. This document will refer 1195 exclusively to Q.933 messages. 1197 The status of any provisioned Frame Relay PVC may be updated 1198 through: 1200 - STATUS messages in response to STATUS ENQUIRY messages, these 1201 are mandatory. 1203 - Optional unsolicited STATUS updates independent of STATUS 1204 ENQUIRY (typically under the control of management system, these 1205 updates can be sent periodically (continuous monitoring) or only 1206 upon detection of specific defects based on configuration. 1208 In Frame Relay, a DLC is either up or down. There is no 1209 distinction between different directions. TO achieve commonality 1210 with other technologies, down is represented as a forward 1211 defect. 1213 Frame relay connection management is not implemented over the PW 1214 using either of the techniques native to FR, therefore PW 1215 mechanisms are used to synchronize the view each PE has of the 1216 remote NS/AC. A PE will treat a remote NS/AC failure in the same 1217 way it would treat a PW or PSN failure, that is using AC facing FR 1218 connection management to notify the CE that FR is down. 1220 12.2 ATM Management 1222 ATM management and OAM mechanisms are much more evolved than those 1223 of Frame Relay. There are five broad management-related 1224 categories, including fault management (FT), Performance 1225 management (PM), configuration management (CM), Accounting 1226 management (AC), and Security management (SM). ITU-T 1227 Recommendation I.610 describes the functions for the operation and 1228 maintenance of the physical layer and the ATM layer, that is, 1229 management at the bit and cell levels ([ITU-T I.610]). Because of 1230 its scope, this document will concentrate on ATM fault management 1231 functions. Fault management functions include the following: 1233 1) Alarm indication signal (AIS) 1234 2) Remote Defect indication (RDI). 1235 3) Continuity Check (CC). 1236 4) Loopback (LB) 1237 draft-ietf-pwe3-oam-msg-map-06 August 2008 1239 Some of the basic ATM fault management functions are described as 1240 follows: Alarm indication signal (AIS) sends a message in the same 1241 direction as that of the signal, to the effect that an error has 1242 been detected. 1244 Remote defect indication (RDI) sends a message to the transmitting 1245 terminal that an error has been detected. RDI is also referred to 1246 as the far-end reporting failure. Alarms related to the physical 1247 layer are indicated using path AIS/RDI. Virtual path AIS/RDI and 1248 virtual channel AIS/RDI are also generated for the ATM layer. 1250 OAM cells (F4 and F5 cells) are used to instrument virtual paths 1251 and virtual channels respectively with regard to their performance 1252 and availability. OAM cells in the F4 and F5 flows are used for 1253 monitoring a segment of the network and end-to-end monitoring. OAM 1254 cells in F4 flows have the same VPI as that of the connection 1255 being monitored. OAM cells in F5 flows have the same VPI and VCI 1256 as that of the connection being monitored. The AIS and RDI 1257 messages of the F4 and F5 flows are sent to the other network 1258 nodes via the VPC or the VCC to which the message refers. The type 1259 of error and its location can be indicated in the OAM cells. 1260 Continuity check is another fault management function. To check 1261 whether a VCC that has been idle for a period of time is still 1262 functioning, the network elements can send continuity-check cells 1263 along that VCC. 1265 12.3 Ethernet Management 1267 At this point in time, inband Ethernet OAM standards are being 1268 specified in the International Telecommunications Union 1269 Telecommunications (ITU-T) and the Institute of Electrical and 1270 Electronics Engineers (IEEE). However, it will take some time 1271 before they are widely deployed. Therefore, this document 1272 specifies only the procedures for mapping a defect due to a 1273 Ethernet physical layer fault. Defects on a remote Ethernet AC or 1274 defects in a PW cannot be mapped back to the local Ethernet 1275 network. 1277 13. Security Considerations 1279 The mapping messages described in this document do not change the 1280 security functions inherent in the actual messages. 1282 14. Acknowledgments 1284 Hari Rakotoranto, Eric Rosen, Mark Townsley, Michel Khouderchah, 1285 Bertrand Duvivier, Vanson Lim, Chris Metz, Ben Washam, Tiberiu 1286 Grigoriu. 1288 draft-ietf-pwe3-oam-msg-map-06 August 2008 1290 15. IANA Considerations 1292 None at this time. 1294 16. References 1296 16.1 Normative References 1298 [BFD] Katz, D., Ward, D., "Bidirectional Forwarding Detection", 1299 Internet Draft 1300 July 2008 1302 [FRF.19] Frame Relay Forum, Frame Relay Operations, 1303 Administration, and Maintenance Implementation Agreement, 1304 March 2001. 1306 [RFC792] Postel, J. "Internet Control Message Protocol", 1307 RFC792 1309 [ITU-T I.610] Recommendation I.610 "B-ISDN operation and 1310 maintenance principles and functions", February 1999 1312 [ITU-T I.620] Recommendation I.620 "Frame relay operation and 1313 maintenance principles and functions", October 1996 1315 [ITU-T Q.933] Recommendation Q.933 " ISDN Digital Subscriber 1316 Signalling System No. 1 (DSS1) Signalling specifications 1317 for frame mode switched and permanent virtual connection 1318 control and status monitoring" February 2003 1320 [RFC3931] Lau, J., et.al. " Layer Two Tunneling Protocol (Version 1321 3", RFC 3931, March 2005 1323 [RFC4379] Kompella, K., Pan, P., Sheth, N., Cooper, D., Swallow, 1324 G., Wadhwa, S., Bonica, R., " Detecting MPLS Data Plane 1325 Failures", RFC4379, February 2006. 1327 [RFC4023] Worster. T., et al., Encapsulating MPLS in IP or 1328 Generic Routing Encapsulation (GRE), RFC 4023, 1329 March 2005. 1331 [RFC5085] Nadeau, T., et al."Pseudo Wire Virtual Circuit Connection 1332 Verification (VCCV)", RFC 5085 December 2007. 1334 16.2 Informative References 1336 [RFC3985] Bryant, S., "Pseudo Wire Emulation Edge-to-Edge (PWE3) 1337 draft-ietf-pwe3-oam-msg-map-06 August 2008 1339 Architecture", RFC 3985, March 2005. 1341 [RFC4377] Nadeau, T. et.al., "OAM Requirements for MPLS Networks", 1342 RFC4377, February 2006. 1344 [RFC4447] Martini, L., Rosen, E., Smith, T., "Pseudowire 1345 Setup and Maintenance using LDP", RFC4447, April 2006. 1347 [RFC4446] Martini, L., et al., "IANA Allocations for pseudo 1348 Wire Edge to Edge Emulation (PWE3)", RFC4446, 1349 April 2006. 1351 [RFC4714] Martini, L., et al., "Encapsulation Methods for Transport 1352 of ATM Cells/Frame Over IP and MPLS Networks", RFC4717, 1353 December 2006 1355 [RFC3916] Xiao, X., McPherson, D., Pate, P., "Requirements for 1356 Pseudo Wire Emulation Edge to-Edge (PWE3)", RFC 3916, 1357 September 2004 1359 [RFC3209] Awduche, D., et.al. "RSVP-TE: Extensions to RSVP for 1360 LSP Tunnels", RFC 3209, December 2001 1362 17. Authors' Addresses 1364 Thomas D. Nadeau (editor) 1365 BT 1366 BT Centre 1367 81 Newgate Street 1368 London EC1A 7AJ 1369 United Kingdom 1370 Email: thomas.nadeau@bt.com 1372 Monique Morrow 1373 Cisco Systems, Inc. 1374 Glatt-com 1375 CH-8301 Glattzentrum 1376 Switzerland 1377 Email: mmorrow@cisco.com 1379 Peter B. Busschbach 1380 Alcatel-Lucent 1381 67 Whippany Road 1382 Whippany, NJ, 07981 1383 Email: busschbach@alcatel-lucent.com 1385 Mustapha Aissaoui 1386 Alcatel-Lucent 1387 draft-ietf-pwe3-oam-msg-map-06 August 2008 1389 600 March Rd 1390 Kanata, ON, Canada. K2K 2E6 1391 Email: mustapha.aissaoui@alcatel-lucent.com 1393 Matthew Bocci 1394 Alcatel- Lucent 1395 Voyager Place, Shoppenhangers Rd 1396 Maidenhead, Berks, UK SL6 2PJ 1397 Email: matthew.bocci@alcatel.co.uk 1399 David Watkinson 1400 Alcatel-Lucent 1401 600 March Rd 1402 Kanata, ON, Canada. K2K 2E6 1403 Email: david.watkinson@alcatel-lucent.com 1405 Yuichi Ikejiri 1406 NTT Communications Corporation 1407 1-1-6, Uchisaiwai-cho, Chiyoda-ku 1408 Tokyo 100-8019, JAPAN 1409 Email: y.ikejiri@ntt.com 1411 Kenji Kumaki 1412 KDDI Corporation 1413 KDDI Bldg. 2-3-2 1414 Nishishinjuku, Shinjuku-ku 1415 Tokyo 163-8003,JAPAN 1416 E-mail : kekumaki@kddi.com 1418 Satoru Matsushima 1419 Japan Telecom 1420 JAPAN 1421 Email: satoru@ft.solteria.net 1423 David Allan 1424 Nortel Networks 1425 3500 Carling Ave., 1426 Ottawa, Ontario, CANADA 1427 Email: dallan@nortelnetworks.com 1429 Simon Delord 1430 Uecomm 1431 8/658 Church St 1432 Richmond VIC 3121 1433 Australia 1434 Email: sdelord@uecomm.com.au 1436 Vasile Radoaca 1437 Alcatel-Lucent 1438 Shanghai, China 1439 draft-ietf-pwe3-oam-msg-map-06 August 2008 1441 Email: vasile.radoaca@alcatel-lucent.com 1443 18. Intellectual Property Statement 1445 The IETF takes no position regarding the validity or scope of any 1446 Intellectual Property Rights or other rights that might be claimed to 1447 pertain to the implementation or use of the technology described in 1448 this document or the extent to which any license under such rights 1449 might or might not be available; nor does it represent that it has 1450 made any independent effort to identify any such rights. Information 1451 on the procedures with respect to rights in RFC documents can be 1452 found in BCP 78 and BCP 79. 1454 Copies of IPR disclosures made to the IETF Secretariat and any 1455 assurances of licenses to be made available, or the result of an 1456 attempt made to obtain a general license or permission for the use of 1457 such proprietary rights by implementers or users of this 1458 specification can be obtained from the IETF on-line IPR repository at 1459 http://www.ietf.org/ipr. 1461 The IETF invites any interested party to bring to its attention any 1462 copyrights, patents or patent applications, or other proprietary 1463 rights that may cover technology that may be required to implement 1464 this standard. Please address the information to the IETF at ietf- 1465 ipr@ietf.org. 1467 Full Copyright Statement 1469 Copyright (C) The IETF Trust (2008). 1471 Full Copyright Statement 1473 Copyright (C) The IETF Trust (2008). 1475 This document is subject to the rights, licenses and restrictions 1476 contained in BCP 78, and except as set forth therein, the authors 1477 retain all their rights. 1479 This document and the information contained herein are provided on 1480 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1481 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1482 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1483 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1484 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1485 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1486 FOR A PARTICULAR PURPOSE. 1488 draft-ietf-pwe3-oam-msg-map-06 August 2008 1490 Acknowledgment 1492 Funding for the RFC Editor function is currently provided by the 1493 Internet Society.