idnits 2.17.1 draft-zhl-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 2 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character 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 25, 2010) is 4932 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 387, but no explicit reference was found in the text 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 H. Zhang 2 Internet Draft J. He 3 Intended status: Standards Track Huawei 5 H. Li 6 China Mobile 7 October 25, 2010 8 Expires: April 2011 10 SD-Triggered Protection Switching in MPLS-TP 11 draft-zhl-mpls-tp-sd-03.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 25, 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 ............................................................8 68 4.3.1. Protection Switching...............................8 69 4.3.2. APS Protocol.......................................8 70 4.4. Analysis................................................9 71 5. Security Considerations......................................9 72 6. IANA Considerations..........................................9 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) should 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, normal 288 traffic will still be selected at the sink from the protection 289 transport entity to avoid flapping between protection and working 290 states. 292 4.2.2. APS Protocol 294 In APS request types, a SD request code should be defined. 296 In case a SD condition affects both transport entities, the first SD 297 detected is not overridden by the second SD detected, to avoid 298 flapping between protection entity and working entity. 300 In case SD is detected simultaneously either as local or far end 301 requests on both working and protection transport entities, SD on the 302 protection transport entity is considered as having higher priority 303 than SD on the working transport entity, and the normal traffic 304 continues to be selected from the working transport entity (i.e. no 305 unneeded protection switching is performed). 307 A new bridge type code in APS protocol need be defined to distinguish 308 the broadcast bridge and the selector bridge. 310 4.3. Broadcast Bridge with Extra Protection Switching Coordination 312 SD-triggered protection based on normal traffic can be implemented by 313 adopting broadcast bridge at source end with the extra protection 314 switching coordination. 316 The SD-W based protection switch action described in section 4.2.1 317 assumes that the probability of SD condition occurring on both 318 working entity and protection entity at the same time is very small. 319 When this assumption is not considered to be reasonable, the 320 operation of the selector may be modified as described hereafter. 322 4.3.1. Protection Switching 324 +----------+ +---------+ 325 | | | | 326 ---->----|---+------+--------SD-->------------+---\ | 327 Source | | | Working Entity | \ | Sink 328 | | | | +---|---->---- 329 | | | | | 330 | +-+----+------------>------------+--- | 331 | | Protection Entity | | 332 | | | | 333 +----------+ +---------+ 335 Figure 3 SD on Working Entity in 1:1 Protection Architecture 337 When the sink end detects an SD condition, it does not switch to the 338 protection entity immediately. Instead, the broadcast bridge at the 339 source end will first send the normal traffic on both working and 340 protection transport entity after receiving SD-W indication sent by 341 the sink end (see Figure 3). Then sink end is able to detect the SD 342 condition of working and protection transport entity. 344 If SD is detected on the protection transport entity as well, the 345 normal traffic remains broadcasted to both working and protection 346 transport entities and is selected from the working transport entity; 347 if no SD is detected on the protection transport entity the normal 348 traffic is selected from the protection entity. 350 4.3.2. APS Protocol 352 The SD priority is the same as described in 4.1.2: SD-P > SD-W. 354 A new bridge type code in APS protocol need be defined to distinguish 355 the broadcast bridge and the selector bridge. 357 4.4. Analysis 359 In section 4.1, 4.2 and 4.3, the different mechanisms for detecting 360 SD are described. The mechanism described in 4.2 is preferred because 361 of its simplicity, accuracy and flexibility. 363 5. Security Considerations 365 To be added in a future version of the document. 367 6. IANA Considerations 369 IANA is requested to allocate two further APS request codes as 370 follows: 372 xx Signal Degradation; 374 yy Selector Bridge for 1:1 case; 376 zz Broadcast Bridge for 1:1 case. 378 7. Acknowledgments 380 The authors would like to thank Huub van Helvoort for his input to 381 and review of the current document. 383 8. References 385 8.1. Normative References 387 [RFC5654] Niven-Jenkins,B., Brungard,D., and Betts,M., "Requirements 388 of an MPLS Transport Profile", RFC5654, September 2009 390 [ITU-T Recommendation G.808.1 Amd1] "Generic protection switching - 391 Linear trail and subnetwork protection", ITU-T G.808.1 392 Amendment 1, January 2009 394 8.2. Informative References 396 [MPLS-TP Framework] Bocci,M., and Bryant,S., "A Framework for MPLS in 397 Transport Networks", draft-ietf-mpls-tp-framework-10 (Work 398 in progress), February 2010 400 [MPLS-TP Survive Frmk] Sprecher,N., and Farrel,a., "Multiprotocol 401 Label Switching Transport Profile Survivability Framework", 402 draft-ietf-mpls-tp-survive-fwk-03(work in progress), 403 November 2009 405 [MPLS-TP OAM Requirements] Vigoureux,M., Ward,D., and Betts,M., 406 "Requirements for OAM in MPLS Transport Networks", draft- 407 ietf-mpls-tp-oam-requirements-06(work in progress), March 408 2010 410 Author's Addresses 412 Haiyan Zhang 413 Huawei Technologies Co., Ltd. 415 Phone: +86-755-28972293 416 Email: zhanghaiyan@huawei.com 418 Jia He 419 Huawei Technologies Co., Ltd. 421 Phone: +86-755-28972293 422 Email: hejia@huawei.com 424 Han Li 425 China Mobile Communications Corporation 427 Email: lihan@chinamobile.com