idnits 2.17.1 draft-zhl-mpls-tp-sd-02.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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 72 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 (March 8, 2010) is 5162 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 370, but no explicit reference was found in the text Summary: 1 error (**), 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 March 8, 2010 8 Expires: September 2010 10 SD-Triggered Protection Switching in MPLS-TP 11 draft-zhl-mpls-tp-sd-02.txt 13 Abstract 15 In MPLS-TP survivability framework, a fault condition includes both 16 Signal Failure (SF) and Signal Degrade (SD) that can be used to 17 trigger protection switching. This document describes Signal Degrade 18 (SD) detection and the consequent protection switching mechanism. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 This Internet-Draft will expire on April 8, 2010. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with 52 respect to this document. 54 Table of Contents 56 1. Introduction.....................................................2 57 2. Terminology......................................................3 58 3. SD-Triggered Protection Switching Architecture...................4 59 4. SD-Triggered Protection Solution Analysis........................4 60 4.1. SD-Triggered Protection Based on OAM packets................5 61 4.1.1. Detection of SD........................................5 62 4.1.2. APS Protocol...........................................5 63 4.2. Broadcast Bridge with Special APS Request Priority..........6 64 4.2.1. Protection Switching...................................6 65 4.2.2. APS Protocol...........................................7 66 4.3. Broadcast Bridge with Extra Protection Switching Coordination 67 ................................................................7 68 4.3.1. Protection Switching...................................8 69 4.3.2. APS Protocol...........................................8 70 4.4. Analysis....................................................8 71 5. Security Considerations..........................................8 72 6. IANA Considerations..............................................8 73 7. Acknowledgments..................................................9 74 8. References......................................................10 75 8.1. Normative References.......................................10 76 8.2. Informative References.....................................10 77 Author's Addresses.................................................10 79 1. Introduction 81 In packet transport network, protection switching can be triggered by 82 fault conditions and external manual commands. The fault conditions 83 include Signal Failure (SF) and Signal Degrade (SD). SF on a 84 transport entity can be detected by fault management OAM functions; 85 SD on a transport entity can be detected by performance monitoring 86 OAM functions. 88 The SD condition used for protection switching mostly depends on 89 packet loss ratio. For some services that are sensitive to time and 90 synchronization, the SD condition may depend on packet loss ratio, 91 packet delay and delay variation. 93 In MPLS-TP OAM tools, the packet loss measurement (LM) is used to 94 measure the amount of the lost service packets and compute the loss 95 ratio of service packet. The packet Delay Measurement (DM) is used to 96 measure the packet delay and delay variation by sending periodic DM 97 packets during the diagnostic interval. The LM and DM mechanisms are 98 out of scope of this document. 100 The detection of SD (e.g. packet loss) must be based on service 101 packets. But in some situation, there is no normal traffic on 102 working/protection transport entity, which makes the detection of SD 103 based on service packets impossible and causes switch flapping. 105 This document describes the mechanism for SD detection and consequent 106 protection switching in 1:1 and 1:n protection architecture. 108 2. Terminology 110 The reader is assumed to be familiar with the terminology in MPLS-TP. 111 The relationship between ITU-T and IETF terminologies on MPLS-TP can 112 be found in [Rosetta stone]. 114 MPLS-TP: MPLS Transport Profile 116 SF: Signal Failure 118 SF-W: SF for working entity 120 SF-P: SF for protection entity 122 SD: Signal Degrade 124 SD-W: SD for working entity 126 SD-P: SD for protection entity 128 APS: Automatic Protection Switching 130 OAM: Operations, Administration and Maintenance 132 CC/CV: Continuity Check/Connectivity Verification 134 LM: Loss Measurement 136 DM: Delay Measurement 138 3. SD-Triggered Protection Switching Architecture 140 The SD-triggered protection switching complies with general 141 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 normal traffic. 149 In case of MPLS-TP 1:1 and 1:n protection architecture, the selector 150 bridge is usually adopted at the source end. The normal traffic is 151 transported on the working entity together with the OAM of the 152 working entity, while on the protection entity only the OAM of the 153 protection entity is transported alone so that it may not be possible 154 to detect SD. If SD is detected on a working entity, protection 155 switching is occurred, and the traffic is transported on the 156 protection entity together with OAM. On the working entity OAM 157 packets is transported alone, and the detected SD may be cleared even 158 if the working entity is still degraded. This will result in another 159 switch of traffic back to the working entity, and SD may be detected 160 again, etc. 162 As mentioned above, in case of 1:1 and 1:n protection architecture, 163 the normal traffic will be either on the working transport entity or 164 on the protection transport entity. This makes it impossible to 165 detect SD on the standby entity. Consequently SD will be detected 166 only after a protection switch and flapping may happen. 168 4. SD-Triggered Protection Solution Analysis 170 In case of 1:1 and 1:n protection architecture, there are the 171 following solutions to implement the SD-triggered protection 172 switching without flapping. 174 - The detection of SD is based on OAM packets; (Section 4.1) 176 - The broadcast bridge has to be applied to enable SD detection in 177 SD-triggered protection, together with 179 - the special APS request priority (Section 4.2), or 181 - the extra protection switching coordination (Section 4.3). 183 The broadcasting is applied only in case protection switching is 184 active. 186 4.1. SD-Triggered Protection Based on OAM packets 188 4.1.1. Detection of SD 190 In case of 1:1 and 1:n protection architecture, for the transport 191 entity on which there is no normal traffic, the detection of SD can 192 be based on OAM packets, e.g. 194 - OAM packets for Test 196 The Test OAM packets can be used to simulate the characteristics of 197 the normal traffic and replace the normal service. With the 198 performance monitoring OAM packets (LM) the SD condition of the 199 transport entity can be detected. 201 - OAM packets for CC/CV 203 The CC/CV OAM packets can be used instead of normal service in packet 204 loss measurement. That is, the performance monitoring OAM packets (LM) 205 will count CC/CV packets and the loss measurement is based on CC/CV 206 packets, which will be used as the input of SD condition of the 207 transport entity where there is no normal service. 209 The above-mentioned SD-triggered protection switching mechanism based 210 on OAM packets (test or CC/CV) is general and flexible without 211 constraint to the bridge type at source end, that may be selector 212 bridge or broadcast bridge. 214 The performance measurement by Test OAM packets is accurate. But the 215 usage of test packets on the protection entity defeats the objective 216 of the 1:1 and 1:n architectures, which is to have the protection 217 entity bandwidth available for best effort traffic during the time 218 there is no fault or degradation of the working transport entity. The 219 test packets consume now this bandwidth. For the case of the 1:1 220 protection, this makes the bandwidth usage of this 1:1 architecture 221 similar to the bandwidth usage of the 1+1 architecture. 223 OAM packets for CC/CV are sent in fixed transmission period (3.3ms, 224 10ms, 1s, etc.) which doesn't exactly reflect the condition of real 225 services. It is applicable only in places without strict requirement 226 for SD measurement. The detection of SD by CC/CV is not recommended 227 when the packet loss is caused by congestion. 229 4.1.2. APS Protocol 231 In APS request types, similar to the definition of SF-W (SF for 232 working entity) and SF-P (SF for protection entity), a definition of 233 SD-W (SD for working entity) and SD-P (SD for protection entity) is 234 required to prevent flapping. 236 The priority of SD-P and SD-W shall be fixed as SD-P > SD-W similar 237 to SF-P > SF-W. In this case a protection switching based on SD 238 detection on the working entity shall not be initiated if there 239 exists also an SD condition on the protection transport entity. 241 4.2. Broadcast Bridge with Special APS Request Priority 243 SD-triggered protection based on normal traffic can be implemented by 244 adopting broadcast bridge at source end with the special APS request 245 priority. 247 4.2.1. Protection Switching 249 +----------+ +---------+ 250 | | | | 251 ---->----|---+------+------------>------------+---\ | 252 Source | | | Working Entity | \ | Sink 253 | | / | | +---|---->---- 254 | | / | | | 255 | +- ---+------------>------------+--- | 256 | | Protection Entity | | 257 | | | | 258 +----------+ +---------+ 260 Figure 1 Normal Condition in 1:1 Protection Architecture 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 (see Figure 1). 266 +----------+ +---------+ 267 | | | | 268 ---->----|---+------+--------SD-->------------+--- | 269 Source | | | Working Entity | | Sink 270 | | | | +---|---->---- 271 | | | | / | 272 | +-+----+------------>------------+---/ | 273 | | Protection Entity | | 274 | | | | 275 +----------+ +---------+ 277 Figure 2 SD on Working Entity in 1:1 Protection Architecture 279 When SD is detected on the working transport entity, the sink end 280 sends SD-W indication to the source end and the selector at the sink 281 end switches to the protection transport entity. The broadcast bridge 282 at the source end will then send the normal traffic on both working 283 and protection transport entities and the performance of both working 284 and protection transport entities can be monitored for SD (see Figure 285 2). 287 If SD is detected on the protection transport entity as well, i.e. 288 SD-W and SD-P exist simultaneously, normal traffic will still be 289 selected at the sink from the protection transport entity to avoid 290 flapping between protection and working states. 292 4.2.2. APS Protocol 294 In this case the priority of SD-W and SD-P in the APS protocol is 295 fixed as SD-W > SD-P to avoid flapping between protection entity and 296 working entity. 298 4.3. Broadcast Bridge with Extra Protection Switching Coordination 300 SD-triggered protection based on normal traffic can be implemented by 301 adopting broadcast bridge at source end with the extra protection 302 switching coordination. 304 The SD-W based protection switch action described in section 4.2.1 305 assumes that the probability of SD condition occurring on both 306 working entity and protection entity at the same time is very small. 307 When this assumption is not considered to be reasonable, the 308 operation of the selector may be modified as described hereafter. 310 4.3.1. Protection Switching 312 +----------+ +---------+ 313 | | | | 314 ---->----|---+------+--------SD-->------------+---\ | 315 Source | | | Working Entity | \ | Sink 316 | | | | +---|---->---- 317 | | | | | 318 | +-+----+------------>------------+--- | 319 | | Protection Entity | | 320 | | | | 321 +----------+ +---------+ 323 Figure 3 SD on Working Entity in 1:1 Protection Architecture 325 When the sink end detects an SD condition, it does not switch to the 326 protection entity immediately. Instead, the broadcast bridge at the 327 source end will first send the normal traffic on both working and 328 protection transport entity after receiving SD-W indication sent by 329 the sink end (see Figure 3). Then sink end is able to detect the SD 330 condition of working and protection transport entity. 332 If SD is detected on the protection transport entity as well, the 333 normal traffic remains broadcasted to both working and protection 334 transport entities and is selected from the working transport entity; 335 if no SD is detected on the protection transport entity the normal 336 traffic is selected from the protection entity. 338 4.3.2. APS Protocol 340 The SD priority is the same as described in 4.1.2: SD-P > SD-W. 342 4.4. Analysis 344 In section 4.1, 4.2 and 4.3, the different mechanisms for detecting 345 SD are described. The mechanism described in 4.2 is preferred because 346 of its simplicity, accuracy and flexibility. 348 5. Security Considerations 350 To be added in a future version of the document. 352 6. IANA Considerations 354 IANA is requested to allocate two further APS request codes as 355 follows: 357 xx Signal Degradation for Working entity (SD-W); 359 yy Signal Degradation for Protection entity (SD-P). 361 7. Acknowledgments 363 The authors would like to thank Huub van Helvoort for his input to 364 and review of the current document. 366 8. References 368 8.1. Normative References 370 [RFC5654] Niven-Jenkins,B., Brungard,D., and Betts,M., "Requirements 371 of an MPLS Transport Profile", RFC5654, September 2009 373 [ITU-T Recommendation G.808.1 Amd1] ''Generic protection switching - - 374 Linear trail and subnetwork protection'', ITU-T G.808.1 375 Amendment 1, January 2009 377 8.2. Informative References 379 [MPLS-TP Framework] Bocci,M., and Bryant,S., "A Framework for MPLS in 380 Transport Networks", draft-ietf-mpls-tp-framework-10 (Work 381 in progress), February 2010 383 [MPLS-TP Survive Frmk] Sprecher,N., and Farrel,a., ''Multiprotocol 384 Label Switching Transport Profile Survivability Framework", 385 draft-ietf-mpls-tp-survive-fwk-03(work in progress), 386 November 2009 388 [MPLS-TP OAM Requirements] Vigoureux,M., Ward,D., and Betts,M., 389 ''Requirements for OAM in MPLS Transport Networks'', draft- 390 ietf-mpls-tp-oam-requirements-06(work in progress), March 391 2010 393 Author's Addresses 395 Haiyan Zhang 396 Huawei Technologies Co., Ltd. 398 Phone: +86-755-28972333 399 Email: zhanghaiyan@huawei.com 401 Jia He 402 Huawei Technologies Co., Ltd. 404 Phone: +86-755-28972333 405 Email: hejia@huawei.com 407 Han Li 408 China Mobile Communications Corporation 410 Email: lihan@chinamobile.com