idnits 2.17.1 draft-rkhd-mpls-tp-sd-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 31, 2011) is 4714 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-mpls-tp-fault-04 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-tp-linear-protection-06 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group R. Ram 2 Internet Draft D. Cohn 3 Intended status: Informational Orckit-Corrigent 4 Expires: November 2011 5 M. Daikoku 6 KDDI 8 M. Yuxia 9 Y. Jian 10 ZTE Corp. 12 A. D'Alessandro 13 Telecom Italia 15 May 31, 2011 17 SD detection and protection triggering in MPLS-TP 18 draft-rkhd-mpls-tp-sd-03.txt 20 Abstract 22 This document describes guidelines for Signal Degrade (SD) fault 23 condition detection at an arbitrary transport path (LSP or PW) and 24 the usage of MPLS-TP fault management [3] for triggering protection 25 switching as defined in the MPLS-TP survivability framework [2]. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in 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 This Internet-Draft will expire in November 2011. 50 Copyright Notice 52 Copyright (c) 2011 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. 62 Table of Contents 64 1. Introduction ................................................ 3 65 2. Conventions used in this document ........................... 3 66 3. Signal Degrade and MPLS-TP protection switching ............. 4 67 4. SD detection method ......................................... 4 68 4.1. Guidelines for SD detection ............................ 4 69 4.2. Examples for SD detection methods ...................... 6 70 5. Transmission of link degradation fault indication ........... 6 71 5.1. Lower layer Bit Error transmission ..................... 7 72 6. Handling of link degradation fault indication ............... 7 73 7. Security Considerations ..................................... 7 74 8. IANA Considerations ......................................... 7 75 9. Acknowledgments ............................................. 7 76 10. References ................................................. 7 77 10.1. Normative References .................................. 7 78 10.2. Informative References ................................ 8 80 1. Introduction 82 Telecommunication carriers and network operators expect to replace 83 aged TDM Services (e.g. legacy VPN services) provided by legacy TDM 84 equipment by new VPN services provided by MPLS-TP equipment. 86 From a service level agreement (SLA) point of view, service quality 87 and availability degradation are not acceptable, even after migration 88 to MPLS-TP equipment. 90 In addition, from an operational point of view, comparable 91 performance monitoring features to those provided by TDM networks are 92 expected from MPLS-TP networks. For example, OAM maintenance points 93 should be the same after TDM to MPLS-TP migration, as SLA revision is 94 typically NOT feasible for telecommunication carriers and network 95 operators. 97 MPLS-TP transport path (i.e. LSP,PW) resiliency actions such as 98 protection switching can be triggered by fault conditions and 99 external manual commands. Fault conditions include Signal Failure 100 (SF) and Signal Degrade (SD). The SD condition could be detected at 101 an intermediate link, based on lower layer indications or other sub- 102 layer techniques. 104 Since the transport path protection switching is not necessarily 105 managed by the transport entity that detects the SD condition, an 106 indication of the link SD condition must be sent over the transport 107 paths that traverse the affected link. 109 This document describes guidelines for SD detection by lower layers 110 indication, and a mechanism for relaying the degraded transport path 111 condition to the network element handling the protection switching at 112 the appropriate transport path level. 114 2. Conventions used in this document 116 BER: Bit Error Rate 118 LSP: Label Switched Path 120 LSR: Label Switching Router 122 MEP: Maintenance End Point 123 MPLS: Multi-Protocol Label Switching 125 MPLS-TP: MPLS Transport Profile 127 OAM: Operations, Administration and Maintenance 129 OTN: Optical Transport Network 131 PCS: Physical Coding Sublayer 133 SF: Signal Failure 135 SD: Signal Degrade 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC 2119 [1]. 141 3. Signal Degrade and MPLS-TP protection switching 143 Network survivability, as defined in [2], is the ability of a 144 network to recover traffic delivery following failure or degradation 145 of network resources. [5] defines an LSP protection mechanism and 146 state machine that handles SF, SD and operator manual commands. 148 4. SD detection method 150 4.1. Guidelines for SD detection 152 Signal degrade is a transport path condition in which the expected 153 quality of transport service delivery is not provided. The signal 154 degrade condition can be used by operators to detect different types 155 of failures, especially those with slow externalization such as 156 optical device aging (e.g. photo detector and laser diode in line 157 amplifier, transponder or SFP), transmission medium external 158 impairment (e.g. temperature or pressure fluctuation, fiber 159 elongation), and time-variable optical impairments in fiber (e.g. 160 chromatic dispersion, polarization mode dispersion). 162 Signal degrade condition in a transport path is derived from bit 163 error detection in the traversed links. 165 Bit errors in a link are caused by the following phenomena: 167 1. Physical conditions such as bad electrical connections, low 168 received optical power, dispersion effects. 170 2. Non-physical conditions such as network congestion, CPU overload, 171 selective packet discard, packet processing error. 173 The common basis for the guidelines set forth in this section is that 174 the SD condition SHOULD reflect only physical error conditions in the 175 traversed links, without any influence from non-physical conditions. 177 The following conditions SHOULD be met by the signal degrade 178 condition detection mechanism: 180 o Method for determining signal degrade MUST NOT affect the services 181 transmitted over the transport path (e.g. add delay or jitter to 182 real-time traffic) 184 o Criterion for determining signal degrade MUST be agnostic to the 185 length of transmitted frames 187 o Criterion for determining signal degrade MUST be agnostic to the 188 transmission rate of transmitted frames 190 o Criterion for determining signal degrade MUST be agnostic to the 191 type of service carried by the transmitted frames 193 o Criterion for determining signal degrade MUST be agnostic to the 194 traffic class of transmitted frames 196 o Criterion for determining signal degrade MUST be agnostic to drop- 197 precedence marking of transmitted frames 199 o Criterion for determining signal degrade MUST be agnostic to 200 congestion 202 o Criterion for determining signal degrade SHOULD be able to detect 203 low error levels (e.g. BER of 10E-8) 205 o Criterion for determining signal degrade SHOULD have low 206 misdetection probability 208 o Criterion for determining signal degrade SHOULD have low false 209 alarm probability 211 o Criterion for determining signal degrade SHOULD be agnostic to 212 number of transport paths (LSPs and PWs) transported over the 213 transmission link 215 o Signal degrade conditions MUST be monitored by the lowest server 216 layer or sub-layer that is not terminated between monitoring 217 points 219 o Method for determining signal degrade SHOULD NOT require 220 transmission of additional packets 222 o Method for determining signal degrade SHOULD allow to localize 223 links that contribute to signal degrade 225 o Method for determining signal degrade MUST be able to exit signal 226 degrade condition when error rate returns to normal condition 228 o Method for determining signal degrade condition MUST be scalable 230 4.2. Examples for SD detection methods 232 o A Server MEP [4] related to SONET or SDH sub-layers can determine 233 SD condition based on error indication from parity information in 234 the path overhead. 236 o A Server MEP related to OTN sub-layer can determine SD condition 237 based on error indications from Forward-Error-Correction 238 functionality inherent in encapsulation. 240 o A Server MEP related to 10GE PCS sub-layer can determine SD 241 condition based on rate of errored 66-bit block headers. (a.k.a. 242 symbol errors) 244 o A Server MEP related to 1GE PCS sub-layer can determine SD 245 condition based on rate of 10-bit code violations dispersion 246 errors. 248 As specified in section 4.1, these examples assume that the layer 249 carrying the information used for SD detection is not terminated by 250 non-MPLS-TP-LSR entities (e.g. media converter). 252 5. Transmission of link degradation fault indication 254 When SD condition is detected, a link degradation fault indication 255 [3] SHOULD be transmitted over affected transport paths, in the 256 downstream direction from the detection point. The link degradation 257 indication will be transmitted immediately following the detection 258 and periodically until the SD condition is removed. The messages will 259 be terminated and handled by the downstream client MEP. 261 The encapsulation and mechanism defined in [3] is suitable for 262 transmission of link degradation fault indication. It is RECOMMENDED 263 that [3] will include this definition in future work. 265 5.1. Lower layer Bit Error transmission 267 There are scenarios where the lower layer bit error rate in each of 268 the links traversed by the transport path is below the SD threshold, 269 while the accumulated end-to-end BER on the LSP is above the 270 threshold. This is possible in lower layer technologies where errored 271 information is dropped, so errors in one link will not be detected by 272 LSRs downstream of this link. An example of such a situation is when 273 an LSP is carried over multiple Ethernet links, and each link drops 274 errored Ethernet frames. 276 To enable SD detection in such scenarios, LSRs MAY optionally include 277 the measured BER in the link degradation fault indication message. 278 The client MEP may then receive multiple link degradation fault 279 indication messages from different LSRs. When this occurs, the client 280 MEP SHOULD compare the sum of the received BER values with the SD 281 threshold to decide on the LSP SD condition. 283 6. Handling of link degradation fault indication 285 LSR behavior upon receiving link degradation fault indication is out 286 of the scope of this document. 288 SD condition processing and prioritization for protection triggering 289 is out of the scope of this document. 291 SD clear condition processing and prioritization for protection 292 triggering is out of the scope of this document. 294 7. Security Considerations 296 To be added in a future version of the document. 298 8. IANA Considerations 300 302 9. Acknowledgments 304 The editors gratefully acknowledge the contributions of Amir Halperin 305 and Shachar Katz. 307 10. References 309 10.1. Normative References 311 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 312 Levels", BCP 14, RFC 2119, March 1997. 314 10.2. Informative References 316 [2] Sprecher,N., and Farrel,A., "Multiprotocol Label Switching 317 Transport Profile Survivability Framework", draft-ietf-mpls-tp- 318 survive-fwk-06(work in progress), June 2010 320 [3] Swallow,G., Fulignoli,A., Vigoureux,M., Boutros,S., and 321 Ward,D., "MPLS Fault Management OAM", draft-ietf-mpls-tp- 322 fault-04 (work in progress), April 2011 324 [4] Busi,I. and Allan,D., "MPLS-TP OAM Framework", draft-ietf-mpls- 325 tp-oam-framework-11 (work in progress), February 2011 327 [5] Bryant,S., Osborne,E., Weingarten,Y., Sprecher,N., 328 Fulignoli,A., "MPLS-TP Linear Protection", draft-ietf-mpls-tp- 329 linear-protection-06 (work in progress), March 2011 331 This document was prepared using 2-Word-v2.0.template.dot. 333 Authors' Addresses 335 Rafi Ram 336 Orckit-Corrigent 337 126 Yigal Alon St. 338 Tel Aviv 339 Israel 341 Email: rafir@orckit.com 343 Daniel Cohn 344 Orckit-Corrigent 345 126 Yigal Alon St. 346 Tel Aviv 347 Israel 349 Email: danielc@orckit.com 351 Masahiro Daikoku 352 KDDI 353 3-10-10, Iidabashi, Chiyoda-ku, 354 Tokyo 355 Japan 357 Email: ms-daikoku@kddi.com 359 Ma Yuxia 360 ZTE Corp. 361 China 363 Email: ma.yuxia@zte.com.cn 365 Yang Jian 366 ZTE Corp. 367 China 369 Email: yang.jian90@zte.com.cn 371 Alessandro D'Alessandro 372 Telecom Italia 373 Italy 375 Email: alessandro.dalessandro@telecomitalia.it 377 Contributors 379 Amir Halperin 381 Shachar Katz