GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4427

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:
  1. 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.
  1. 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).
  1. 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.
  1. Phase 4: Recovery (Protection or Restoration)
 See Section 4.3.
  1. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4427.txt · Last modified: 2006/03/30 23:23 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki