draft-ietf-ccamp-gmpls-recovery-terminology-01.txt   draft-ietf-ccamp-gmpls-recovery-terminology-02.txt 
CCAMP Working Group CCAMP GMPLS P&R Design Team CCAMP Working Group CCAMP GMPLS P&R Design Team
Internet Draft Internet Draft
Expiration Date: May 2003 Eric Mannie (Consult) Editor Category: Standard Track Eric Mannie (Editor)
Dimitri Papadimitriou (Alcatel) Editor Expiration Date: November 2003 Dimitri Papadimitriou (Editor)
Deborah Brungard (AT&T)
Sudheer Dharanikota (Consult)
Jonathan Lang (Calient)
Guangzhi Li (AT&T)
Bala Rajagopalan (Tellium)
Yakov Rekhter (Juniper)
November 2002 May 2003
Recovery (Protection and Restoration) Terminology for GMPLS Recovery (Protection and Restoration) Terminology
for Generalized Multi-Protocol Label Switching (GMPLS)
draft-ietf-ccamp-gmpls-recovery-terminology-01.txt draft-ietf-ccamp-gmpls-recovery-terminology-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at line 45 skipping to change at line 39
http://www.ietf.org/1id-abstracts.html. http://www.ietf.org/1id-abstracts.html.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
For potential updates to the above required-text see: For potential updates to the above required-text see:
http://www.ietf.org/ietf/1id-guidelines.txt http://www.ietf.org/ietf/1id-guidelines.txt
1. Abstract 1. Abstract
This document defines a common terminology for Generalized MPLS This document defines a common terminology for Generalized Multi-
(GMPLS) based recovery mechanisms (i.e. protection and restoration) Protocol Label Switching (GMPLS) based recovery mechanisms (i.e.
that are under consideration by the CCAMP Working Group. protection and restoration) that are under consideration by the
CCAMP Working Group. The proposed terminology is intended to be
independent of the underlying transport technologies covered by
GMPLS.
E.Mannie, D.Papadimitriou et al. 1 E.Mannie, D.Papadimitriou et al. 1
2. Conventions used in this document 2. Contributors
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This document is the result of the CCAMP Working Group Protection
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in and Restoration design team joint effort. The following are the
this document are to be interpreted as described in RFC-2119 [1]. authors that contributed to the present memo:
Deborah Brungard (AT&T)
Rm. D1-3C22 - 200 S. Laurel Ave.
Middletown, NJ 07748, USA
E-mail: dbrungard@att.com
Sudheer Dharanikota (Consult)
E-mail: sudheer@ieee.org
Jonathan P. Lang (Rincon Networks)
E-mail: jplang@ieee.org
Guangzhi Li (AT&T)
180 Park Avenue,
Florham Park, NJ 07932, USA
E-mail: gli@research.att.com
Eric Mannie (Consult)
Email: eric_mannie@hotmail.com
Dimitri Papadimitriou (Alcatel)
Fr. Wellesplein, 1
B-2018, Antwerpen, Belgium
Email: dimitri.papadimitriou@alcatel.be
Bala Rajagopalan (Tellium)
2 Crescent Place - P.O. Box 901
Oceanport, NJ 07757-0901, USA
E-mail: braja@tellium.com
Yakov Rekhter (Juniper)
1194 N. Mathilda Avenue
Sunnyvale, CA 94089, USA
E-mail: yakov@juniper.net
3. Introduction 3. Introduction
This document defines a common terminology for Generalized MPLS This document defines a common terminology for Generalized MPLS
(GMPLS) based recovery mechanisms (i.e. protection and restoration) (GMPLS) based recovery mechanisms (i.e. protection and restoration)
that are under consideration by the CCAMP Working Group. that are under consideration by the CCAMP Working Group.
The terminology proposed in this document is intended to be The terminology proposed in this document is intended to be
independent of the underlying transport technologies and borrows independent of the underlying transport technologies and borrows
from an ITU-T ongoing effort (G.gps - Generic Protection Switching from an ITU-T ongoing effort, the Draft Recommendation [G.808.1]
[G.gps]) and from the G.841 ITU-T Recommendation. The restoration (ex. G.GPS - Generic Protection Switching) and from the G.841 ITU-T
terminology and concepts have been gathered from numerous sources Recommendation. The restoration terminology and concepts have been
including IETF drafts. gathered from numerous sources including IETF drafts.
E.Mannie, D.Papadimitriou et al.- Internet Draft - November 2003 2
In the context of this document we will use the term "recovery" to In the context of this document we will use the term "recovery" to
denote both protection and restoration. The specific terms denote both protection and restoration. The specific terms
"protection" and "restoration" will only be used when "protection" and "restoration" will only be used when
differentiation is required. differentiation is required.
Note that this document focuses on the terminology for the recovery Note that this document focuses on the terminology for the recovery
of LSPs controlled by a GMPLS control plane. We focus on end-to-end, of LSPs controlled by a GMPLS control plane. We focus on end-to-end,
segment and span (i.e. link) LSP recovery. Terminology for control segment and span (i.e. link) LSP recovery. Terminology for control
plane recovery is not in the scope of this document. plane recovery is not in the scope of this document.
skipping to change at line 105 skipping to change at line 137
ensures that a single failure will not affect both the working and ensures that a single failure will not affect both the working and
recovery LSPs. recovery LSPs.
A bi-directional span between neighboring nodes is usually realized A bi-directional span between neighboring nodes is usually realized
as a pair of unidirectional spans. The end-to-end path for a bi- as a pair of unidirectional spans. The end-to-end path for a bi-
directional LSP therefore consists of a series of bi-directional directional LSP therefore consists of a series of bi-directional
segments (i.e. Sub-Network Connections, or SNCs, in the ITU-T segments (i.e. Sub-Network Connections, or SNCs, in the ITU-T
terminology) between the source and destination nodes, traversing terminology) between the source and destination nodes, traversing
intermediate nodes. intermediate nodes.
E.Mannie, D.Papadimitriou et al.- Internet Draft û May 2003 2 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 RFC-2119 [1].
4. Recovery Terminology Common to Protection and Restoration 4. Recovery Terminology Common to Protection and Restoration
This section defines the following general terms common to both This section defines the following general terms common to both
protection and restoration (i.e. recovery). In addition, most of protection and restoration (i.e. recovery). In addition, most of
these terms apply to end-to-end, segment and span LSP recovery. Note these terms apply to end-to-end, segment and span LSP recovery. Note
that span recovery assumes that the nodes at each end of the span that span recovery does not protect the nodes at each end of the
did not fail, otherwise end-to-end or segment LSP recovery is used. span, otherwise end-to-end or segment LSP recovery should be used.
The terminology and the definitions have been originally taken from The terminology and the definitions have been originally taken from
G.gps. However, for generalization, the following language that is G.808.1. However, for generalization, the following language that is
E.Mannie, D.Papadimitriou et al.- Internet Draft - November 2003 3
not directly related to recovery has been adapted to GMPLS and the not directly related to recovery has been adapted to GMPLS and the
common IETF terminology: common IETF terminology:
An LSP is used as a generic term to designate either an SNC (Sub- An LSP is used as a generic term to designate either an SNC (Sub-
Network Connection) or an NC (Network Connection) in ITU-T Network Connection) or an NC (Network Connection) in ITU-T
terminology. The ITU-T uses the term transport entity to designate 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 either a link, an SNC or an NC. The term "Traffic" is used instead
of "Traffic Signal". The term protection or restoration "scheme" is of "Traffic Signal". The term protection or restoration "scheme" is
used instead of protection or restoration "architecture". used instead of protection or restoration "architecture".
The reader is invited to read G.841 and G.gps for references to SDH The reader is invited to read G.841 and G.808.1 for references to
protection and ITU-T generic protection terminology. Note that SDH protection and ITU-T generic protection terminology. Note that
restoration is not in the scope of G.gps. restoration is not in the scope of G.808.1.
4.1 Working and Recovery LSP/Span 4.1 Working and Recovery LSP/Span
A working LSP/span is an LSP/span transporting "normal" user A working LSP/span is an LSP/span transporting "normal" user
traffic. A recovery LSP/span is an LSP/span used to transport traffic. A recovery LSP/span is an LSP/span used to transport
"normal" user traffic when the working LSP/span fails. Additionally, "normal" user traffic when the working LSP/span fails. Additionally,
the recovery LSP/span may transport "extra" user traffic (i.e. pre- the recovery LSP/span may transport "extra" user traffic (i.e. pre-
emptable traffic) when normal traffic is carried over the working emptable traffic) when normal traffic is carried over the working
LSP/span. LSP/span.
skipping to change at line 160 skipping to change at line 198
B. Extra traffic: B. Extra traffic:
User traffic carried over recovery resources (e.g. a recovery User traffic carried over recovery resources (e.g. a recovery
LSP/span) when these resources are not being used for the 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 of normal traffic; i.e. when the recovery resources are in standby
mode. When the recovery resources are required to recover normal mode. When the recovery resources are required to recover normal
traffic from the failed working LSP/span, the extra traffic is pre- traffic from the failed working LSP/span, the extra traffic is pre-
empted. Extra traffic is not protected by definition, but may be empted. Extra traffic is not protected by definition, but may be
restored. restored.
E.Mannie, D.Papadimitriou et al.- Internet Draft û May 2003 3
C. Null traffic: C. Null traffic:
Traffic carried over the recovery LSP/span if it is not used to 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 carry normal or extra traffic. Null traffic can be any kind of
traffic that conforms to the signal structure of the specific layer, traffic that conforms to the signal structure of the specific layer,
and it is ignored (not selected) at the egress of the recovery and it is ignored (not selected) at the egress of the recovery
LSP/span. LSP/span.
4.3 LSP/Span Protection and Restoration 4.3 LSP/Span Protection and Restoration
E.Mannie, D.Papadimitriou et al.- Internet Draft - November 2003 4
The following subtle distinction is generally made between the terms The following subtle distinction is generally made between the terms
"protection" and "restoration", even though these terms are often "protection" and "restoration", even though these terms are often
used interchangeably [TEWG]. used interchangeably [TEWG].
The distinction between protection and restoration is made based on The distinction between protection and restoration is made based on
the resource allocation done during the recovery LSP/span the resource allocation done during the recovery LSP/span
establishment. The distinction between different types of establishment. The distinction between different types of
restoration is made based on the level of route computation, restoration is made based on the level of route computation,
signaling and resource allocation done during the restoration signaling and resource allocation done during the restoration
LSP/span establishment. LSP/span establishment.
skipping to change at line 215 skipping to change at line 253
resources may be pre-computed, signaled and selected a priori, but resources may be pre-computed, signaled and selected a priori, but
not cross-connected to restore a working LSP/span. The complete not cross-connected to restore a working LSP/span. The complete
establishment of the restoration LSP/span occurs only after a establishment of the restoration LSP/span occurs only after a
failure of the working LSP/span, and requires some additional failure of the working LSP/span, and requires some additional
signaling. signaling.
Both protection and restoration require signaling. Signaling to Both protection and restoration require signaling. Signaling to
establish the recovery resources and signaling associated with the establish the recovery resources and signaling associated with the
use of the recovery LSP(s)/span(s) are needed. use of the recovery LSP(s)/span(s) are needed.
E.Mannie, D.Papadimitriou et al.- Internet Draft û May 2003 4
4.4 Recovery Scope 4.4 Recovery Scope
Recovery can be applied at various levels throughout the network. Recovery can be applied at various levels throughout the network.
Local (span) recovery refers to the recovery of an LSP over a link Local (span) recovery refers to the recovery of an LSP over a link
between two nodes. Segment recovery refers to the recovery of an LSP between two nodes. Segment recovery refers to the recovery of an LSP
segment (i.e. an SNC in the ITU-T terminology) between two nodes, segment (i.e. an SNC in the ITU-T terminology) between two nodes,
i.e. the boundary nodes of the segment. End-to-end recovery refers i.e. the boundary nodes of the segment. End-to-end recovery refers
E.Mannie, D.Papadimitriou et al.- Internet Draft - November 2003 5
to the recovery of an entire LSP from its source to its destination. to the recovery of an entire LSP from its source to its destination.
An LSP may be subject to local (span), segment, and/or end-to-end An LSP may be subject to local (span), segment, and/or end-to-end
recovery. recovery.
4.5 Recovery Domain 4.5 Recovery Domain
A recovery domain is defined as a set of nodes and spans over which 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 one or more recovery schemes are provided. A recovery domain served
by one single recovery scheme is referred to as a "single recovery by one single recovery scheme is referred to as a "single recovery
domain", while a recovery domain served by multiple recovery schemes domain", while a recovery domain served by multiple recovery schemes
is referred to as a "multi recovery domain". 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 may contain multiple recovery domains.
4.6 Recovery Types 4.6 Recovery Types
The different recovery types can be classified depending on the The different recovery types can be classified depending on the
number of recovery LSPs/spans that are protecting a given number of number of recovery LSPs/spans that are protecting a given number of
working LSPs/spans. The definitions given hereafter are from the 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 point of view of a working LSP/span that needs to be protected by a
recovery scheme. recovery scheme.
A. 1+1 type: dedicated protection A. 1+1 type: dedicated protection
skipping to change at line 269 skipping to change at line 311
restoration route. Note that there are no resources pre-established restoration route. Note that there are no resources pre-established
for this recovery type. for this recovery type.
This type is applicable to LSP/span restoration, but not to LSP/span This type is applicable to LSP/span restoration, but not to LSP/span
protection. Span restoration can be for instance achieved by moving protection. Span restoration can be for instance achieved by moving
all the LSPs transported over of a failed span to a dynamically all the LSPs transported over of a failed span to a dynamically
selected span. selected span.
C. 1:1 type: dedicated recovery with extra traffic C. 1:1 type: dedicated recovery with extra traffic
E.Mannie, D.Papadimitriou et al.- Internet Draft û May 2003 5
One specific recovery LSP/span protects exactly one specific working One specific recovery LSP/span protects exactly one specific working
LSP/span but the normal traffic is transmitted only over one LSP LSP/span but the normal traffic is transmitted only over one LSP
E.Mannie, D.Papadimitriou et al.- Internet Draft - November 2003 6
(working or recovery) at a time. Extra traffic can be transported (working or recovery) at a time. Extra traffic can be transported
using the recovery LSP/span resources. using the recovery LSP/span resources.
This type is applicable to LSP/span protection and LSP restoration, This type is applicable to LSP/span protection and LSP restoration,
but not to span restoration. but not to span restoration.
D. 1:N (N>1) type: shared recovery with extra traffic D. 1:N (N>1) type: shared recovery with extra traffic
A specific recovery LSP/span is dedicated to the protection of up to 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 N working LSPs/spans. The set of working LSPs/spans is explicitly
skipping to change at line 302 skipping to change at line 345
decision. decision.
This type is applicable to LSP/span protection and LSP restoration, This type is applicable to LSP/span protection and LSP restoration,
but not to span restoration. but not to span restoration.
Note: a shared recovery where each recovery resource can be shared 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 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 as a recovery scheme. The choice of X is a network resource
management policy decision. management policy decision.
E. M:N (M, N > 1; M <= N) type: E. M:N (M, N > 1; M =< N) type:
A set of M specific recovery LSPs/spans protects a set of up to N 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. specific working LSPs/spans. The two sets are explicitly identified.
Extra traffic can be transported over the M recovery LSPs/spans when 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. available. All the LSPs/spans must start and end at the same nodes.
Sometimes, the working LSPs/spans are assumed to be resource Sometimes, the working LSPs/spans are assumed to be resource
disjoint in the network so that they do not share any failure disjoint in the network so that they do not share any failure
probability, but this is not mandatory. Obviously, if several probability, but this is not mandatory. Obviously, if several
working LSPs/spans in the set of N are concurrently affected by some 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 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 recovered. Note that N can be arbitrarily large (i.e. infinite). The
choice of N and M is a policy decision. choice of N and M is a policy decision.
This type is applicable to LSP/span protection and LSP restoration, This type is applicable to LSP/span protection and LSP restoration,
but not to span restoration. but not to span restoration.
E.Mannie, D.Papadimitriou et al.- Internet Draft û May 2003 6
4.7 Bridge Types 4.7 Bridge Types
A bridge is the function that connects the normal traffic and extra A bridge is the function that connects the normal traffic and extra
traffic to the working and recovery LSP/span. traffic to the working and recovery LSP/span.
E.Mannie, D.Papadimitriou et al.- Internet Draft - November 2003 7
A. Permanent bridge A. Permanent bridge
Under a 1+1 type, the bridge connects the normal traffic to both the 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 working and protection LSPs/spans. This type of bridge is not
applicable to restoration types. There is of course no extra traffic applicable to restoration types. There is of course no extra traffic
connected to the recovery LSP/span. connected to the recovery LSP/span.
B. Broadcast bridge B. Broadcast bridge
For 1:N and M:N types, the bridge permanently connects the normal For 1:N and M:N types, the bridge permanently connects the normal
skipping to change at line 373 skipping to change at line 415
outputs. This alternative works only in combination with a selector outputs. This alternative works only in combination with a selector
bridge. bridge.
4.9 Recovery GMPLS Nodes 4.9 Recovery GMPLS Nodes
This section defines the GMPLS nodes involved during recovery. This section defines the GMPLS nodes involved during recovery.
A. Ingress GMPLS node of an end-to-end LSP/segment LSP/span 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 The ingress node of an end-to-end LSP/segment LSP/span is where the
working traffic may be bridged to the recovery end-to-end 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.
E.Mannie, D.Papadimitriou et al.- Internet Draft û May 2003 7
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 B. Egress GMPLS node of an end-to-end LSP/segment LSP/span
E.Mannie, D.Papadimitriou et al.- Internet Draft - November 2003 8
The egress node of an end-to-end LSP/segment LSP/span is where the The egress node of an end-to-end LSP/segment LSP/span is where the
working traffic may be selected from either the working or 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 recovery end-to-end LSP/segment LSP/span. Also known as sink node in
the ITU-T terminology. the ITU-T terminology.
C. Intermediate GMPLS node of an end-to-end LSP/segment LSP 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 A node along either the working or recovery end-to-end LSP/segment
LSP route between the corresponding ingress and egress nodes. Also LSP route between the corresponding ingress and egress nodes. Also
known as intermediate node in the ITU-T terminology. known as intermediate node in the ITU-T terminology.
4.10 Switching Mechanism 4.10 Switching Mechanism
skipping to change at line 430 skipping to change at line 470
4.12 Failure Reporting 4.12 Failure Reporting
This section gives (for information) several signal types commonly This section gives (for information) several signal types commonly
used in transport planes to report a failure condition. Note that used in transport planes to report a failure condition. Note that
fault reporting may require additional signaling mechanisms. fault reporting may require additional signaling mechanisms.
A. Signal Degrade (SD): a signal indicating that the associated data A. Signal Degrade (SD): a signal indicating that the associated data
has degraded. has degraded.
E.Mannie, D.Papadimitriou et al.- Internet Draft û May 2003 8
B. Signal Fail (SF): a signal indicating that the associated data B. Signal Fail (SF): a signal indicating that the associated data
has failed. has failed.
E.Mannie, D.Papadimitriou et al.- Internet Draft - November 2003 9
C. Signal Degrade Group (SDG): a signal indicating that the C. Signal Degrade Group (SDG): a signal indicating that the
associated group data has degraded (under discussion at the ITU-T). associated group data has degraded.
D. Signal Fail Group (SFG): a signal indicating that the associated D. Signal Fail Group (SFG): a signal indicating that the associated
group has failed (under discussion at the ITU-T). group has failed.
Note: SDG and SFG definitions are under discussion at the ITU-T.
4.13 External commands 4.13 External commands
This section defines several external commands, typically issued by This section defines several external commands, typically issued by
an operator through the NMS/EMS, which can be used to influence or an operator through the NMS/EMS, which can be used to influence or
command the recovery schemes. command the recovery schemes.
A. Lockout of recovery LSP/span: A. Lockout of recovery LSP/span:
A configuration action initiated externally that results in the A configuration action initiated externally that results in the
skipping to change at line 476 skipping to change at line 518
the recovery LSP/span, unless an equal or higher priority switch the recovery LSP/span, unless an equal or higher priority switch
command is in effect. command is in effect.
E. Manual switch for normal traffic: E. Manual switch for normal traffic:
A switch action initiated externally that switches normal traffic to A switch action initiated externally that switches normal traffic to
the recovery LSP/span, unless a fault condition exists on other the recovery LSP/span, unless a fault condition exists on other
LSPs/spans (including the recovery LSP/span) or an equal or higher LSPs/spans (including the recovery LSP/span) or an equal or higher
priority switch command is in effect. priority switch command is in effect.
F. Manual switch for recovery LSP/span:
A switch 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 command is in effect.
G. Clear:
E.Mannie, D.Papadimitriou et al.- Internet Draft - November 2003 10
An action initiated externally that clears the active external
command.
4.14 Unidirectional versus Bi-Directional Recovery Switching 4.14 Unidirectional versus Bi-Directional Recovery Switching
A. Unidirectional recovery switching: A. Unidirectional recovery switching:
A recovery switching mode in which, for a unidirectional fault (i.e. A recovery switching mode in which, for a unidirectional fault (i.e.
a fault affecting only one direction of transmission), only the a fault affecting only one direction of transmission), only the
E.Mannie, D.Papadimitriou et al.- Internet Draft û May 2003 9
normal traffic transported in the affected direction (of the LSP or normal traffic transported in the affected direction (of the LSP or
span) is switched to the recovery LSP/span. span) is switched to the recovery LSP/span.
B. Bi-directional recovery switching: B. Bi-directional recovery switching:
A recovery switching mode in which, for a unidirectional fault, the A recovery switching mode in which, for a unidirectional fault, the
normal traffic in both directions (of the LSP or span), including normal traffic in both directions (of the LSP or span), including
the affected direction and the unaffected direction, are switched to the affected direction and the unaffected direction, are switched to
the recovery LSP/span. the recovery LSP/span.
skipping to change at line 508 skipping to change at line 560
this span. In either case, the corresponding recovery switching this span. In either case, the corresponding recovery switching
actions are performed at the LSP level such that the ratio between actions are performed at the LSP level such that the ratio between
the number of recovery switching messages and the number of the number of recovery switching messages and the number of
recovered LSP (in one given direction) is minimized. If this ratio recovered LSP (in one given direction) is minimized. If this ratio
equals 1, one refers to full span recovery, otherwise, 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. is greater than 1 one refers to partial span recovery.
A. Full Span Recovery A. Full Span Recovery
All the S LSP carried over a given span are recovered under span All the S LSP carried over a given span are recovered under span
failure condition. Full span recovery is also referred to as ôbulk failure condition. Full span recovery is also referred to as "bulk
recoveryö. recovery".
B. Partial Span Recovery B. Partial Span Recovery
Only a subset s of the S LSP carried over a given span are recovered Only a subset s of the S LSP carried over a given span are recovered
under span failure condition. Both selection criteria of the under span failure condition. Both selection criteria of the
entities belonging to this subset and the decision concerning the entities belonging to this subset and the decision concerning the
recovery of the remaining (Sûs) LSP are based on local policy. recovery of the remaining (S - s) LSP are based on local policy.
4.16 Recovery Schemes Related Time and Durations 4.16 Recovery Schemes Related Time and Durations
This section gives several typical timing definitions that are of This section gives several typical timing definitions that are of
importance for recovery schemes. importance for recovery schemes.
A. Detection time: A. Detection time:
E.Mannie, D.Papadimitriou et al.- Internet Draft - November 2003 11
The time between the occurrence of the fault or degradation and its The time between the occurrence of the fault or degradation and its
detection. Note that this is a rather theoretical time since in detection. Note that this is a rather theoretical time since in
practice this is difficult to measure. practice this is difficult to measure.
B. Correlation time: B. Correlation time:
The time between detection of the fault or degradation and the The time between detection of the fault or degradation and the
reporting of the signal fail or degrade. This time is typically used reporting of the signal fail or degrade. This time is typically used
in correlating related failures or degradations. in correlating related failures or degradations.
C. Hold-off time: C. Hold-off time:
E.Mannie, D.Papadimitriou et al.- Internet Draft û May 2003 10
The time between reporting of signal fail or degrade, and the The time between reporting of signal fail or degrade, and the
initialization of the recovery switching algorithm. This is useful initialization of the recovery switching algorithm. This is useful
when multiple layers of recovery are being used. when multiple layers of recovery are being used.
D. Wait To Restore time: D. Wait To Restore time:
A period of time that must elapse from a recovered fault before an A period of time that must elapse from a recovered fault before an
LSP/span can be used again to transport the normal traffic and/or to LSP/span can be used again to transport the normal traffic and/or to
select the normal traffic from. select the normal traffic from.
skipping to change at line 578 skipping to change at line 630
4.19 Hitless Protection Switch 4.19 Hitless Protection Switch
Protection switch, which does not cause data loss, data duplication, Protection switch, which does not cause data loss, data duplication,
data disorder, or bit errors upon recovery switching action. data disorder, or bit errors upon recovery switching action.
4.20 Network Survivability 4.20 Network Survivability
The set of capabilities that allow a network to restore affected The set of capabilities that allow a network to restore affected
traffic in the event of a failure. The degree of survivability is traffic in the event of a failure. The degree of survivability is
E.Mannie, D.Papadimitriou et al.- Internet Draft - November 2003 12
determined by the networkÆs capability to survive single and determined by the networkÆs capability to survive single and
multiple failures. multiple failures.
4.21 Survivable Network 4.21 Survivable Network
A network that is capable of restoring traffic in the event of a A network that is capable of restoring traffic in the event of a
failure. failure.
4.22 Escalation 4.22 Escalation
A network survivability action caused by the impossibility of the A network survivability action caused by the impossibility of the
survivability function in lower layers. survivability function in lower layers.
E.Mannie, D.Papadimitriou et al.- Internet Draft û May 2003 11
5. Recovery Phases 5. Recovery Phases
It is commonly accepted that recovery implies that the following It is commonly accepted that recovery implies that the following
generic operations need to be performed when an LSP/span or a node generic operations need to be performed when an LSP/span or a node
failure occurs: failure occurs:
- Phase 1: Failure Detection - Phase 1: Failure Detection
TBD. The action of detecting the impairment (defect of performance
degradation) as a defect condition and consequential activation of
SF or SD trigger to the control plane (through internal interface
with the transport plane). Thus, failure detection (that should
occur at the transport layer closest to the failure) is the only
phase that can not be achieved by the control plane alone.
- Phase 2: Failure Localization and Isolation - Phase 2: Failure Localization (and Isolation)
TBD. Failure localization provides to the deciding entity information
about the location (and so the identity) of the transport plane
entity that causes the LSP(s)/span(s) failure. The deciding entity
can then take accurate decision to achieve finer grained recovery
switching action(s).
- Phase 3: Failure Notification - Phase 3: Failure Notification
TBD. Failure notification phase is used 1) to inform intermediate nodes
that LSP(s)/span(s) failure has occurred and has been detected 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) - Phase 4: Recovery (Protection or Restoration)
See above. See above.
- Phase 5: Reversion (Normalization) - Phase 5: Reversion (Normalization)
See above. See above.
E.Mannie, D.Papadimitriou et al.- Internet Draft - November 2003 13
The combination of Failure Detection and Failure Localization and The combination of Failure Detection and Failure Localization and
Notification is referred to as Fault Management. Notification is referred to as Fault Management.
5.1 Entities Involved During Recovery 5.1 Entities Involved During Recovery
The entities involved during the recovery operations can be defined The entities involved during the recovery operations can be defined
as follows; these entities are parts of ingress, egress and as follows; these entities are parts of ingress, egress and
intermediate nodes as defined previously: intermediate nodes as defined previously:
A. Detecting Entity (Failure Detection): A. Detecting Entity (Failure Detection):
skipping to change at line 646 skipping to change at line 712
and report the failure to the deciding entity. Fault reporting can and report the failure to the deciding entity. Fault reporting can
be automatically performed by the deciding entity detecting the be automatically performed by the deciding entity detecting the
failure. failure.
C. Deciding Entity (part of the failure recovery decision process): C. Deciding Entity (part of the failure recovery decision process):
An entity that makes the recovery decision or select the recovery An entity that makes the recovery decision or select the recovery
resources. This entity communicates the decision to the impacted resources. This entity communicates the decision to the impacted
LSPs/spans with the recovery actions to be performed. LSPs/spans with the recovery actions to be performed.
E.Mannie, D.Papadimitriou et al.- Internet Draft û May 2003 12
D. Recovering Entity (part of the failure recovery activation D. Recovering Entity (part of the failure recovery activation
process): process):
An entity that participates in the recovery of the LSPs/spans. An entity that participates in the recovery of the LSPs/spans.
The process of moving failed LSPs from a failed (working) span to a The process of moving failed LSPs from a failed (working) span to a
protection span must be initiated by one of the nodes terminating protection span must be initiated by one of the nodes terminating
the span, e.g. A or B. The deciding (and recovering) entity is 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 referred to as the "master" while the other node is called the
"slave" and corresponds to a recovering only entity. "slave" and corresponds to a recovering only entity.
Note: The determination of the master and the slave may be based on Note: The determination of the master and the slave may be based on
configured information or protocol specific requirements. configured information or protocol specific requirements.
6. Protection Schemes 6. Protection Schemes
This section clarifies the multiple possible protection schemes and This section clarifies the multiple possible protection schemes and
the specific terminology for the protection. the specific terminology for the protection.
To be completed with references to ITU-T protection schemes and a 6.1 1+1 protection
table summarizing the multiple ITU-T protection schemes.
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
E.Mannie, D.Papadimitriou et al.- Internet Draft - November 2003 14
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 carrying normal traffic and
1 protecting LSP/span that may carry extra-traffic.
At the ingress, 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 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 (N >= M) Protection
M:N protection has N working LSPs/spans carrying normal traffic and
M protecting LSP/span that may carry extra-traffic.
At the ingress, a 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 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.
Note1: all protection types are either uni- or bi-directional,
obviously, the latter applies only to bi-directional LSP/span and
requires coordination between the ingress and egress node during
protection switching.
Note2: all protection types except 1+1 unidirectional protection
switching require a communication channel between the ingress and
the egress node.
Note3: 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 7. Restoration Schemes
E.Mannie, D.Papadimitriou et al.- Internet Draft - November 2003 15
This section clarifies the multiple possible restoration schemes and This section clarifies the multiple possible restoration schemes and
the specific terminology for the restoration. the specific terminology for the restoration.
To be completed when an agreement on restoration scheme definitions 7.1 Pre-planned LSP Restoration
and mechanisms has been achieved in other drafts.
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 than the
working LSP. Note that the restoration resources must be pre-
computed, must be signaled and may be selected a priori, but not
cross-connected and thus are able to carry 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 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.)
7.2 LSP Restoration
Also referred to as LSP re-routing. The ingress node switches the
normal traffic to an alternate LSP signaled and fully established
(i.e. cross-connected) after failure detection and/or notification.
The alternate LSP path may be pre-computed after failure detection
and/or notification. In this case, one refers to "Full LSP Re-
routing."
The alternate LSP is signaled from the ingress node and may reuse
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).
E.Mannie, D.Papadimitriou et al.- Internet Draft - November 2003 16
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 8. Security Considerations
This document does not introduce or imply any specific security This document does not introduce or imply any specific security
consideration. consideration.
9. References 9. Intellectual Property Considerations
[RFC-2026] Bradner, S., ôThe Internet Standards Process -- This section is taken from Section 10.4 of [RFC2026].
Revision 3ö, BCP 9, RFC 2026, October 1996.
[RFC-2119] Bradner, S., ôKey words for use in RFCs to Indicate The IETF takes no position regarding the validity or scope of any
Requirement Levelsö, BCP 14, RFC 2119, March 1997. intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification
can be obtained from the IETF Secretariat.
[G.707] ITU-T, ôNetwork Node Interface for the Synchronous The IETF invites any interested party to bring to its attention any
Digital Hierarchy (SDH)ö, Recommendation G.707, October copyrights, patents or patent applications, or other proprietary
2000. rights, which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
[G.783] ITU-T, ôCharacteristics of Synchronous Digital 10. References
Hierarchy (SDH) Equipment Functional Blocksö,
Recommendation G.783, October 2000.
E.Mannie, D.Papadimitriou et al.- Internet Draft û May 2003 13 10.1 Normative References
[G.806] ITU-T, ôCharacteristics of Transport Equipment û
Description Methodology and Generic Functionalityö,
Recommendation G.806, October 2000.
[G.841] ITU-T, ôTypes and Characteristics of SDH Network [G.707] ITU-T, "Network Node Interface for the Synchronous
Protection Architecturesö, Recommendation G.841, Digital Hierarchy (SDH)," Recommendation G.707, October
2000.
[G.841] ITU-T, "Types and Characteristics of SDH Network
Protection Architectures," Recommendation G.841,
October 1998. October 1998.
[G.842] ITU-T, ôInterworking of SDH network protection [G.842] ITU-T, "Interworking of SDH network protection
architecturesö, Recommendation G.842, October 1998. architectures," Recommendation G.842, October 1998.
[G.gps] ITU-T ongoing work G.gps, "Generic Protection E.Mannie, D.Papadimitriou et al.- Internet Draft - November 2003 17
Switching", ITU-T Draft (April, 2002). [GMPLS-ARCH] E.Mannie (Editor), "Generalized MPLS Architecture,"
Internet Draft, Work in progress, draft-ietf-ccamp-
gmpls-architecture-06.txt, April 2003.
[RFC-2026] S.Bradner, "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC-2119] S.Bradner, "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, RFC 2119, March 1997.
[T1.105] ANSI, "Synchronous Optical Network (SONET): Basic [T1.105] ANSI, "Synchronous Optical Network (SONET): Basic
Description Including Multiplex Structure, Rates, and Description Including Multiplex Structure, Rates, and
Formats", ANSI T1.105, January 2001. Formats," ANSI T1.105, January 2001.
[BALA] B.Rajagopalan et al, "Signaling for Protection and 10.2 Informative References
Restoration in Optical Mesh Networks", Internet Draft,
[BALA] B.Rajagopalan et al., "Signaling for Protection and
Restoration in Optical Mesh Networks," Internet Draft,
Work in progress, draft-bala-protection-restoration- Work in progress, draft-bala-protection-restoration-
signaling-00.txt. signaling-00.txt.
[GMPLS-ARCH] E.Mannie, Editor, "Generalized MPLS Architecture", [G.783] ITU-T, "Characteristics of Synchronous Digital
Internet Draft, Work in progress, draft-ietf-ccamp- Hierarchy (SDH) Equipment Functional Blocks,"
gmpls-architecture-03.txt, August 2002. Recommendation G.783, October 2000.
[TEWG] W.S Lai, et al., "Network Hierarchy and Multilayer [G.806] ITU-T, "Characteristics of Transport Equipment û
Survivability", Internet Draft, Work in progress, Description Methodology and Generic Functionality,"
draft-ietf-tewg-restore-hierarchy-01.txt, June 2002. Recommendation G.806, October 2000.
[G.808.1] ITU-T, "Generic Protection Switching û Linear trail and
subnetwork protection," Draft Recommendation (work in
progress), Version 0.5, January 2003.
[SUDHEER] S.Dharanikota et al., "NNI Protection and restoration [SUDHEER] S.Dharanikota et al., "NNI Protection and restoration
requirements," OIF Contribution 507, 2001. requirements," OIF Contribution 507, 2001.
10. Acknowledgments [TEWG] W.S.Lai, et al., "Network Hierarchy and Multilayer
Survivability," Internet Draft, Work in progress,
Valuable comments and input were received from many people. draft-ietf-tewg-restore-hierarchy-01.txt, June 2002.
11. Author's Addresses
Deborah Brungard (AT&T)
Rm. D1-3C22
200 S. Laurel Ave.
Middletown, NJ 07748, USA
Email: dbrungard@att.com
Sudheer Dharanikota (Consulting)
Email: sudheer@ieee.org
Jonathan P. Lang 11. Acknowledgments
Calient Networks
25 Castilian
Goleta, CA 93117, USA
E.Mannie, D.Papadimitriou et al.- Internet Draft û May 2003 14 Valuable comments and input were received from many people.
Email: jplang@calient.net
Guangzhi Li (AT&T) 12. Author's Addresses
180 Park Avenue,
Florham Park, NJ 07932
Email: gli@research.att.com
973-360-7376
Eric Mannie (Consult) Eric Mannie (Consult)
Email: eric_mannie@hotmail.com Email: eric_mannie@hotmail.com
Dimitri Papadimitriou (Alcatel) Dimitri Papadimitriou (Alcatel)
Francis Wellesplein, 1 Francis Wellesplein, 1
B-2018 Antwerpen, Belgium B-2018 Antwerpen, Belgium
Phone: +32 3 240-84-91
Email: dimitri.papadimitriou@alcatel.be
Bala Rajagopalan (Tellium) E.Mannie, D.Papadimitriou et al.- Internet Draft - November 2003 18
2 Crescent Place Phone: +32 3 240-8491
P.O. Box 901 Email: dimitri.papadimitriou@alcatel.be
Oceanport, NJ 07757-0901, USA
Phone: +1 732 923 4237
Email: braja@tellium.com
Yakov Rekhter (Juniper)
Email: yakov@juniper.net
E.Mannie, D.Papadimitriou et al.- Internet Draft û May 2003 15 E.Mannie, D.Papadimitriou et al.- Internet Draft - November 2003 19
Full Copyright Statement Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved. "Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
skipping to change at line 810 skipping to change at line 982
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
E.Mannie, D.Papadimitriou et al.- Internet Draft û May 2003 16 E.Mannie, D.Papadimitriou et al.- Internet Draft - November 2003 20
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/