idnits 2.17.1 draft-ietf-ccamp-gmpls-recovery-terminology-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.a on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1058. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1035. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1042. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1048. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1064), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 20 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (April 2005) is 6944 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2026' is defined on line 955, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 961, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 964, but no explicit reference was found in the text == Unused Reference: 'G.707' is defined on line 983, but no explicit reference was found in the text == Unused Reference: 'G.783' is defined on line 987, but no explicit reference was found in the text == Unused Reference: 'G.806' is defined on line 991, but no explicit reference was found in the text == Unused Reference: 'G.842' is defined on line 1005, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) Summary: 8 errors (**), 0 flaws (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group CCAMP GMPLS P&R Design Team 3 Internet Draft 4 Category: Informational Eric Mannie (Editor) 5 Expiration Date: October 2005 Dimitri Papadimitriou (Editor) 7 April 2005 9 Recovery (Protection and Restoration) Terminology 10 for Generalized Multi-Protocol Label Switching (GMPLS) 12 draft-ietf-ccamp-gmpls-recovery-terminology-06.txt 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of section 3 of RFC 3667. By submitting this Internet-Draft, each 18 author represents that any applicable patent or other IPR claims of 19 which he or she is aware have been or will be disclosed, and any of 20 which he or she become aware will be disclosed, in accordance with 21 RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any 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/ietf/1id-abstracts.txt. 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 Internet Society (2005). All Rights Reserved. 43 Abstract 45 This document defines a common terminology for Generalized Multi- 46 Protocol Label Switching (GMPLS) based recovery mechanisms (i.e. 47 protection and restoration). The terminology is independent of the 48 underlying transport technologies covered by GMPLS. 50 E.Mannie, D.Papadimitriou et al. - Informational 1 51 Table of Contents 53 Status of this Memo .............................................. 1 54 Abstract ......................................................... 1 55 Table of Contents ................................................ 2 56 1. Contributors .................................................. 3 57 2. Introduction .................................................. 3 58 3. Conventions used in this document ............................. 4 59 4. Recovery Terminology Common to Protection and Restoration ..... 4 60 4.1 Working and Recovery LSP/Span ................................ 5 61 4.2 Traffic Types ................................................ 5 62 4.3 LSP/Span Protection and Restoration .......................... 6 63 4.4 Recovery Scope ............................................... 7 64 4.5 Recovery Domain .............................................. 7 65 4.6 Recovery Types ............................................... 7 66 4.7 Bridge Types ................................................. 9 67 4.8 Selector Types ............................................... 9 68 4.9 Recovery GMPLS Nodes ........................................ 10 69 4.10 Switch-over Mechanism ...................................... 10 70 4.11 Reversion operations ....................................... 10 71 4.12 Failure Reporting .......................................... 11 72 4.13 External commands .......................................... 11 73 4.14 Unidirectional versus Bi-Directional Recovery Switching .... 12 74 4.15 Full versus Partial Span Recovery Switching ................ 12 75 4.16 Recovery Schemes Related Time and Durations ................ 13 76 4.17 Impairment ................................................. 14 77 4.18 Recovery Ratio ............................................. 14 78 4.19 Hitless Protection Switch-over ............................. 14 79 4.20 Network Survivability ...................................... 14 80 4.21 Survivable Network ......................................... 14 81 4.22 Escalation ................................................. 14 82 5. Recovery Phases .............................................. 14 83 5.1 Entities Involved During Recovery ........................... 15 84 6. Protection Schemes ........................................... 16 85 6.1 1+1 Protection .............................................. 16 86 6.2 1:N (N >= 1) Protection ..................................... 16 87 6.3 M:N (M, N > 1, N >= M) Protection ........................... 16 88 6.4 Notes on Protection Schemes ................................. 17 89 7. Restoration Schemes .......................................... 17 90 7.1 Pre-planned LSP Restoration ................................. 17 91 7.1.1 Shared-Mesh Restoration ................................... 18 92 7.2 LSP Restoration ............................................. 18 93 7.2.1 Hard LSP Restoration ...................................... 18 94 7.2.2 Soft LSP Restoration ...................................... 18 95 8. Security Considerations ...................................... 18 96 9. IANA Considerations .......................................... 18 97 10. References .................................................. 18 98 10.1 Normative References ....................................... 18 99 10.2 Informative References ..................................... 19 100 11. Acknowledgments ............................................. 20 101 12. Editor's Address ............................................ 20 102 Intellectual Property Statement ................................. 21 104 E.Mannie, D.Papadimitriou et al.- Expires October 2005 2 105 Disclaimer of Validity .......................................... 21 106 Copyright Statement ............................................. 21 108 1. Contributors 110 This document is the result of the CCAMP Working Group Protection 111 and Restoration design team joint effort. The following are the 112 authors that contributed to the present document: 114 Deborah Brungard (AT&T) 115 Rm. D1-3C22 - 200 S. Laurel Ave. 116 Middletown, NJ 07748, USA 117 EMail: dbrungard@att.com 119 Sudheer Dharanikota 120 EMail: sudheer@ieee.org 122 Jonathan P. Lang (Sonos) 123 506 Chapala Street 124 Santa Barbara, CA 93101, USA 125 EMail: jplang@ieee.org 127 Guangzhi Li (AT&T) 128 180 Park Avenue, 129 Florham Park, NJ 07932, USA 130 EMail: gli@research.att.com 132 Eric Mannie 133 EMail: eric_mannie@hotmail.com 135 Dimitri Papadimitriou (Alcatel) 136 Francis Wellesplein, 1 137 B-2018 Antwerpen, Belgium 138 EMail: dimitri.papadimitriou@alcatel.be 140 Bala Rajagopalan (Intel Broadband Wireless Division) 141 2111 NE 25th Ave. 142 Hillsboro, OR 97124, USA 143 EMail: bala.rajagopalan@intel.com 145 Yakov Rekhter (Juniper) 146 1194 N. Mathilda Avenue 147 Sunnyvale, CA 94089, USA 148 EMail: yakov@juniper.net 150 2. Introduction 152 This document defines a common terminology for Generalized Multi- 153 Protocol Label Switching (GMPLS) based recovery mechanisms (i.e. 154 protection and restoration). 156 E.Mannie, D.Papadimitriou et al.- Expires October 2005 3 157 The terminology proposed in this document is independent of the 158 underlying transport technologies and borrows from the G.808.1 ITU-T 159 Recommendation [G.808.1] and from the G.841 ITU-T Recommendation 160 [G.841]. The restoration terminology and concepts have been gathered 161 from numerous sources including IETF drafts. 163 In the context of this document, the term "recovery" denotes both 164 protection and restoration. The specific terms "protection" and 165 "restoration" will only be used when differentiation is required. 167 This document focuses on the terminology for the recovery of Label 168 Switched Paths (LSPs) controlled by a GMPLS control plane. The 169 proposed terminology applies to end-to-end, segment, and span (i.e. 170 link) recovery. Note that the terminology for recovery of the 171 control plane itself is not in the scope of this document. 173 Protection and restoration of switched LSPs under tight time 174 constraints is a challenging problem. This is particularly relevant 175 to optical networks that consist of Time Division Multiplex (TDM) 176 and/or all-optical (photonic) cross-connects referred to as GMPLS 177 nodes (or simply nodes, or even sometimes "Label Switching Routers, 178 or LSRs") connected in a general topology [RFC3945]. 180 Recovery typically involves the activation of a recovery (or 181 alternate) LSP when a failure is encountered in the working LSP. 183 A working or recovery LSP is characterized by an ingress interface, 184 an egress interface, and a set of intermediate nodes and spans 185 through which the LSP is routed. The working and recovery LSPs are 186 typically resource disjoint (e.g. node and/or span disjoint). This 187 ensures that a single failure will not affect both the working and 188 recovery LSPs. 190 A bi-directional span between neighboring nodes is usually realized 191 as a pair of unidirectional spans. The end-to-end path for a bi- 192 directional LSP therefore consists of a series of bi-directional 193 segments (i.e. Sub-Network Connections, or SNCs, in the ITU-T 194 terminology) between the source and destination nodes, traversing 195 intermediate nodes. 197 3. Conventions used in this document: 199 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 200 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 201 this document are to be interpreted as described in [RFC2119]. 203 4. Recovery Terminology Common to Protection and Restoration 205 This section defines the following general terms common to both 206 protection and restoration (i.e. recovery). In addition, most of 207 these terms apply to end-to-end, segment and span LSP recovery. Note 209 E.Mannie, D.Papadimitriou et al.- Expires October 2005 4 210 that span recovery does not protect the nodes at each end of the 211 span, otherwise end-to-end or segment LSP recovery should be used. 213 The terminology and the definitions have been originally taken from 214 [G.808.1]. However, for generalization, the following language that 215 is not directly related to recovery has been adapted to GMPLS and 216 the common IETF terminology: 218 An LSP is used as a generic term to designate either an SNC (Sub- 219 Network Connection) or an NC (Network Connection) in ITU-T 220 terminology. The ITU-T uses the term transport entity to designate 221 either a link, an SNC or an NC. The term "Traffic" is used instead 222 of "Traffic Signal". The term protection or restoration "scheme" is 223 used instead of protection or restoration "architecture". 225 The reader is invited to read [G.841] and [G.808.1] for references 226 to SDH protection and Generic Protection Switching terminology, 227 respectively. Note that restoration is not in the scope of 228 [G.808.1]. 230 4.1 Working and Recovery LSP/Span 232 A working LSP/span is an LSP/span transporting "normal" user 233 traffic. A recovery LSP/span is an LSP/span used to transport 234 "normal" user traffic when the working LSP/span fails. Additionally, 235 the recovery LSP/span may transport "extra" user traffic (i.e. pre- 236 emptable traffic) when normal traffic is carried over the working 237 LSP/span. 239 4.2 Traffic Types 241 The different types of traffic that can be transported over an 242 LSP/span in the context of this document are defined hereafter: 244 A. Normal traffic: 246 User traffic that may be protected by two alternative LSPs/spans 247 (the working and recovery LSPs/spans). 249 B. Extra traffic: 251 User traffic carried over recovery resources (e.g. a recovery 252 LSP/span) when these resources are not being used for the recovery 253 of normal traffic; i.e. when the recovery resources are in standby 254 mode. When the recovery resources are required to recover normal 255 traffic from the failed working LSP/span, the extra traffic is pre- 256 empted. Extra traffic is not protected by definition, but may be 257 restored. Moreover, extra traffic does not need to commence or be 258 terminated at the ends of the LSPs/spans that it uses. 260 C. Null traffic: 262 E.Mannie, D.Papadimitriou et al.- Expires October 2005 5 263 Traffic carried over the recovery LSP/span if it is not used to 264 carry normal or extra traffic. Null traffic can be any kind of 265 traffic that conforms to the signal structure of the specific layer, 266 and it is ignored (not selected) at the egress of the recovery 267 LSP/span. 269 4.3 LSP/Span Protection and Restoration 271 The following subtle distinction is generally made between the terms 272 "protection" and "restoration", even though these terms are often 273 used interchangeably [RFC3386]. 275 The distinction between protection and restoration is made based on 276 the resource allocation done during the recovery LSP/span 277 establishment. The distinction between different types of 278 restoration is made based on the level of route computation, 279 signaling and resource allocation done during the restoration 280 LSP/span establishment. 282 A. LSP/Span Protection 284 LSP/span protection denotes the paradigm whereby one or more 285 dedicated protection LSP(s)/span(s) is/are fully established to 286 protect one or more working LSP(s)/span(s). 288 For a protection LSP, this implies that route computation took 289 place, that the LSP was fully signaled all the way and that its 290 resources were fully selected (i.e. allocated) and cross-connected 291 between the ingress and egress nodes. 293 For a protection span, this implies that the span has been selected 294 and reserved for protection. 296 Indeed, it means that no signaling takes place to establish the 297 protection LSP/span when a failure occurs. However, various other 298 kinds of signaling may take place between the ingress and egress 299 nodes for fault notification, to synchronize their use of the 300 protection LSP/span, for reversion, etc. 302 B. LSP/Span Restoration 304 LSP/span restoration denotes the paradigm whereby some restoration 305 resources may be pre-computed, signaled and selected a priori, but 306 not cross-connected to restore a working LSP/span. The complete 307 establishment of the restoration LSP/span occurs only after a 308 failure of the working LSP/span, and requires some additional 309 signaling. 311 Both protection and restoration require signaling. Signaling to 312 establish the recovery resources and signaling associated with the 313 use of the recovery LSP(s)/span(s) are needed. 315 E.Mannie, D.Papadimitriou et al.- Expires October 2005 6 316 4.4 Recovery Scope 318 Recovery can be applied at various levels throughout the network. An 319 LSP may be subject to local (span), segment, and/or end-to-end 320 recovery. 322 Local (span) recovery refers to the recovery of an LSP over a link 323 between two nodes. 325 End-to-end recovery refers to the recovery of an entire LSP from its 326 source (ingress node end-point) to its destination (egress node end- 327 point). 329 Segment recovery refers to the recovery over a portion of the 330 network of a segment LSP (i.e. an SNC in the ITU-T terminology) of 331 an end-to-end LSP. Such recovery protects against span and/or node 332 failure over a particular portion of the network traversed by an 333 end-to-end LSP. 335 4.5 Recovery Domain 337 A recovery domain is defined as a set of nodes and spans over which 338 one or more recovery schemes are provided. A recovery domain served 339 by one single recovery scheme is referred to as a "single recovery 340 domain", while a recovery domain served by multiple recovery schemes 341 is referred to as a "multi recovery domain". 343 The recovery operation is contained within the recovery domain. A 344 GMPLS recovery domain must be entirely contained within a GMPLS 345 domain. A GMPLS domain (defined as a set of nodes and spans 346 controlled by GMPLS) may contain multiple recovery domains. 348 4.6 Recovery Types 350 The different recovery types can be classified depending on the 351 number of recovery LSPs/spans that are protecting a given number of 352 working LSPs/spans. The definitions given hereafter are from the 353 point of view of a working LSP/span that needs to be protected by a 354 recovery scheme. 356 A. 1+1 type: dedicated protection 358 One dedicated protection LSP/span protects exactly one working 359 LSP/span and the normal traffic is permanently duplicated at the 360 ingress node on both the working and protection LSPs/spans. No extra 361 traffic can be carried over the protection LSP/span. 363 This type is applicable to LSP/span protection, but not to LSP/span 364 restoration. 366 B. 0:1 type: unprotected 368 E.Mannie, D.Papadimitriou et al.- Expires October 2005 7 369 No specific recovery LSP/span protects the working LSP/span. 370 However, the working LSP/span can potentially be restored through 371 any alternate available route/span, with or without any pre-computed 372 restoration route. Note that there are no resources pre-established 373 for this recovery type. 375 This type is applicable to LSP/span restoration, but not to LSP/span 376 protection. Span restoration can be for instance achieved by moving 377 all the LSPs transported over of a failed span to a dynamically 378 selected span. 380 C. 1:1 type: dedicated recovery with extra traffic 382 One specific recovery LSP/span protects exactly one specific working 383 LSP/span but the normal traffic is transmitted only over one LSP 384 (working or recovery) at a time. Extra traffic can be transported 385 using the recovery LSP/span resources. 387 This type is applicable to LSP/span protection and LSP restoration, 388 but not to span restoration. 390 D. 1:N (N > 1) type: shared recovery with extra traffic 392 A specific recovery LSP/span is dedicated to the protection of up to 393 N working LSPs/spans. The set of working LSPs/spans is explicitly 394 identified. Extra traffic can be transported over the recovery 395 LSP/span. All these LSPs/spans must start and end at the same nodes. 397 Sometimes, the working LSPs/spans are assumed to be resource 398 disjoint in the network so that they do not share any failure 399 probability, but this is not mandatory. Obviously, if more than one 400 working LSP/span in the set of N are affected by some failure(s) at 401 the same time, the traffic on only one of these failed LSPs/spans 402 may be recovered over the recovery LSP/span. Note that N can be 403 arbitrarily large (i.e. infinite). The choice of N is a policy 404 decision. 406 This type is applicable to LSP/span protection and LSP restoration, 407 but not to span restoration. 409 Note: a shared recovery where each recovery resource can be shared 410 by a maximum of X LSPs/spans is not defined as a recovery type but 411 as a recovery scheme. The choice of X is a network resource 412 management policy decision. 414 E. M:N (M, N > 1, N >= M) type: 416 A set of M specific recovery LSPs/spans protects a set of up to N 417 specific working LSPs/spans. The two sets are explicitly identified. 418 Extra traffic can be transported over the M recovery LSPs/spans when 419 available. All the LSPs/spans must start and end at the same nodes. 421 E.Mannie, D.Papadimitriou et al.- Expires October 2005 8 422 Sometimes, the working LSPs/spans are assumed to be resource 423 disjoint in the network so that they do not share any failure 424 probability, but this is not mandatory. Obviously, if several 425 working LSPs/spans in the set of N are concurrently affected by some 426 failure(s), the traffic on only M of these failed LSPs/spans may be 427 recovered. Note that N can be arbitrarily large (i.e. infinite). The 428 choice of N and M is a policy decision. 430 This type is applicable to LSP/span protection and LSP restoration, 431 but not to span restoration. 433 4.7 Bridge Types 435 A bridge is the function that connects the normal traffic and extra 436 traffic to the working and recovery LSP/span. 438 A. Permanent bridge 440 Under a 1+1 type, the bridge connects the normal traffic to both the 441 working and protection LSPs/spans. This type of bridge is not 442 applicable to restoration types. There is of course no extra traffic 443 connected to the recovery LSP/span. 445 B. Broadcast bridge 447 For 1:N and M:N types, the bridge permanently connects the normal 448 traffic to the working LSP/span. In the event of recovery switching, 449 the normal traffic is additionally connected to the recovery 450 LSP/span. Extra traffic is either not connected or connected to the 451 recovery LSP/span. 453 C. Selector bridge 455 For 1:N and M:N types, the bridge connects the normal traffic to 456 either the working or the recovery LSP/span. Extra traffic is either 457 not connected or connected to the recovery LSP/span. 459 4.8 Selector Types 461 A selector is the function that extracts the normal traffic either 462 from the working or the recovery LSP/span. Extra traffic is either 463 extracted from the recovery LSP/span, or is not extracted. 465 A. Selective selector 467 Is a selector that extracts the normal traffic from either the 468 working LSP/span output or the recovery LSP/span output. 470 B. Merging selector 472 For 1:N and M:N protection types, the selector permanently extracts 473 the normal traffic from both the working and recovery LSP/span 475 E.Mannie, D.Papadimitriou et al.- Expires October 2005 9 476 outputs. This alternative works only in combination with a selector 477 bridge. 479 4.9 Recovery GMPLS Nodes 481 This section defines the GMPLS nodes involved during recovery. 483 A. Ingress GMPLS node of an end-to-end LSP/segment LSP/span 485 The ingress node of an end-to-end LSP/segment LSP/span is where the 486 normal traffic may be bridged to the recovery end-to-end LSP/segment 487 LSP/span. Also known as source node in the ITU-T terminology. 489 B. Egress GMPLS node of an end-to-end LSP/segment LSP/span 491 The egress node of an end-to-end LSP/segment LSP/span is where the 492 normal traffic may be selected from either the working or the 493 recovery end-to-end LSP/segment LSP/span. Also known as sink node in 494 the ITU-T terminology. 496 C. Intermediate GMPLS node of an end-to-end LSP/segment LSP 498 A node along either the working or recovery end-to-end LSP/segment 499 LSP route between the corresponding ingress and egress nodes. Also 500 known as intermediate node in the ITU-T terminology. 502 4.10 Switch-over Mechanism 504 A switch-over is an action that can be performed at both the bridge 505 and the selector. This action is as follows: 507 A. For the selector: 509 The action of selecting normal traffic from the recovery LSP/span 510 rather than from the working LSP/span. 512 B. For the bridge: 514 In case of permanent connection to the working LSP/span, the action 515 of connecting or disconnecting the normal traffic to the recovery 516 LSP/span. In case of non-permanent connection to the working 517 LSP/span, the action of connecting the normal traffic to the 518 recovery LSP/span. 520 4.11 Reversion operations 522 A revertive recovery operation refers to a recovery switching 523 operation, where the traffic returns to (or remains on) the working 524 LSP/span if the switch-over requests are terminated; i.e. when the 525 working LSP/span has recovered from the failure. 527 E.Mannie, D.Papadimitriou et al.- Expires October 2005 10 528 Therefore a non-revertive recovery switching operation is when the 529 traffic does not return to the working LSP/span if the switch-over 530 requests are terminated. 532 4.12 Failure Reporting 534 This section gives (for information) several signal types commonly 535 used in transport planes to report a failure condition. Note that 536 fault reporting may require additional signaling mechanisms. 538 A. Signal Degrade (SD): a signal indicating that the associated data 539 has degraded. 541 B. Signal Fail (SF): a signal indicating that the associated data 542 has failed. 544 C. Signal Degrade Group (SDG): a signal indicating that the 545 associated group data has degraded. 547 D. Signal Fail Group (SFG): a signal indicating that the associated 548 group has failed. 550 Note: SDG and SFG definitions are under discussion at the ITU-T. 552 4.13 External commands 554 This section defines several external commands, typically issued by 555 an operator through the Network Management System (NMS)/Element 556 Management System (EMS), which can be used to influence or command 557 the recovery schemes. 559 A. Lockout of recovery LSP/span: 561 A configuration action initiated externally that results in the 562 recovery LSP/span being temporarily unavailable to transport traffic 563 (either normal or extra traffic). 565 B. Lockout of normal traffic: 567 A configuration action initiated externally that results in the 568 normal traffic being temporarily not allowed to be routed over its 569 recovery LSP/span. Note that in this case extra-traffic is still 570 allowed on the recovery LSP/span. 572 C. Freeze: 574 A configuration action initiated externally that prevents any 575 switch-over action to be taken, and as such freezes the current 576 state. 578 D. Forced switch-over for normal traffic: 580 E.Mannie, D.Papadimitriou et al.- Expires October 2005 11 581 A switch-over action initiated externally that switches normal 582 traffic to the recovery LSP/span, unless an equal or higher priority 583 switch-over command is in effect. 585 E. Manual switch-over for normal traffic: 587 A switch-over action initiated externally that switches normal 588 traffic to the recovery LSP/span, unless a fault condition exists on 589 other LSPs/spans (including the recovery LSP/span) or an equal or 590 higher priority switch-over command is in effect. 592 F. Manual switch-over for recovery LSP/span: 594 A switch-over action initiated externally that switches normal 595 traffic to the working LSP/span, unless a fault condition exists on 596 the working LSP/span or an equal or higher priority switch-over 597 command is in effect. 599 G. Clear: 601 An action initiated externally that clears the active external 602 command. 604 4.14 Unidirectional versus Bi-Directional Recovery Switching 606 A. Unidirectional recovery switching: 608 A recovery switching mode in which, for a unidirectional fault (i.e. 609 a fault affecting only one direction of transmission), only the 610 normal traffic transported in the affected direction (of the LSP or 611 span) is switched to the recovery LSP/span. 613 B. Bi-directional recovery switching: 615 A recovery switching mode in which, for a unidirectional fault, the 616 normal traffic in both directions (of the LSP or span), including 617 the affected direction and the unaffected direction, are switched to 618 the recovery LSP/span. 620 4.15 Full versus Partial Span Recovery Switching 622 Bulk LSP recovery is initiated upon reception on either span failure 623 notification or bulk failure notification of the S LSPs carried by 624 this span. In either case, the corresponding recovery switching 625 actions are performed at the LSP level such that the ratio between 626 the number of recovery switching messages and the number of 627 recovered LSP (in one given direction) is minimized. If this ratio 628 equals 1, one refers to full span recovery, otherwise, if this ratio 629 is greater than 1 one refers to partial span recovery. 631 A. Full Span Recovery 633 E.Mannie, D.Papadimitriou et al.- Expires October 2005 12 634 All the S LSP carried over a given span are recovered under span 635 failure condition. Full span recovery is also referred to as "bulk 636 recovery". 638 B. Partial Span Recovery 640 Only a subset s of the S LSP carried over a given span are recovered 641 under span failure condition. Both selection criteria of the 642 entities belonging to this subset and the decision concerning the 643 recovery of the remaining (S - s) LSP are based on local policy. 645 4.16 Recovery Schemes Related Time and Durations 647 This section gives several typical timing definitions that are of 648 importance for recovery schemes. 650 A. Detection time: 652 The time between the occurrence of the fault or degradation and its 653 detection. Note that this is a rather theoretical time since in 654 practice this is difficult to measure. 656 B. Correlation time: 658 The time between the detection of the fault or degradation and the 659 reporting of the signal fail or degrade. This time is typically used 660 in correlating related failures or degradations. 662 C. Notification time: 664 The time between the reporting of the signal fail or degrade and the 665 reception of the indication of this event by the entities that 666 decide on the recovery switching operation(s). 668 D. Recovery Switching time: 670 The time between the initialization of the recovery switching 671 operation and the moment the normal traffic is selected from the 672 recovery LSP/span. 674 E. Total Recovery time: 676 The total recovery time is defined as the sum of the detection, the 677 correlation, the notification and the recovery switching time. 679 F. Wait To Restore time: 681 A period of time that must elapse from a recovered fault before an 682 LSP/span can be used again to transport the normal traffic and/or to 683 select the normal traffic from. 685 E.Mannie, D.Papadimitriou et al.- Expires October 2005 13 686 Note: the hold-off time is defined as the time between the reporting 687 of signal fail or degrade, and the initialization of the recovery 688 switching operation. This is useful when multiple layers of recovery 689 are being used. 691 4.17 Impairment 693 A defect or performance degradation, which may lead to SF or SD 694 trigger. 696 4.18 Recovery Ratio 698 The quotient of the actually recovery bandwidth divided by the 699 traffic bandwidth which is intended to be protected. 701 4.19 Hitless Protection Switch-over 703 Protection switch-over, which does not cause data loss, data 704 duplication, data disorder, or bit errors upon recovery switching 705 action. 707 4.20 Network Survivability 709 The set of capabilities that allow a network to restore affected 710 traffic in the event of a failure. The degree of survivability is 711 determined by the network's capability to survive single and 712 multiple failures. 714 4.21 Survivable Network 716 A network that is capable of restoring traffic in the event of a 717 failure. 719 4.22 Escalation 721 A network survivability action caused by the impossibility of the 722 survivability function in lower layers. 724 5. Recovery Phases 726 It is commonly accepted that recovery implies that the following 727 generic operations need to be performed when an LSP/span or a node 728 failure occurs: 730 - Phase 1: Failure Detection 732 The action of detecting the impairment (defect of performance 733 degradation) as a defect condition and consequential activation of 734 SF or SD trigger to the control plane (through internal interface 735 with the transport plane). Thus, failure detection (that should 736 occur at the transport layer closest to the failure) is the only 737 phase that can not be achieved by the control plane alone. 739 E.Mannie, D.Papadimitriou et al.- Expires October 2005 14 740 - Phase 2: Failure Localization (and Isolation) 742 Failure localization provides to the deciding entity information 743 about the location (and so the identity) of the transport plane 744 entity that causes the LSP(s)/span(s) failure. The deciding entity 745 can then take accurate decision to achieve finer grained recovery 746 switching action(s). 748 - Phase 3: Failure Notification 750 Failure notification phase is used 1) to inform intermediate nodes 751 that LSP(s)/span(s) failure has occurred and has been detected 2) to 752 inform the recovery deciding entities (which can correspond to any 753 intermediate or end-point of the failed LSP/span) that the 754 corresponding LSP/span is not available. 756 - Phase 4: Recovery (Protection or Restoration) 758 See Section 4.3. 760 - Phase 5: Reversion (Normalization) 762 See Section 4.11. 764 The combination of Failure Detection and Failure Localization and 765 Notification is referred to as Fault Management. 767 5.1 Entities Involved During Recovery 769 The entities involved during the recovery operations can be defined 770 as follows; these entities are parts of ingress, egress and 771 intermediate nodes as defined previously: 773 A. Detecting Entity (Failure Detection): 775 An entity that detects a failure or group of failures; providing 776 thus a non-correlated list of failures. 778 B. Reporting Entity (Failure Correlation and Notification): 780 An entity that can make an intelligent decision on fault correlation 781 and report the failure to the deciding entity. Fault reporting can 782 be automatically performed by the deciding entity detecting the 783 failure. 785 C. Deciding Entity (part of the failure recovery decision process): 787 An entity that makes the recovery decision or selects the recovery 788 resources. This entity communicates the decision to the impacted 789 LSPs/spans with the recovery actions to be performed. 791 E.Mannie, D.Papadimitriou et al.- Expires October 2005 15 792 D. Recovering Entity (part of the failure recovery activation 793 process): 795 An entity that participates in the recovery of the LSPs/spans. 797 The process of moving failed LSPs from a failed (working) span to a 798 protection span must be initiated by one of the nodes terminating 799 the span, e.g. A or B. The deciding (and recovering) entity is 800 referred to as the "master" while the other node is called the 801 "slave" and corresponds to a recovering only entity. 803 Note: The determination of the master and the slave may be based on 804 configured information or protocol specific requirements. 806 6. Protection Schemes 808 This section clarifies the multiple possible protection schemes and 809 the specific terminology for the protection. 811 6.1 1+1 Protection 813 1+1 protection has one working LSP/span, one protection LSP/span and 814 a permanent bridge. At the ingress node, the normal traffic is 815 permanently bridged to both the working and protection LSP/span. At 816 the egress node, the normal traffic is selected from the better of 817 the two LSPs/spans. 819 Due to the permanent bridging, the 1+1 protection does not allow an 820 unprotected extra traffic signal to be provided. 822 6.2 1:N (N >= 1) Protection 824 1:N protection has N working LSPs/spans carrying normal traffic and 825 1 protection LSP/span that may carry extra-traffic. 827 At the ingress, the normal traffic is either permanently connected 828 to its working LSP/span and may be connected to the protection 829 LSP/span (case of broadcast bridge), or is connected to either its 830 working or the protection LSP/span (case of selector bridge). At the 831 egress node, the normal traffic is selected from either its working 832 or protection LSP/span. 834 Unprotected extra traffic can be transported over the protection 835 LSP/span whenever the protection LSP/span is not used to carry a 836 normal traffic. 838 6.3 M:N (M, N > 1, N >= M) Protection 840 M:N protection has N working LSPs/spans carrying normal traffic and 841 M protection LSP/span that may carry extra-traffic. 843 E.Mannie, D.Papadimitriou et al.- Expires October 2005 16 844 At the ingress, the normal traffic is either permanently connected 845 to its working LSP/span and may be connected to one of the 846 protection LSPs/spans (case of broadcast bridge), or is connected to 847 either its working or one of the protection LSPs/spans (case of 848 selector bridge). At the egress node, the normal traffic is selected 849 from either its working or one of the protection LSP/span. 851 Unprotected extra traffic can be transported over the M protection 852 LSP/span whenever the protection LSPs/spans is not used to carry a 853 normal traffic. 855 6.4 Notes on Protection Schemes 857 All protection types are either uni- or bi-directional, obviously, 858 the latter applies only to bi-directional LSP/span and requires 859 coordination between the ingress and egress node during protection 860 switching. 862 All protection types except 1+1 unidirectional protection switching 863 require a communication channel between the ingress and the egress 864 node. 866 In the GMPLS context, span protection refers to the full or partial 867 span recovery of the LSPs carried over that span (see Section 4.15). 869 7. Restoration Schemes 871 This section clarifies the multiple possible restoration schemes and 872 the specific terminology for the restoration. 874 7.1 Pre-planned LSP Restoration 876 Also referred to as pre-planned LSP re-routing. Before failure 877 detection and/or notification, one or more restoration LSPs are 878 instantiated between the same ingress-egress node pair than the 879 working LSP. Note that the restoration resources must be pre- 880 computed, must be signaled and may be selected a priori, but not 881 cross-connected. Thus, the restoration LSP is not able to carry any 882 extra-traffic. 884 The complete establishment of the restoration LSP (i.e. activation) 885 occurs only after failure detection and/or notification of the 886 working LSP and requires some additional restoration signaling. 887 Therefore, this mechanism protects against working LSP failure(s) 888 but requires activation of the restoration LSP after failure 889 occurrence. After the ingress node has activated the restoration 890 LSP, the latter can carry the normal traffic. 892 Note: when each working LSP is recoverable by exactly one 893 restoration LSP, one refers also to 1:1 (pre-planned) re-routing 894 without extra-traffic. 896 E.Mannie, D.Papadimitriou et al.- Expires October 2005 17 897 7.1.1 Shared-Mesh Restoration 899 "Shared-mesh" restoration is defined as a particular case of pre- 900 planned LSP re-routing that reduces the restoration resource 901 requirements by allowing multiple restoration LSPs (initiated from 902 distinct ingress nodes) to share common resources (including links 903 and nodes.) 905 7.2 LSP Restoration 907 Also referred to as LSP re-routing. The ingress node switches the 908 normal traffic to an alternate LSP signaled and fully established 909 (i.e. cross-connected) after failure detection and/or notification. 910 The alternate LSP path may be computed after failure detection 911 and/or notification. In this case, one also refers to "Full LSP Re- 912 routing." 914 The alternate LSP is signaled from the ingress node and may reuse 915 intermediate node's resources of the working LSP under failure 916 condition (and may also include additional intermediate nodes.) 918 7.2.1 Hard LSP Restoration 920 Also referred to as hard LSP re-routing. A re-routing operation 921 where the LSP is released before the full establishment of an 922 alternate LSP (i.e. break-before-make). 924 7.2.2 Soft LSP Restoration 926 Also referred to as soft LSP re-routing. A re-routing operation 927 where the LSP is released after the full establishment of an 928 alternate LSP (i.e. make-before-break). 930 8. Security Considerations 932 Security considerations are detailed in [ANAL] and [FUNCT]. 934 9. IANA Considerations 936 This document defines no new code points and requires no action by 937 IANA. 939 10. References 941 10.1 Normative References 943 [ANAL] D.Papadimitriou and E.Mannie (Editors), "Analysis of 944 Generalized Multi-Protocol Label Switching (GMPLS)- 945 based Recovery Mechanisms (including Protection and 946 Restoration)", Internet Draft (Work in progress), April 947 2005. 949 E.Mannie, D.Papadimitriou et al.- Expires October 2005 18 951 [FUNCT] J.P.Lang, B.Rajagopalan and D.Papadimitriou (Editors), 952 "Generalized MPLS Recovery Functional Specification," 953 Internet Draft (Work in progress), April 2005. 955 [RFC2026] S.Bradner, "The Internet Standards Process -- Revision 956 3", BCP 9, RFC 2026, October 1996. 958 [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate 959 Requirement Levels," BCP 14, RFC 2119, March 1997. 961 [RFC3667] S.Bradner, "IETF Rights in Contributions", BCP 78, 962 RFC 3667, February 2004. 964 [RFC3668] S.Bradner, Ed., "Intellectual Property Rights in IETF 965 Technology", BCP 79, RFC 3668, February 2004. 967 10.2 Informative References 969 [RFC3386] W.S.Lai, et al., "Network Hierarchy and Multilayer 970 Survivability," RFC 3386, November 2002. 972 [RFC3945] E.Mannie (Editor), "Generalized Multi-Protocol Label 973 Switching (GMPLS) Architecture," RFC 3945, October 974 2004. 976 [T1.105] ANSI, "Synchronous Optical Network (SONET): Basic 977 Description Including Multiplex Structure, Rates, and 978 Formats," ANSI T1.105, January 2001. 980 For information on the availability of the following documents, 981 please see http://www.itu.int 983 [G.707] ITU-T, "Network Node Interface for the Synchronous 984 Digital Hierarchy (SDH)," Recommendation G.707, October 985 2000. 987 [G.783] ITU-T, "Characteristics of Synchronous Digital 988 Hierarchy (SDH) Equipment Functional Blocks," 989 Recommendation G.783, October 2000. 991 [G.806] ITU-T, "Characteristics of Transport Equipment - 992 Description Methodology and Generic Functionality," 993 Recommendation G.806, October 2000. 995 [G.808.1] ITU-T, "Generic Protection Switching - Linear trail and 996 subnetwork protection," Recommendation G.808.1, 997 December 2003. 999 [G.841] ITU-T, "Types and Characteristics of SDH Network 1000 Protection Architectures," Recommendation G.841, 1001 October 1998. 1003 E.Mannie, D.Papadimitriou et al.- Expires October 2005 19 1005 [G.842] ITU-T, "Interworking of SDH network protection 1006 architectures," Recommendation G.842, October 1998. 1008 11. Acknowledgments 1010 Many thanks to Adrian Farrel for having thoroughly review this 1011 document. 1013 12. Editor's Addresses 1015 Eric Mannie 1016 EMail: eric_mannie@hotmail.com 1018 Dimitri Papadimitriou 1019 Alcatel 1020 Francis Wellesplein, 1 1021 B-2018 Antwerpen, Belgium 1022 Phone: +32 3 240-8491 1023 EMail: dimitri.papadimitriou@alcatel.be 1025 E.Mannie, D.Papadimitriou et al.- Expires October 2005 20 1026 Intellectual Property Statement 1028 The IETF takes no position regarding the validity or scope of any 1029 Intellectual Property Rights or other rights that might be claimed 1030 to pertain to the implementation or use of the technology described 1031 in this document or the extent to which any license under such 1032 rights might or might not be available; nor does it represent that 1033 it has made any independent effort to identify any such rights. 1034 Information on the procedures with respect to rights in RFC 1035 documents can be found in BCP 78 and BCP 79. 1037 Copies of IPR disclosures made to the IETF Secretariat and any 1038 assurances of licenses to be made available, or the result of an 1039 attempt made to obtain a general license or permission for the use 1040 of such proprietary rights by implementers or users of this 1041 specification can be obtained from the IETF on-line IPR repository 1042 at http://www.ietf.org/ipr. 1044 The IETF invites any interested party to bring to its attention any 1045 copyrights, patents or patent applications, or other proprietary 1046 rights that may cover technology that may be required to implement 1047 this standard. Please address the information to the IETF at 1048 ietf-ipr@ietf.org. 1050 Disclaimer of Validity 1052 This document and the information contained herein are provided on 1053 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1054 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1055 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1056 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1057 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1058 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1060 Copyright Statement 1062 Copyright (C) The Internet Society (2005). This document is subject 1063 to the rights, licenses and restrictions contained in BCP 78, and 1064 except as set forth therein, the authors retain all their rights. 1066 Acknowledgment 1068 Funding for the RFC Editor function is currently provided by the 1069 Internet Society. 1071 E.Mannie, D.Papadimitriou et al.- Expires October 2005 21