idnits 2.17.1 draft-zhl-mpls-tp-sd-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 26, 2009) is 5295 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: 'RFC5654' is defined on line 337, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group H. Zhang 2 Internet Draft J. He 3 Intended status: Standards Track Huawei 5 H. Li 6 China Mobile 7 October 26, 2009 8 Expires: April 2010 10 SD-Triggered Protection Switching in MPLS-TP 11 draft-zhl-mpls-tp-sd-01.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on April 26, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 In MPLS-TP survivability framework, a fault condition includes both 49 Signal Failure (SF) and Signal Degrade (SD) that can be used to trigger 50 protection switching. This document describes Signal Degrade (SD) 51 detection and the consequent protection switching mechanism. 53 Table of Contents 55 1. Introduction.................................................2 56 2. Terminology..................................................3 57 3. SD-Triggered Protection Switching............................4 58 3.1. General Operation.......................................4 59 3.1.1. General protection architecture....................4 60 3.1.2. APS Protocol.......................................4 61 3.2. SD-Triggered Protection Based on other Traffic (i.e. non 62 normal traffic)..............................................5 63 3.2.1. Detection of SD....................................5 64 3.2.2. Protection Switching and APS Protocol..............6 65 3.3. SD-Triggered Protection Based on Normal Traffic.........6 66 3.3.1. Broadcast Bridge with special APS request priority.6 67 3.3.2. Broadcast Bridge with extra protection switching 68 coordination..............................................7 69 4. Analysis.....................................................7 70 5. Security Considerations......................................7 71 6. IANA Considerations..........................................7 72 7. Acknowledgments..............................................8 73 8. References...................................................9 74 8.1. Normative References....................................9 75 8.2. Informative References..................................9 76 Author's Addresses..............................................9 78 1. Introduction 80 In packet transport network, protection switching can be triggered by 81 fault conditions and external manual commands. The fault conditions 82 include Signal Failure (SF) and Signal Degrade (SD). SF on a 83 transport entity can be detected by fault management OAM functions; 84 SD on a transport entity can be detected by performance monitoring 85 OAM functions. 87 The SD condition used for protection switching mostly depends on 88 packet loss ratio. For some services that are sensitive to time and 89 synchronization, the SD condition may depend on packet loss ratio, 90 packet delay and delay variation. 92 In MPLS-TP OAM tools, the packet loss measurement (LM) is used to 93 measure the amount of the lost service packets and compute the loss 94 ratio of service packet. The packet Delay Measurement (DM) is used to 95 measure the packet delay and delay variation by sending periodic DM 96 packets during the diagnostic interval. The LM and DM mechanisms are 97 out of scope of this document. 99 The detection of SD (e.g. packet loss) must be based on service 100 packets. But in some situation, there is no normal traffic on 101 working/protection transport entity, which makes the detection of SD 102 based on service packets impossible and causes switch flapping. 104 This document describes the mechanism for SD detection and consequent 105 protection switching in 1:1 and 1:n protection architecture. 107 2. Terminology 109 The reader is assumed to be familiar with the terminology in MPLS-TP. 110 The relationship between ITU-T and IETF terminologies on MPLS-TP can 111 be found in [Rosetta stone]. 113 MPLS-TP: MPLS Transport Profile 115 SF: Signal Failure 117 SF-W: SF for working entity 119 SF-P: SF for protection entity 121 SD: Signal Degrade 123 SD-W: SD for working entity 125 SD-P: SD for protection entity 127 APS: Automatic Protection Switching 129 OAM: Operations, Administration and Maintenance 131 CC/CV: Continuity Check/Connectivity Verification 133 LM: Loss Measurement 135 DM: Delay Measurement 137 3. SD-Triggered Protection Switching 139 3.1. General Operation 141 3.1.1. General protection architecture 143 In case of MPLS-TP 1+1 protection architecture, the normal traffic is 144 permanently sent on both working and protection entities by the 145 permanent bridge at the source. Therefore, the detection of SD or the 146 clearing of SD on both working and protection entities can be based 147 on the characteristics of the original traffic. 149 In case of MPLS-TP revertive 1:1 and 1:n protection architecture: 151 - If the protection switching is not active, normal traffic is 152 transported together with OAM on the working entity while on the 153 protection entity OAM is transported alone or together with the 154 possible extra traffic. 156 - If the protection switching is active, only OAM is transported on 157 the working entity. Normal traffic is transported on the 158 protection entity together with OAM. The extra traffic originally 159 transported on protection entity is disrupted. 161 In case of MPLS-TP non-revertive 1:1 and 1:n protection architecture: 163 - If the protection switching is not active, normal traffic is 164 transported together with OAM on the working entity while on the 165 protection entity OAM is transported alone or together with the 166 possible extra traffic. 168 - If the protection switching is active, OAM is transported alone or 169 possibly together with extra traffic on the working entity. Normal 170 traffic is transported on the protection entity together with OAM 171 traffic. That is, the normal traffic is switched from the working 172 entity to the protection entity and the extra traffic is switched 173 from the protection entity to the working entity. 175 As mentioned above, in case of 1:1 and 1:n protection architecture, 176 there may be no normal traffic on working/protection transport entity, 177 which makes the detection of SD impossible and consequently switch 178 flapping may happen. 180 3.1.2. APS Protocol 182 In APS request types, similar to the definition of SF-W (SF for 183 working entity) and SF-P (SF for protection entity), a definition of 184 SD-W (SD for working entity) and SD-P (SD for protection entity) is 185 required to prevent flapping. 187 3.2. SD-Triggered Protection Based on other Traffic (i.e. non normal 188 traffic) 190 3.2.1. Detection of SD 192 In case of 1:1 and 1:n protection architecture, for the transport 193 entity on which there is no normal traffic, the detection of SD can 194 be based on other service packets, e.g. 196 - Extra traffic 198 The extra traffic can be used instead of normal traffic in packet 199 loss measurement. That is, the performance monitoring OAM packets (LM) 200 will count the number of extra service packets and the loss 201 measurement is based on extra service, which will be used as the 202 input of SD condition of the transport entity that lacks normal 203 service. 205 - OAM packets for Test 207 The Test OAM packets can be used to simulate the characteristics of 208 the normal traffic and replace the normal service. With the 209 performance monitoring OAM packets (LM) the SD condition of the 210 transport entity can be detected. 212 - OAM packets for CC/CV 214 The CC/CV OAM packets can be used instead of normal service in packet 215 loss measurement. That is, the performance monitoring OAM packets (LM) 216 will count CC/CV packets and the loss measurement is based on CC/CV 217 packets, which will be used as the input of SD condition of the 218 transport entity where there is no normal service. 220 The above-mentioned SD-triggered protection switching mechanism based 221 on other traffic is general and flexible without constraint on the 222 bridge type by using the extra traffic, OAM packets (test or CC/CV). 224 However, the characteristics of the extra traffic are usually not the 225 same as that of the normal traffic so that the performance 226 measurement is not exactly reflecting the condition of real service. 227 OAM packets for CC/CV are sent in fixed transmission period (3.3ms, 228 10ms, 1s, etc.) which as well doesn't reflect the condition of real 229 services. It is applicable in places without strict requirement for 230 SD measurement. 232 The performance measurement by Test OAM packets is accurate. But the 233 usage of test packets on protection entity defeats the objective of 234 the 1:1 and 1:n architectures, which is to have the protection entity 235 bandwidth available for best effort traffic during the time there is 236 no fault or degradation of the working transport entity. The test 237 packets consume now this bandwidth. For the case of the 1:1 238 protection, this makes the bandwidth usage of this 1:1 architecture 239 similar to the bandwidth usage of the 1+1 architecture. 241 3.2.2. Protection Switching and APS Protocol 243 For the SD-triggered protection based on other traffic, if a 244 broadcast bridge is used, the other traffic used to detect SD is 245 required on the protection transport entity only. 247 The priority of SD-P and SD-W shall be fixed as SD-P > SD-W similar 248 to SF-P > SF-W. Therefore, a protection switching based on SD 249 detection shall not be initiated if there exists also an SD condition 250 on the protection transport entity. The priority of SD-P and SD-W can 251 be flexible as well based on the actual degraded degree of signal. 252 Therefore, traffic is sent on the transport entity with better SD 253 condition if both SD-W and SD-P exist. 255 3.3. SD-Triggered Protection Based on Normal Traffic 257 In case of 1:1 and 1:n protection architecture, a broadcast bridge 258 can be applied to assist SD detection in SD-triggered protection. 260 3.3.1. Broadcast Bridge with special APS request priority 262 In the normal state, the normal traffic is sent only on the working 263 transport entity and only the SD condition of the working transport 264 entity can be evaluated. 266 When SD is detected on the working transport entity, sink end sends 267 SD-W indication to the source end and the selector at the sink end 268 switches to the protection transport entity. The broadcast bridge at 269 the source end will then send the normal traffic on both working and 270 protection transport entities and the performance of both working and 271 protection transport entities can be monitored. 273 If SD is detected on protection transport entity as well, i.e. SD-W 274 and SD-P exist simultaneously, normal traffic is selected at the sink 275 still from the protection transport entity to avoid flapping between 276 protection and working states. 278 In this case the priority of SD-W and SD-P in the APS protocol is 279 fixed as SD-W > SD-P to avoid flapping of between protection and 280 working states. 282 3.3.2. Broadcast Bridge with extra protection switching coordination 284 The SD-W based protection switch action described in section 3.3.1 is 285 performed under the assumption that a SD condition on a transport 286 entity is a rare condition, and it is thus unlikely that SD on 287 protection will co-exist with SD on working. When such assumption is 288 not considered to be reasonable, the operation of the selector may be 289 modified as described hereafter. 291 When the sink end detects an SD condition, it does not switch to the 292 protection entity immediately. Instead, the broadcast bridge at the 293 source end will send the normal traffic on both working and 294 protection transport entity after receiving SD-W indication sent by 295 the sink end. Then sink end is able to detect the SD condition of 296 working and protection transport entity. 298 If SD is detected on the protection transport entity as well, the 299 normal traffic is sent to both working and protection transport 300 entities and is selected from the working transport entity; if no SD 301 is detected on the protection transport entity the normal traffic is 302 selected from the protection entity. 304 SD-triggered protection switching based normal traffic is simple and 305 efficient by applying a specific broadcast bridge but with a minor 306 modification to the priority order of APS request (i.e. SD-W > SD-P) 307 or to the operation order. 309 4. Analysis 311 In section 3.2 and 3.3, the different mechanisms are described. They 312 may be suitable in differenct application scenarios with different 313 requirements for simplicity, accuracy, flexibility. 315 [More analysis may be needed in a future version of this draft] 317 5. Security Considerations 319 To be added in a future version of the document. 321 6. IANA Considerations 323 No new IANA considerations. 325 7. Acknowledgments 327 To be added in a future version of the document. 329 8. References 331 8.1. Normative References 333 [MPLS-TP Framework] Bocci,M., and Bryant,S., "A Framework for MPLS in 334 Transport Networks", draft-ietf-mpls-tp-framework-06 (Work 335 in progress), October 2009 337 [RFC5654] Niven-Jenkins,B., Brungard,D., and Betts,M., "Requirements 338 of an MPLS Transport Profile", RFC5654, September 2009 340 [ITU-T Recommendation G.808.1] "Generic protection switching - Linear 341 trail and subnetwork protection", ITU-T G.808.1 (03/2006) 343 [MPLS-TP OAM Requirements] Vigoureux,M., Ward,D., and Betts,M., 344 "Requirements for OAM in MPLS Transport Networks", draft- 345 ietf-mpls-tp-oam-requirements-03(work in progress), August 346 2009 348 8.2. Informative References 350 [MPLS-TP Survive Frmk] Sprecher,N., and Farrel,a., "Multiprotocol 351 Label Switching Transport Profile Survivability Framework", 352 draft-ietf-mpls-tp-survive-fwk-00(work in progress), April 353 2009 355 Author's Addresses 357 Haiyan Zhang 358 Huawei Technologies Co., Ltd. 360 Phone: +86-755-28972333 361 Email: zhanghaiyan@huawei.com 363 Jia He 364 Huawei Technologies Co., Ltd. 366 Phone: +86-755-28972333 367 Email: hejia@huawei.com 369 Han Li 370 China Mobile Communications Corporation 372 Email: lihan@chinamobile.com