diff options
Diffstat (limited to 'doc/rfc/rfc4427.txt')
| -rw-r--r-- | doc/rfc/rfc4427.txt | 1235 |
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc4427.txt b/doc/rfc/rfc4427.txt new file mode 100644 index 0000000..4e526aa --- /dev/null +++ b/doc/rfc/rfc4427.txt @@ -0,0 +1,1235 @@ + + + + + + +Network Working Group E. Mannie, Ed. +Request for Comments: 4427 Perceval +Category: Informational D. Papadimitriou, Ed. + Alcatel + March 2006 + + + Recovery (Protection and Restoration) Terminology + for Generalized Multi-Protocol Label Switching (GMPLS) + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document defines a common terminology for Generalized Multi- + Protocol Label Switching (GMPLS)-based recovery mechanisms (i.e., + protection and restoration). The terminology is independent of the + underlying transport technologies covered by GMPLS. + + + + + + + + + + + + + + + + + + + + + + + + + +Mannie & Papadimitriou Informational [Page 1] + +RFC 4427 GMPLS Recovery Terminology March 2006 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Contributors ....................................................4 + 3. Conventions Used in this Document ...............................5 + 4. Recovery Terminology Common to Protection and Restoration .......5 + 4.1. Working and Recovery LSP/Span ..............................6 + 4.2. Traffic Types ..............................................6 + 4.3. LSP/Span Protection and Restoration ........................6 + 4.4. Recovery Scope .............................................7 + 4.5. Recovery Domain ............................................8 + 4.6. Recovery Types .............................................8 + 4.7. Bridge Types ..............................................10 + 4.8. Selector Types ............................................10 + 4.9. Recovery GMPLS Nodes ......................................11 + 4.10. Switch-over Mechanism ....................................11 + 4.11. Reversion operations .....................................11 + 4.12. Failure Reporting ........................................12 + 4.13. External commands ........................................12 + 4.14. Unidirectional versus Bi-Directional Recovery Switching ..13 + 4.15. Full versus Partial Span Recovery Switching ..............14 + 4.16. Recovery Schemes Related Time and Durations ..............14 + 4.17. Impairment ...............................................15 + 4.18. Recovery Ratio ...........................................15 + 4.19. Hitless Protection Switch-over ...........................15 + 4.20. Network Survivability ....................................15 + 4.21. Survivable Network .......................................16 + 4.22. Escalation ...............................................16 + 5. Recovery Phases ................................................16 + 5.1. Entities Involved During Recovery .........................17 + 6. Protection Schemes .............................................17 + 6.1. 1+1 Protection ............................................18 + 6.2. 1:N (N >= 1) Protection ...................................18 + 6.3. M:N (M, N > 1, N >= M) Protection .........................18 + 6.4. Notes on Protection Schemes ...............................19 + 7. Restoration Schemes ............................................19 + 7.1. Pre-Planned LSP Restoration ...............................19 + 7.1.1. Shared-Mesh Restoration ............................19 + 7.2. LSP Restoration ...........................................20 + 7.2.1. Hard LSP Restoration ...............................20 + 7.2.2. Soft LSP Restoration ...............................20 + 8. Security Considerations ........................................20 + 9. References .....................................................20 + 9.1. Normative References ......................................20 + 9.2. Informative References ....................................20 + 10. Acknowledgements ..............................................21 + + + + + +Mannie & Papadimitriou Informational [Page 2] + +RFC 4427 GMPLS Recovery Terminology March 2006 + + +1. Introduction + + This document defines a common terminology for Generalized Multi- + Protocol Label Switching (GMPLS)-based recovery mechanisms (i.e., + protection and restoration). + + The terminology proposed in this document is independent of the + underlying transport technologies and borrows from the G.808.1 ITU-T + Recommendation [G.808.1] and from the G.841 ITU-T Recommendation + [G.841]. The restoration terminology and concepts have been gathered + from numerous sources including IETF documents. + + In the context of this document, the term "recovery" denotes both + protection and restoration. The specific terms "protection" and + "restoration" will only be used when differentiation is required. + + This document focuses on the terminology for the recovery of Label + Switched Paths (LSPs) controlled by a GMPLS control plane. The + proposed terminology applies to end-to-end, segment, and span (i.e., + link) recovery. Note that the terminology for recovery of the + control plane itself is not in the scope of this document. + + Protection and restoration of switched LSPs under tight time + constraints is a challenging problem. This is particularly relevant + to optical networks that consist of Time Division Multiplex (TDM) + and/or all-optical (photonic) cross-connects referred to as GMPLS + nodes (or simply nodes, or even sometimes "Label Switching Routers, + or LSRs") connected in a general topology [RFC3945]. + + Recovery typically involves the activation of a recovery (or + alternate) LSP when a failure is encountered in the working LSP. + + A working or recovery LSP is characterized by an ingress interface, + an egress interface, and a set of intermediate nodes and spans + through which the LSP is routed. The working and recovery LSPs are + typically resource disjoint (e.g., node and/or span disjoint). This + ensures that a single failure will not affect both the working and + recovery LSPs. + + A bi-directional span between neighboring nodes is usually realized + as a pair of unidirectional spans. Therefore, the end-to-end path + for a bi-directional LSP consists of a series of bi-directional + segments (i.e., Sub-Network Connections, or SNCs, in the ITU-T + terminology) between the source and destination nodes, traversing + intermediate nodes. + + + + + + +Mannie & Papadimitriou Informational [Page 3] + +RFC 4427 GMPLS Recovery Terminology March 2006 + + +2. Contributors + + This document is the result of a joint effort by the CCAMP Working + Group Protection and Restoration design team. The following are the + authors that contributed to the present document: + + Deborah Brungard (AT&T) + Rm. D1-3C22 - 200 S. Laurel Ave. + Middletown, NJ 07748, USA + + EMail: dbrungard@att.com + + + Sudheer Dharanikota + + EMail: sudheer@ieee.org + + + Jonathan P. Lang (Sonos) + 506 Chapala Street + Santa Barbara, CA 93101, USA + + EMail: jplang@ieee.org + + + Guangzhi Li (AT&T) + 180 Park Avenue, + Florham Park, NJ 07932, USA + + EMail: gli@research.att.com + + + Eric Mannie + Perceval + Rue Tenbosch, 9 + 1000 Brussels + Belgium + + Phone: +32-2-6409194 + EMail: eric.mannie@perceval.net + + + Dimitri Papadimitriou (Alcatel) + Francis Wellesplein, 1 + B-2018 Antwerpen, Belgium + + EMail: dimitri.papadimitriou@alcatel.be + + + + +Mannie & Papadimitriou Informational [Page 4] + +RFC 4427 GMPLS Recovery Terminology March 2006 + + + Bala Rajagopalan + Microsoft India Development Center + Hyderabad, India + + EMail: balar@microsoft.com + + + Yakov Rekhter (Juniper) + 1194 N. Mathilda Avenue + Sunnyvale, CA 94089, USA + + EMail: yakov@juniper.net + +3. Conventions Used in this Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +4. Recovery Terminology Common to Protection and Restoration + + This section defines the following general terms common to both + protection and restoration (i.e., recovery). In addition, most of + these terms apply to end-to-end, segment, and span LSP recovery. + Note that span recovery does not protect the nodes at each end of the + span, otherwise end-to-end or segment LSP recovery should be used. + + The terminology and the definitions were originally taken from + [G.808.1]. However, for generalization, the following language, + which is not directly related to recovery, has been adapted to GMPLS + and the common IETF terminology: + + An LSP is used as a generic term to designate either an SNC (Sub- + Network Connection) or an NC (Network Connection) in ITU-T + terminology. The ITU-T uses the term transport entity to designate + either a link, an SNC, or an NC. The term "Traffic" is used instead + of "Traffic Signal". The term protection or restoration "scheme" is + used instead of protection or restoration "architecture". + + The reader is invited to read [G.841] and [G.808.1] for references to + SDH protection and Generic Protection Switching terminology, + respectively. Note that restoration is not in the scope of + [G.808.1]. + + + + + + + + +Mannie & Papadimitriou Informational [Page 5] + +RFC 4427 GMPLS Recovery Terminology March 2006 + + +4.1. Working and Recovery LSP/Span + + A working LSP/span is an LSP/span transporting "normal" user traffic. + A recovery LSP/span is an LSP/span used to transport "normal" user + traffic when the working LSP/span fails. Additionally, the recovery + LSP/span may transport "extra" user traffic (i.e., pre-emptable + traffic) when normal traffic is carried over the working LSP/span. + +4.2. Traffic Types + + The different types of traffic that can be transported over an + LSP/span, in the context of this document, are defined hereafter: + + A. Normal traffic: + + User traffic that may be protected by two alternative LSPs/spans (the + working and recovery LSPs/spans). + + B. Extra traffic: + + User traffic carried over recovery resources (e.g., a recovery + LSP/span) when these resources are not being used for the recovery of + normal traffic (i.e., when the recovery resources are in standby + mode). When the recovery resources are required to recover normal + traffic from the failed working LSP/span, the extra traffic is pre- + empted. Extra traffic is not protected by definition, but may be + restored. Moreover, extra traffic does not need to commence or be + terminated at the ends of the LSPs/spans that it uses. + + C. Null traffic: + + Traffic carried over the recovery LSP/span if it is not used to carry + normal or extra traffic. Null traffic can be any kind of traffic + that conforms to the signal structure of the specific layer, and it + is ignored (not selected) at the egress of the recovery LSP/span. + +4.3. LSP/Span Protection and Restoration + + The following subtle distinction is generally made between the terms + "protection" and "restoration", even though these terms are often + used interchangeably [RFC3386]. + + The distinction between protection and restoration is made based on + the resource allocation done during the recovery LSP/span + establishment. The distinction between different types of + restoration is made based on the level of route computation, + signaling, and resource allocation during the restoration LSP/span + establishment. + + + +Mannie & Papadimitriou Informational [Page 6] + +RFC 4427 GMPLS Recovery Terminology March 2006 + + + A. LSP/Span Protection + + LSP/span protection denotes the paradigm whereby one or more + dedicated protection LSP(s)/span(s) is/are fully established to + protect one or more working LSP(s)/span(s). + + For a protection LSP, this implies that route computation took place, + that the LSP was fully signaled all the way, and that its resources + were fully selected (i.e., allocated) and cross-connected between the + ingress and egress nodes. + + For a protection span, this implies that the span has been selected + and reserved for protection. + + Indeed, it means that no signaling takes place to establish the + protection LSP/span when a failure occurs. However, various other + kinds of signaling may take place between the ingress and egress + nodes for fault notification, to synchronize their use of the + protection LSP/span, for reversion, etc. + + B. LSP/Span Restoration + + LSP/span restoration denotes the paradigm whereby some restoration + resources may be pre-computed, signaled, and selected a priori, but + not cross-connected to restore a working LSP/span. The complete + establishment of the restoration LSP/span occurs only after a failure + of the working LSP/span, and requires some additional signaling. + + Both protection and restoration require signaling. Signaling to + establish the recovery resources and signaling associated with the + use of the recovery LSP(s)/span(s) are needed. + +4.4. Recovery Scope + + Recovery can be applied at various levels throughout the network. An + LSP may be subject to local (span), segment, and/or end-to-end + recovery. + + Local (span) recovery refers to the recovery of an LSP over a link + between two nodes. + + End-to-end recovery refers to the recovery of an entire LSP from its + source (ingress node end-point) to its destination (egress node end- + point). + + Segment recovery refers to the recovery over a portion of the network + of a segment LSP (i.e., an SNC in the ITU-T terminology) of an end- + to-end LSP. Such recovery protects against span and/or node failure + + + +Mannie & Papadimitriou Informational [Page 7] + +RFC 4427 GMPLS Recovery Terminology March 2006 + + + over a particular portion of the network that is traversed by an + end-to-end LSP. + +4.5. Recovery Domain + + A recovery domain is defined as a set of nodes and spans, over which + one or more recovery schemes are provided. A recovery domain served + by one single recovery scheme is referred to as a "single recovery + domain", while a recovery domain served by multiple recovery schemes + is referred to as a "multi recovery domain". + + The recovery operation is contained within the recovery domain. A + GMPLS recovery domain must be entirely contained within a GMPLS + domain. A GMPLS domain (defined as a set of nodes and spans + controlled by GMPLS) may contain multiple recovery domains. + +4.6. Recovery Types + + The different recovery types can be classified depending on the + number of recovery LSPs/spans that are protecting a given number of + working LSPs/spans. The definitions given hereafter are from the + point of view of a working LSP/span that needs to be protected by a + recovery scheme. + + A. 1+1 type: dedicated protection + + One dedicated protection LSP/span protects exactly one working + LSP/span, and the normal traffic is permanently duplicated at the + ingress node on both the working and protection LSPs/spans. No extra + traffic can be carried over the protection LSP/span. + + This type is applicable to LSP/span protection, but not to LSP/span + restoration. + + B. 0:1 type: unprotected + + No specific recovery LSP/span protects the working LSP/span. + However, the working LSP/span can potentially be restored through any + alternate available route/span, with or without any pre-computed + restoration route. Note that no resources are pre-established for + this recovery type. + + This type is applicable to LSP/span restoration, but not to LSP/span + protection. Span restoration can be achieved, for instance, by + moving all the LSPs transported over a failed span to a dynamically + selected span. + + + + + +Mannie & Papadimitriou Informational [Page 8] + +RFC 4427 GMPLS Recovery Terminology March 2006 + + + C. 1:1 type: dedicated recovery with extra traffic + + One specific recovery LSP/span protects exactly one specific working + LSP/span, but the normal traffic is transmitted over only one LSP + (working or recovery) at a time. Extra traffic can be transported + using the recovery LSP/span resources. + + This type is applicable to LSP/span protection and LSP restoration, + but not to span restoration. + + D. 1:N (N > 1) type: shared recovery with extra traffic + + A specific recovery LSP/span is dedicated to the protection of up to + N working LSPs/spans. The set of working LSPs/spans is explicitly + identified. Extra traffic can be transported over the recovery + LSP/span. All these LSPs/spans must start and end at the same nodes. + + Sometimes, the working LSPs/spans are assumed to be resource disjoint + in the network so that they do not share any failure probability, but + this is not mandatory. Obviously, if more than one working LSP/span + in the set of N are affected by some failure(s) at the same time, the + traffic on only one of these failed LSPs/spans may be recovered over + the recovery LSP/span. Note that N can be arbitrarily large (i.e., + infinite). The choice of N is a policy decision. + + This type is applicable to LSP/span protection and LSP restoration, + but not to span restoration. + + Note: a shared recovery where each recovery resource can be shared by + a maximum of X LSPs/spans is not defined as a recovery type but as a + recovery scheme. The choice of X is a network resource management + policy decision. + + E. M:N (M, N > 1, N >= M) type: + + A set of M specific recovery LSPs/spans protects a set of up to N + specific working LSPs/spans. The two sets are explicitly identified. + Extra traffic can be transported over the M recovery LSPs/spans when + available. All the LSPs/spans must start and end at the same nodes. + + Sometimes, the working LSPs/spans are assumed to be resource disjoint + in the network so that they do not share any failure probability, but + this is not mandatory. Obviously, if several working LSPs/spans in + the set of N are concurrently affected by some failure(s), the + traffic on only M of these failed LSPs/spans may be recovered. Note + that N can be arbitrarily large (i.e., infinite). The choice of N + and M is a policy decision. + + + + +Mannie & Papadimitriou Informational [Page 9] + +RFC 4427 GMPLS Recovery Terminology March 2006 + + + This type is applicable to LSP/span protection and LSP restoration, + but not to span restoration. + +4.7. Bridge Types + + A bridge is the function that connects the normal traffic and extra + traffic to the working and recovery LSP/span. + + A. Permanent bridge + + Under a 1+1 type, the bridge connects the normal traffic to both the + working and protection LSPs/spans. This type of bridge is not + applicable to restoration types. There is, of course, no extra + traffic connected to the recovery LSP/span. + + B. Broadcast bridge + + For 1:N and M:N types, the bridge permanently connects the normal + traffic to the working LSP/span. In the event of recovery switching, + the normal traffic is additionally connected to the recovery + LSP/span. Extra traffic is either not connected or connected to the + recovery LSP/span. + + C. Selector bridge + + For 1:N and M:N types, the bridge connects the normal traffic to + either the working or the recovery LSP/span. Extra traffic is either + not connected or connected to the recovery LSP/span. + +4.8. Selector Types + + A selector is the function that extracts the normal traffic from + either the working or the recovery LSP/span. Extra traffic is either + extracted from the recovery LSP/span, or is not extracted. + + A. Selective selector + + Is a selector that extracts the normal traffic from either the + working LSP/span output or the recovery LSP/span output. + + B. Merging selector + + For 1:N and M:N protection types, the selector permanently extracts + the normal traffic from both the working and recovery LSP/span + + outputs. This alternative works only in combination with a selector + bridge. + + + + +Mannie & Papadimitriou Informational [Page 10] + +RFC 4427 GMPLS Recovery Terminology March 2006 + + +4.9. Recovery GMPLS Nodes + + This section defines the GMPLS nodes involved during recovery. + + A. Ingress GMPLS node of an end-to-end LSP/segment LSP/span + + The ingress node of an end-to-end LSP/segment LSP/span is where the + normal traffic may be bridged to the recovery end-to-end LSP/segment + LSP/span. Also known as source node in the ITU-T terminology. + + B. Egress GMPLS node of an end-to-end LSP/segment LSP/span + + The egress node of an end-to-end LSP/segment LSP/span is where the + normal traffic may be selected from either the working or the + recovery end-to-end LSP/segment LSP/span. Also known as sink node in + the ITU-T terminology. + + C. Intermediate GMPLS node of an end-to-end LSP/segment LSP + + A node along either the working or recovery end-to-end LSP/segment + LSP route between the corresponding ingress and egress nodes. Also + known as intermediate node in the ITU-T terminology. + +4.10. Switch-over Mechanism + + A switch-over is an action that can be performed at both the bridge + and the selector. This action is as follows: + + A. For the selector: + + The action of selecting normal traffic from the recovery LSP/span + rather than from the working LSP/span. + + B. For the bridge: + + In case of permanent connection to the working LSP/span, the action + of connecting or disconnecting the normal traffic to or from the + recovery LSP/span. In case of non-permanent connection to the + working LSP/span, the action of connecting the normal traffic to the + recovery LSP/span. + +4.11. Reversion operations + + A revertive recovery operation refers to a recovery switching + operation, where the traffic returns to (or remains on) the working + LSP/span when the switch-over requests are terminated (i.e., when the + working LSP/span has recovered from the failure). + + + + +Mannie & Papadimitriou Informational [Page 11] + +RFC 4427 GMPLS Recovery Terminology March 2006 + + + Therefore, a non-revertive recovery switching operation is when the + traffic does not return to the working LSP/span when the switch-over + requests are terminated. + +4.12. Failure Reporting + + This section gives (for information) several signal types commonly + used in transport planes to report a failure condition. Note that + fault reporting may require additional signaling mechanisms. + + A. Signal Degrade (SD): a signal indicating that the associated data + has degraded. + + B. Signal Fail (SF): a signal indicating that the associated data has + failed. + + C. Signal Degrade Group (SDG): a signal indicating that the + associated group data has degraded. + + D. Signal Fail Group (SFG): a signal indicating that the associated + group has failed. + + Note: SDG and SFG definitions are under discussion at the ITU-T. + +4.13. External commands + + This section defines several external commands, typically issued by + an operator through the Network Management System (NMS)/Element + Management System (EMS), that can be used to influence or command the + recovery schemes. + + A. Lockout of recovery LSP/span: + + A configuration action, initiated externally, that results in the + recovery LSP/span being temporarily unavailable to transport traffic + (either normal or extra traffic). + + B. Lockout of normal traffic: + + A configuration action, initiated externally, that results in the + normal traffic being temporarily not allowed to be routed over its + recovery LSP/span. Note that in this case extra-traffic is still + allowed on the recovery LSP/span. + + + + + + + + +Mannie & Papadimitriou Informational [Page 12] + +RFC 4427 GMPLS Recovery Terminology March 2006 + + + C. Freeze: + + A configuration action, initiated externally, that prevents any + switch-over action from being taken, and, as such, freezes the + current state. + + D. Forced switch-over for normal traffic: + + A switch-over action, initiated externally, that switches normal + traffic to the recovery LSP/span, unless an equal or higher priority + switch-over command is in effect. + + E. Manual switch-over for normal traffic: + + A switch-over action, initiated externally, that switches normal + traffic to the recovery LSP/span, unless a fault condition exists on + other LSPs/spans (including the recovery LSP/span) or an equal or + higher priority switch-over command is in effect. + + F. Manual switch-over for recovery LSP/span: + + A switch-over action, initiated externally, that switches normal + traffic to the working LSP/span, unless a fault condition exists on + the working LSP/span or an equal or higher priority switch-over + command is in effect. + + G. Clear: + + An action, initiated externally, that clears the active external + command. + +4.14. Unidirectional versus Bi-Directional Recovery Switching + + A. Unidirectional recovery switching: + + A recovery switching mode in which, for a unidirectional fault (i.e., + a fault affecting only one direction of transmission), only the + normal traffic transported in the affected direction (of the LSP or + span) is switched to the recovery LSP/span. + + B. Bi-directional recovery switching: + + A recovery switching mode in which, for a unidirectional fault, the + normal traffic in both directions (of the LSP or span), including the + affected direction and the unaffected direction, are switched to the + recovery LSP/span. + + + + + +Mannie & Papadimitriou Informational [Page 13] + +RFC 4427 GMPLS Recovery Terminology March 2006 + + +4.15. Full versus Partial Span Recovery Switching + + Bulk LSP recovery is initiated upon reception of either span failure + notification or bulk failure notification of the S LSPs carried by + this span. In either case, the corresponding recovery switching + actions are performed at the LSP level, such that the ratio between + the number of recovery switching messages and the number of recovered + LSP (in one given direction) is minimized. If this ratio equals 1, + one refers to full span recovery; otherwise, if this ratio is greater + than 1, one refers to partial span recovery. + + A. Full Span Recovery + + All the S LSP carried over a given span are recovered under span + failure condition. Full span recovery is also referred to as "bulk + recovery". + + B. Partial Span Recovery + + Only a subset s of the S LSP carried over a given span is recovered + under span failure condition. Both selection criteria of the + entities belonging to this subset, and the decision concerning the + recovery of the remaining (S - s) LSP, are based on local policy. + +4.16. Recovery Schemes Related Time and Durations + + This section gives several typical timing definitions that are of + importance for recovery schemes. + + A. Detection time: + + The time between the occurrence of the fault or degradation and its + detection. Note that this is a rather theoretical time because, in + practice, this is difficult to measure. + + B. Correlation time: + + The time between the detection of the fault or degradation and the + reporting of the signal fail or degrade. This time is typically used + in correlating related failures or degradations. + + C. Notification time: + + The time between the reporting of the signal fail or degrade and the + reception of the indication of this event by the entities that decide + on the recovery switching operation(s). + + + + + +Mannie & Papadimitriou Informational [Page 14] + +RFC 4427 GMPLS Recovery Terminology March 2006 + + + D. Recovery Switching time: + + The time between the initialization of the recovery switching + operation and the moment the normal traffic is selected from the + recovery LSP/span. + + E. Total Recovery time: + + The total recovery time is defined as the sum of the detection, the + correlation, the notification, and the recovery switching time. + + F. Wait To Restore time: + + A period of time that must elapse after a recovered fault before an + LSP/span can be used again to transport the normal traffic and/or to + select the normal traffic from. + + Note: the hold-off time is defined as the time between the reporting + of signal fail or degrade, and the initialization of the recovery + switching operation. This is useful when multiple layers of recovery + are being used. + +4.17. Impairment + + A defect or performance degradation, which may lead to SF or SD + trigger. + +4.18. Recovery Ratio + + The quotient of the actual recovery bandwidth divided by the traffic + bandwidth that is intended to be protected. + +4.19. Hitless Protection Switch-over + + Protection switch-over, which does not cause data loss, data + duplication, data disorder, or bit errors upon recovery switching + action. + +4.20. Network Survivability + + The set of capabilities that allows a network to restore affected + traffic in the event of a failure. The degree of survivability is + determined by the network's capability to survive single and multiple + failures. + + + + + + + +Mannie & Papadimitriou Informational [Page 15] + +RFC 4427 GMPLS Recovery Terminology March 2006 + + +4.21. Survivable Network + + A network that is capable of restoring traffic in the event of a + failure. + +4.22. Escalation + + A network survivability action caused by the impossibility of the + survivability function in lower layers. + +5. Recovery Phases + + It is commonly accepted that recovery implies that the following + generic operations need to be performed when an LSP/span or a node + failure occurs: + + - Phase 1: Failure Detection + + The action of detecting the impairment (defect of performance + degradation) as a defect condition and the consequential activation + of SF or SD trigger to the control plane (through internal interface + with the transport plane). Thus, failure detection (which should + occur at the transport layer closest to the failure) is the only + phase that cannot be achieved by the control plane alone. + + - Phase 2: Failure Localization (and Isolation) + + Failure localization provides, to the deciding entity, information + about the location (and thus the identity) of the transport plane + entity that causes the LSP(s)/span(s) failure. The deciding entity + can then make an accurate decision to achieve finer grained recovery + switching action(s). + + - Phase 3: Failure Notification + + Failure notification phase is used 1) to inform intermediate nodes + that LSP(s)/span(s) failure has occurred and has been detected and 2) + to inform the recovery deciding entities (which can correspond to any + intermediate or end-point of the failed LSP/span) that the + corresponding LSP/span is not available. + + - Phase 4: Recovery (Protection or Restoration) + + See Section 4.3. + + - Phase 5: Reversion (Normalization) + + See Section 4.11. + + + +Mannie & Papadimitriou Informational [Page 16] + +RFC 4427 GMPLS Recovery Terminology March 2006 + + + The combination of Failure Detection and Failure Localization and + Notification is referred to as Fault Management. + +5.1. Entities Involved During Recovery + + The entities involved during the recovery operations can be defined + as follows; these entities are parts of ingress, egress, and + intermediate nodes, as defined previously: + + A. Detecting Entity (Failure Detection): + + An entity that detects a failure or group of failures; thus providing + a non-correlated list of failures. + + B. Reporting Entity (Failure Correlation and Notification): + + An entity that can make an intelligent decision on fault correlation + and report the failure to the deciding entity. Fault reporting can + be automatically performed by the deciding entity detecting the + failure. + + C. Deciding Entity (part of the failure recovery decision process): + + An entity that makes the recovery decision or selects the recovery + resources. This entity communicates the decision to the impacted + LSPs/spans with the recovery actions to be performed. + + D. Recovering Entity (part of the failure recovery activation + process): + + An entity that participates in the recovery of the LSPs/spans. + + The process of moving failed LSPs from a failed (working) span to a + protection span must be initiated by one of the nodes that terminates + the span, e.g., A or B. The deciding (and recovering) entity is + referred to as the "master", while the other node is called the + "slave" and corresponds to a recovering only entity. + + Note: The determination of the master and the slave may be based on + configured information or protocol-specific requirements. + +6. Protection Schemes + + This section clarifies the multiple possible protection schemes and + the specific terminology for the protection. + + + + + + +Mannie & Papadimitriou Informational [Page 17] + +RFC 4427 GMPLS Recovery Terminology March 2006 + + +6.1. 1+1 Protection + + 1+1 protection has one working LSP/span, one protection LSP/span, and + a permanent bridge. At the ingress node, the normal traffic is + permanently bridged to both the working and protection LSP/span. At + the egress node, the normal traffic is selected from the better of + the two LSPs/spans. + + Due to the permanent bridging, the 1+1 protection does not allow an + unprotected extra traffic signal to be provided. + +6.2. 1:N (N >= 1) Protection + + 1:N protection has N working LSPs/spans that carry normal traffic and + 1 protection LSP/span that may carry extra-traffic. + + At the ingress, the normal traffic is either permanently connected to + its working LSP/span and may be connected to the protection LSP/span + (case of broadcast bridge), or is connected to either its working + LSP/span or the protection LSP/span (case of selector bridge). At + the egress node, the normal traffic is selected from either its + working or protection LSP/span. + + Unprotected extra traffic can be transported over the protection + LSP/span whenever the protection LSP/span is not used to carry a + normal traffic. + +6.3. M:N (M, N > 1, N >= M) Protection + + M:N protection has N working LSPs/spans carrying normal traffic and M + protection LSP/span that may carry extra-traffic. + + At the ingress, the normal traffic is either permanently connected to + its working LSP/span and may be connected to one of the protection + LSPs/spans (case of broadcast bridge), or is connected to either its + working LSP/span or one of the protection LSPs/spans (case of + selector bridge). At the egress node, the normal traffic is selected + from either its working or one of the protection LSP/span. + + Unprotected extra traffic can be transported over the M protection + LSP/span whenever the protection LSPs/spans is not used to carry a + normal traffic. + + + + + + + + + +Mannie & Papadimitriou Informational [Page 18] + +RFC 4427 GMPLS Recovery Terminology March 2006 + + +6.4. Notes on Protection Schemes + + All protection types are either uni- or bi-directional; obviously, + the latter applies only to bi-directional LSPs/spans and requires + coordination between the ingress and egress node during protection + switching. + + All protection types except 1+1 unidirectional protection switching + require a communication channel between the ingress and the egress + node. + + In the GMPLS context, span protection refers to the full or partial + span recovery of the LSPs carried over that span (see Section 4.15). + +7. Restoration Schemes + + This section clarifies the multiple possible restoration schemes and + the specific terminology for the restoration. + +7.1. Pre-Planned LSP Restoration + + Also referred to as pre-planned LSP re-routing. Before failure + detection and/or notification, one or more restoration LSPs are + instantiated between the same ingress-egress node pair as the working + LSP. Note that the restoration resources must be pre-computed, must + be signaled, and may be selected a priori, but may not cross- + connected. Thus, the restoration LSP is not able to carry any + extra-traffic. + + The complete establishment of the restoration LSP (i.e., activation) + occurs only after failure detection and/or notification of the + working LSP and requires some additional restoration signaling. + Therefore, this mechanism protects against working LSP failure(s) but + requires activation of the restoration LSP after failure occurrence. + After the ingress node has activated the restoration LSP, the latter + can carry the normal traffic. + + Note: when each working LSP is recoverable by exactly one restoration + LSP, one refers also to 1:1 (pre-planned) re-routing without extra- + traffic. + +7.1.1. Shared-Mesh Restoration + + "Shared-mesh" restoration is defined as a particular case of pre- + planned LSP re-routing that reduces the restoration resource + requirements by allowing multiple restoration LSPs (initiated from + distinct ingress nodes) to share common resources (including links + and nodes.) + + + +Mannie & Papadimitriou Informational [Page 19] + +RFC 4427 GMPLS Recovery Terminology March 2006 + + +7.2. LSP Restoration + + Also referred to as LSP re-routing. The ingress node switches the + normal traffic to an alternate LSP that is signaled and fully + established (i.e., cross-connected) after failure detection and/or + notification. The alternate LSP path may be computed after failure + detection and/or notification. In this case, one also refers to + "Full LSP Re-routing." + + The alternate LSP is signaled from the ingress node and may reuse the + intermediate node's resources of the working LSP under failure + condition (and may also include additional intermediate nodes.) + +7.2.1. Hard LSP Restoration + + Also referred to as hard LSP re-routing. A re-routing operation + where the LSP is released before the full establishment of an + alternate LSP (i.e., break-before-make). + +7.2.2. Soft LSP Restoration + + Also referred to as soft LSP re-routing. A re-routing operation + where the LSP is released after the full establishment of an + alternate LSP (i.e., make-before-break). + +8. Security Considerations + + Security considerations are detailed in [RFC4428] and [RFC4426]. + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +9.2. Informative References + + [RFC3386] Lai, W. and D. McDysan, "Network Hierarchy and + Multilayer Survivability", RFC 3386, November 2002. + + [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching + (GMPLS) Architecture", RFC 3945, October 2004. + + [RFC4426] Lang, J., Rajagopalan B., and D.Papadimitriou, Editors, + "Generalized Multiprotocol Label Switching (GMPLS) + Recovery Functional Specification", RFC 4426, March + 2006. + + + +Mannie & Papadimitriou Informational [Page 20] + +RFC 4427 GMPLS Recovery Terminology March 2006 + + + [RFC4428] Papadimitriou D. and E.Mannie, Editors, "Analysis of + Generalized Multi-Protocol Label Switching (GMPLS)-based + Recovery Mechanisms (including Protection and + Restoration)", RFC 4428, March 2006. + + For information on the availability of the following documents, + please see http://www.itu.int + + [G.808.1] ITU-T, "Generic Protection Switching - Linear trail and + subnetwork protection," Recommendation G.808.1, December + 2003. + + [G.841] ITU-T, "Types and Characteristics of SDH Network + Protection Architectures," Recommendation G.841, October + 1998. + +10. Acknowledgements + + Many thanks to Adrian Farrel for having thoroughly review this + document. + +Editors' Addresses + + Eric Mannie + Perceval + Rue Tenbosch, 9 + 1000 Brussels + Belgium + + Phone: +32-2-6409194 + EMail: eric.mannie@perceval.net + + + Dimitri Papadimitriou + Alcatel + Francis Wellesplein, 1 + B-2018 Antwerpen, Belgium + + Phone: +32 3 240-8491 + EMail: dimitri.papadimitriou@alcatel.be + + + + + + + + + + + +Mannie & Papadimitriou Informational [Page 21] + +RFC 4427 GMPLS Recovery Terminology March 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Mannie & Papadimitriou Informational [Page 22] + |