draft-ietf-ccamp-gmpls-recovery-terminology-04.txt   draft-ietf-ccamp-gmpls-recovery-terminology-05.txt 
CCAMP Working Group CCAMP GMPLS P&R Design Team CCAMP Working Group CCAMP GMPLS P&R Design Team
Internet Draft Internet Draft
Category: Standards Track Eric Mannie (Editor) Category: Informational Eric Mannie (Editor)
Expiration Date: October 2004 Dimitri Papadimitriou (Editor) Expiration Date: March 2005 Dimitri Papadimitriou (Editor)
April 2004 October 2004
Recovery (Protection and Restoration) Terminology Recovery (Protection and Restoration) Terminology
for Generalized Multi-Protocol Label Switching (GMPLS) for Generalized Multi-Protocol Label Switching (GMPLS)
draft-ietf-ccamp-gmpls-recovery-terminology-04.txt draft-ietf-ccamp-gmpls-recovery-terminology-05.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 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other documents
time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html. http://www.ietf.org/ietf/1id-abstracts.txt.
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: Copyright Notice
http://www.ietf.org/ietf/1id-guidelines.txt
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document defines a common terminology for Generalized Multi- This document defines a common terminology for Generalized Multi-
Protocol Label Switching (GMPLS) based recovery mechanisms (i.e. Protocol Label Switching (GMPLS) based recovery mechanisms (i.e.
protection and restoration). The terminology is independent of the protection and restoration). The terminology is independent of the
underlying transport technologies covered by GMPLS. underlying transport technologies covered by GMPLS.
E.Mannie, D.Papadimitriou et al. - Standards Track 1 E.Mannie, D.Papadimitriou et al. - Informational 1
Table of Contents Table of Contents
Status of this Memo .............................................. 1 Status of this Memo .............................................. 1
Abstract ......................................................... 1 Abstract ......................................................... 1
Table of Contents ................................................ 2 Table of Contents ................................................ 2
1. Contributors .................................................. 3 1. Contributors .................................................. 3
2. Introduction .................................................. 3 2. Introduction .................................................. 3
3. Conventions used in this document ............................. 4 3. Conventions used in this document ............................. 4
4. Recovery Terminology Common to Protection and Restoration ..... 4 4. Recovery Terminology Common to Protection and Restoration ..... 4
skipping to change at line 71 skipping to change at line 78
4.8 Selector Types ............................................... 9 4.8 Selector Types ............................................... 9
4.9 Recovery GMPLS Nodes ........................................ 10 4.9 Recovery GMPLS Nodes ........................................ 10
4.10 Switch-over Mechanism ...................................... 10 4.10 Switch-over Mechanism ...................................... 10
4.11 Reversion operations ....................................... 10 4.11 Reversion operations ....................................... 10
4.12 Failure Reporting .......................................... 11 4.12 Failure Reporting .......................................... 11
4.13 External commands .......................................... 11 4.13 External commands .......................................... 11
4.14 Unidirectional versus Bi-Directional Recovery Switching .... 12 4.14 Unidirectional versus Bi-Directional Recovery Switching .... 12
4.15 Full versus Partial Span Recovery Switching ................ 12 4.15 Full versus Partial Span Recovery Switching ................ 12
4.16 Recovery Schemes Related Time and Durations ................ 13 4.16 Recovery Schemes Related Time and Durations ................ 13
4.17 Impairment ................................................. 13 4.17 Impairment ................................................. 13
4.18 Recovery Ratio ............................................. 13 4.18 Recovery Ratio ............................................. 14
4.19 Hitless Protection Switch-over ............................. 14 4.19 Hitless Protection Switch-over ............................. 14
4.20 Network Survivability ...................................... 14 4.20 Network Survivability ...................................... 14
4.21 Survivable Network ......................................... 14 4.21 Survivable Network ......................................... 14
4.22 Escalation ................................................. 14 4.22 Escalation ................................................. 14
5. Recovery Phases .............................................. 14 5. Recovery Phases .............................................. 14
5.1 Entities Involved During Recovery ........................... 15 5.1 Entities Involved During Recovery ........................... 15
6. Protection Schemes ........................................... 16 6. Protection Schemes ........................................... 16
6.1 1+1 Protection .............................................. 16 6.1 1+1 Protection .............................................. 16
6.2 1:N (N >= 1) Protection ..................................... 16 6.2 1:N (N >= 1) Protection ..................................... 16
6.3 M:N (M, N > 1, N >= M) Protection ........................... 16 6.3 M:N (M, N > 1, N >= M) Protection ........................... 16
6.4 Notes on Protection Schemes ................................. 16 6.4 Notes on Protection Schemes ................................. 16
7. Restoration Schemes .......................................... 17 7. Restoration Schemes .......................................... 17
7.1 Pre-planned LSP Restoration ................................. 17 7.1 Pre-planned LSP Restoration ................................. 17
7.1.1 Shared-Mesh Restoration ................................... 17 7.1.1 Shared-Mesh Restoration ................................... 17
7.2 LSP Restoration ............................................. 17 7.2 LSP Restoration ............................................. 18
7.2.1 Hard LSP Restoration ...................................... 18 7.2.1 Hard LSP Restoration ...................................... 18
7.2.2 Soft LSP Restoration ...................................... 18 7.2.2 Soft LSP Restoration ...................................... 18
8. Security Considerations ...................................... 18 8. Security Considerations ...................................... 18
9. Intellectual Property Consideration .......................... 18 9. References ................................................... 18
9.1 IPR Disclosure Acknowledgement .............................. 18 9.1 Normative References ........................................ 18
10. References .................................................. 19 9.2 Informative References ...................................... 18
10.1 Normative References ....................................... 19 10. Acknowledgments ............................................. 19
10.2 Informative References ..................................... 19 11. Editor's Address ............................................ 19
11. Acknowledgments ............................................. 20 Intellectual Property Statement ................................. 20
12. Editor's Addresses .......................................... 20 Disclaimer of Validity .......................................... 20
E.Mannie, D.Papadimitriou et al.- Standards Track 2 E.Mannie, D.Papadimitriou et al.- Expires March 2005 2
Copyright Statement ............................................. 20
1. Contributors 1. Contributors
This document is the result of the CCAMP Working Group Protection This document is the result of the CCAMP Working Group Protection
and Restoration design team joint effort. The following are the and Restoration design team joint effort. The following are the
authors that contributed to the present memo: authors that contributed to the present document:
Deborah Brungard (AT&T) Deborah Brungard (AT&T)
Rm. D1-3C22 - 200 S. Laurel Ave. Rm. D1-3C22 - 200 S. Laurel Ave.
Middletown, NJ 07748, USA Middletown, NJ 07748, USA
EMail: dbrungard@att.com EMail: dbrungard@att.com
Sudheer Dharanikota Sudheer Dharanikota
EMail: sudheer@ieee.org EMail: sudheer@ieee.org
Jonathan P. Lang (Rincon Networks) Jonathan P. Lang (Rincon Networks)
skipping to change at line 151 skipping to change at line 159
Protocol Label Switching (GMPLS) based recovery mechanisms (i.e. Protocol Label Switching (GMPLS) based recovery mechanisms (i.e.
protection and restoration) that are under consideration by the protection and restoration) that are under consideration by the
CCAMP Working Group. CCAMP Working Group.
The terminology proposed in this document is independent of the The terminology proposed in this document is independent of the
underlying transport technologies and borrows from the G.808.1 ITU-T underlying transport technologies and borrows from the G.808.1 ITU-T
Recommendation [G.808.1] and from the G.841 ITU-T Recommendation Recommendation [G.808.1] and from the G.841 ITU-T Recommendation
[G.841]. The restoration terminology and concepts have been gathered [G.841]. The restoration terminology and concepts have been gathered
from numerous sources including IETF drafts. from numerous sources including IETF drafts.
E.Mannie, D.Papadimitriou et al.- Standards Track 3 E.Mannie, D.Papadimitriou et al.- Expires March 2005 3
In the context of this document, the term "recovery" denotes both In the context of this document, the term "recovery" denotes both
protection and restoration. The specific terms "protection" and protection and restoration. The specific terms "protection" and
"restoration" will only be used when differentiation is required. "restoration" will only be used when differentiation is required.
Note that this document focuses on the terminology for the recovery This document focuses on the terminology for the recovery of Label
of LSPs controlled by a GMPLS control plane. We focus on end-to-end, Switched Paths (LSPs) controlled by a GMPLS control plane. The
segment, and span (i.e. link) Label Switched Path (LSP) recovery. proposed terminology applies to end-to-end, segment, and span (i.e.
Terminology for control plane recovery is not in the scope of this link) recovery. Note that the terminology for recovery of the
document. control plane itself is not in the scope of this document.
Protection and restoration of switched LSPs under tight time Protection and restoration of switched LSPs under tight time
constraints is a challenging problem. This is particularly relevant constraints is a challenging problem. This is particularly relevant
to optical networks that consist of Time Division Multiplex (TDM) to optical networks that consist of Time Division Multiplex (TDM)
and/or all-optical (photonic) cross-connects referred to as GMPLS and/or all-optical (photonic) cross-connects referred to as GMPLS
nodes (or simply nodes, or even sometimes "Label Switching Routers, nodes (or simply nodes, or even sometimes "Label Switching Routers,
or LSRs") connected in a general topology [GMPLS-ARCH]. or LSRs") connected in a general topology [GMPLS-ARCH].
Recovery typically involves the activation of a recovery (or Recovery typically involves the activation of a recovery (or
alternate) LSP when a failure is encountered in the working (or alternate) LSP when a failure is encountered in the working (or
skipping to change at line 204 skipping to change at line 212
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 does not protect the nodes at each end of the 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. 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.808.1]. However, for generalization, the following language that [G.808.1]. However, for generalization, the following language that
E.Mannie, D.Papadimitriou et al.- Standards Track 4 E.Mannie, D.Papadimitriou et al.- Expires March 2005 4
is not directly related to recovery has been adapted to GMPLS and is not directly related to recovery has been adapted to GMPLS and
the common IETF terminology: the 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".
skipping to change at line 258 skipping to change at line 266
terminated at the ends of the LSPs/spans that it uses. terminated at the ends of the LSPs/spans that it uses.
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.
E.Mannie, D.Papadimitriou et al.- Standards Track 5 E.Mannie, D.Papadimitriou et al.- Expires March 2005 5
4.3 LSP/Span Protection and Restoration 4.3 LSP/Span Protection and Restoration
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 [RFC3386]. used interchangeably [RFC3386].
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
skipping to change at line 312 skipping to change at line 320
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.
4.4 Recovery Scope 4.4 Recovery Scope
Recovery can be applied at various levels throughout the network. An Recovery can be applied at various levels throughout the network. An
LSP may be subject to local (span), segment, and/or end-to-end LSP may be subject to local (span), segment, and/or end-to-end
recovery. recovery.
E.Mannie, D.Papadimitriou et al.- Standards Track 6 E.Mannie, D.Papadimitriou et al.- Expires March 2005 6
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. between two nodes.
End-to-end recovery refers to the recovery of an entire LSP from its 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- source (ingress node end-point) to its destination (egress node end-
point). point).
Segment recovery refers to the recovery over a portion of the 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 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 an end-to-end LSP. Such recovery protects against span and/or node
skipping to change at line 365 skipping to change at line 373
restoration. restoration.
B. 0:1 type: unprotected B. 0:1 type: unprotected
No specific recovery LSP/span protects the working LSP/span. No specific recovery LSP/span protects the working LSP/span.
However, the working LSP/span can potentially be restored through However, the working LSP/span can potentially be restored through
any alternate available route/span, with or without any pre-computed any alternate available route/span, with or without any pre-computed
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.
E.Mannie, D.Papadimitriou et al.- Standards Track 7 E.Mannie, D.Papadimitriou et al.- Expires March 2005 7
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
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
(working or recovery) at a time. Extra traffic can be transported (working or recovery) at a time. Extra traffic can be transported
skipping to change at line 418 skipping to change at line 426
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
E.Mannie, D.Papadimitriou et al.- Standards Track 8 E.Mannie, D.Papadimitriou et al.- Expires March 2005 8
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.
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.
skipping to change at line 469 skipping to change at line 477
Is a selector that extracts the normal traffic from either the Is a selector that extracts the normal traffic from either the
working LSP/span output or the recovery LSP/span output. working LSP/span output or the recovery LSP/span output.
B. Merging selector B. Merging selector
For 1:N and M:N protection types, the selector permanently extracts For 1:N and M:N protection types, the selector permanently extracts
the normal traffic from both the working and recovery LSP/span the normal traffic from both the working and recovery LSP/span
outputs. This alternative works only in combination with a selector outputs. This alternative works only in combination with a selector
bridge. bridge.
E.Mannie, D.Papadimitriou et al.- Standards Track 9 E.Mannie, D.Papadimitriou et al.- Expires March 2005 9
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
normal traffic may be bridged to the recovery end-to-end LSP/segment 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. LSP/span. Also known as source node in the ITU-T terminology.
skipping to change at line 523 skipping to change at line 531
A revertive recovery operation refers to a recovery switching A revertive recovery operation refers to a recovery switching
operation, where the traffic returns to (or remains on) the working operation, where the traffic returns to (or remains on) the working
LSP/span if the switch-over requests are terminated; i.e. when the LSP/span if the switch-over requests are terminated; i.e. when the
working LSP/span has recovered from the failure. working LSP/span has recovered from the failure.
Therefore a non-revertive recovery switching operation is when the Therefore a non-revertive recovery switching operation is when the
traffic does not return to the working LSP/span if the switch-over traffic does not return to the working LSP/span if the switch-over
requests are terminated. requests are terminated.
E.Mannie, D.Papadimitriou et al.- Standards Track 10 E.Mannie, D.Papadimitriou et al.- Expires March 2005 10
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.
skipping to change at line 578 skipping to change at line 586
state. state.
D. Forced switch-over for normal traffic: D. Forced switch-over for normal traffic:
A switch-over action initiated externally that switches normal A switch-over action initiated externally that switches normal
traffic to the recovery LSP/span, unless an equal or higher priority traffic to the recovery LSP/span, unless an equal or higher priority
switch-over command is in effect. switch-over command is in effect.
E. Manual switch-over for normal traffic: E. Manual switch-over for normal traffic:
E.Mannie, D.Papadimitriou et al.- Standards Track 11 E.Mannie, D.Papadimitriou et al.- Expires March 2005 11
A switch-over action initiated externally that switches normal A switch-over action initiated externally that switches normal
traffic to the recovery LSP/span, unless a fault condition exists on traffic to the recovery LSP/span, unless a fault condition exists on
other LSPs/spans (including the recovery LSP/span) or an equal or other LSPs/spans (including the recovery LSP/span) or an equal or
higher priority switch-over command is in effect. higher priority switch-over command is in effect.
F. Manual switch-over for recovery LSP/span: F. Manual switch-over for recovery LSP/span:
A switch-over action initiated externally that switches normal A switch-over action initiated externally that switches normal
traffic to the working LSP/span, unless a fault condition exists on traffic to the working LSP/span, unless a fault condition exists on
the working LSP/span or an equal or higher priority switch-over the working LSP/span or an equal or higher priority switch-over
skipping to change at line 631 skipping to change at line 639
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
E.Mannie, D.Papadimitriou et al.- Standards Track 12 E.Mannie, D.Papadimitriou et al.- Expires March 2005 12
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.
skipping to change at line 684 skipping to change at line 692
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.
Note: the hold-off time is defined as the time between the reporting Note: the hold-off time is defined as the time between the reporting
of signal fail or degrade, and the initialization of the recovery of signal fail or degrade, and the initialization of the recovery
switching operation. This is useful when multiple layers of recovery switching operation. This is useful when multiple layers of recovery
are being used. are being used.
4.17 Impairment 4.17 Impairment
E.Mannie, D.Papadimitriou et al.- Standards Track 13 E.Mannie, D.Papadimitriou et al.- Expires March 2005 13
A defect or performance degradation, which may lead to SF or SD A defect or performance degradation, which may lead to SF or SD
trigger. trigger.
4.18 Recovery Ratio 4.18 Recovery Ratio
The quotient of the actually recovery bandwidth divided by the The quotient of the actually recovery bandwidth divided by the
traffic bandwidth which is intended to be protected. traffic bandwidth which is intended to be protected.
4.19 Hitless Protection Switch-over 4.19 Hitless Protection Switch-over
skipping to change at line 737 skipping to change at line 745
with the transport plane). Thus, failure detection (that should with the transport plane). Thus, failure detection (that should
occur at the transport layer closest to the failure) is the only occur at the transport layer closest to the failure) is the only
phase that can not be achieved by the control plane alone. phase that can not be achieved by the control plane alone.
- Phase 2: Failure Localization (and Isolation) - Phase 2: Failure Localization (and Isolation)
Failure localization provides to the deciding entity information Failure localization provides to the deciding entity information
about the location (and so the identity) of the transport plane about the location (and so the identity) of the transport plane
entity that causes the LSP(s)/span(s) failure. The deciding entity entity that causes the LSP(s)/span(s) failure. The deciding entity
E.Mannie, D.Papadimitriou et al.- Standards Track 14 E.Mannie, D.Papadimitriou et al.- Expires March 2005 14
can then take accurate decision to achieve finer grained recovery can then take accurate decision to achieve finer grained recovery
switching action(s). switching action(s).
- Phase 3: Failure Notification - Phase 3: Failure Notification
Failure notification phase is used 1) to inform intermediate nodes Failure notification phase is used 1) to inform intermediate nodes
that LSP(s)/span(s) failure has occurred and has been detected 2) to that LSP(s)/span(s) failure has occurred and has been detected 2) to
inform the recovery deciding entities (which can correspond to any inform the recovery deciding entities (which can correspond to any
intermediate or end-point of the failed LSP/span) that the intermediate or end-point of the failed LSP/span) that the
corresponding LSP/span is not available. corresponding LSP/span is not available.
skipping to change at line 789 skipping to change at line 797
An entity that makes the recovery decision or selects the recovery An entity that makes the recovery decision or selects 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.
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.
E.Mannie, D.Papadimitriou et al.- Standards Track 15 E.Mannie, D.Papadimitriou et al.- Expires March 2005 15
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
skipping to change at line 843 skipping to change at line 851
M:N protection has N working LSPs/spans carrying normal traffic and M:N protection has N working LSPs/spans carrying normal traffic and
M protection LSP/span that may carry extra-traffic. M protection LSP/span that may carry extra-traffic.
At the ingress, the normal traffic is either permanently connected At the ingress, the normal traffic is either permanently connected
to its working LSP/span and may be connected to one of the to its working LSP/span and may be connected to one of the
protection LSPs/spans (case of broadcast bridge), or is connected to protection LSPs/spans (case of broadcast bridge), or is connected to
either its working or one of the protection LSPs/spans (case of either its working or one of the protection LSPs/spans (case of
selector bridge). At the egress node, the normal traffic is selected selector bridge). At the egress node, the normal traffic is selected
from either its working or one of the protection LSP/span. from either its working or one of the protection LSP/span.
E.Mannie, D.Papadimitriou et al.- Standards Track 16 E.Mannie, D.Papadimitriou et al.- Expires March 2005 16
Unprotected extra traffic can be transported over the M protection Unprotected extra traffic can be transported over the M protection
LSP/span whenever the protection LSPs/spans is not used to carry a LSP/span whenever the protection LSPs/spans is not used to carry a
normal traffic. normal traffic.
6.4 Notes on Protection Schemes 6.4 Notes on Protection Schemes
All protection types are either uni- or bi-directional, obviously, All protection types are either uni- or bi-directional, obviously,
the latter applies only to bi-directional LSP/span and requires the latter applies only to bi-directional LSP/span and requires
coordination between the ingress and egress node during protection coordination between the ingress and egress node during protection
switching. switching.
skipping to change at line 895 skipping to change at line 903
Note: when each working LSP is recoverable by exactly one Note: when each working LSP is recoverable by exactly one
restoration LSP, one refers also to 1:1 (pre-planned) re-routing restoration LSP, one refers also to 1:1 (pre-planned) re-routing
without extra-traffic. without extra-traffic.
7.1.1 Shared-Mesh Restoration 7.1.1 Shared-Mesh Restoration
"Shared-mesh" restoration is defined as a particular case of pre- "Shared-mesh" restoration is defined as a particular case of pre-
planned LSP re-routing that reduces the restoration resource planned LSP re-routing that reduces the restoration resource
requirements by allowing multiple restoration LSPs (initiated from requirements by allowing multiple restoration LSPs (initiated from
E.Mannie, D.Papadimitriou et al.- Standards Track 17 E.Mannie, D.Papadimitriou et al.- Expires March 2005 17
distinct ingress nodes) to share common resources (including links distinct ingress nodes) to share common resources (including links
and nodes.) and nodes.)
7.2 LSP Restoration 7.2 LSP Restoration
Also referred to as LSP re-routing. The ingress node switches the Also referred to as LSP re-routing. The ingress node switches the
normal traffic to an alternate LSP signaled and fully established normal traffic to an alternate LSP signaled and fully established
(i.e. cross-connected) after failure detection and/or notification. (i.e. cross-connected) after failure detection and/or notification.
The alternate LSP path may be computed after failure detection The alternate LSP path may be computed after failure detection
and/or notification. In this case, one also refers to "Full LSP Re- and/or notification. In this case, one also refers to "Full LSP Re-
skipping to change at line 929 skipping to change at line 937
Also referred to as soft LSP re-routing. A re-routing operation Also referred to as soft LSP re-routing. A re-routing operation
where the LSP is released after the full establishment of an where the LSP is released after the full establishment of an
alternate LSP (i.e. make-before-break). 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. Intellectual Property Consideration 9. References
The IETF takes no position regarding the validity or scope of any 9.1 Normative References
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 [RFC2026] S.Bradner, "The Internet Standards Process -- Revision
assurances of licenses to be made available, or the result of an 3", BCP 9, RFC 2026, October 1996.
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.
E.Mannie, D.Papadimitriou et al.- Standards Track 18 [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate
The IETF invites any interested party to bring to its attention Requirement Levels," BCP 14, RFC 2119, March 1997.
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.
9.1 IPR Disclosure Acknowledgement [RFC3667] S.Bradner, "IETF Rights in Contributions", BCP 78,
RFC 3667, February 2004.
By submitting this Internet-Draft, I certify that any applicable [RFC3668] S.Bradner, Ed., "Intellectual Property Rights in IETF
patent or other IPR claims of which I am aware have been Technology", BCP 79, RFC 3668, February 2004.
disclosed, and any of which I become aware will be disclosed, in
accordance with RFC 3668.
10. References 9.2 Informative References
10.1 Normative References E.Mannie, D.Papadimitriou et al.- Expires March 2005 18
[GMPLS-ARCH] E.Mannie (Editor), "Generalized MPLS Architecture,"
Internet Draft, Work in progress, draft-ietf-ccamp-
gmpls-architecture-07.txt, May 2003.
[RFC2026] S.Bradner, "The Internet Standards Process -- Revision [RFC3386] W.S.Lai, et al., "Network Hierarchy and Multilayer
3", BCP 9, RFC 2026, October 1996. Survivability," RFC 3386, November 2002.
[RFC2119] S.Bradner, "Key words for use in RFCs to Indicate [T1.105] ANSI, "Synchronous Optical Network (SONET): Basic
Requirement Levels," BCP 14, RFC 2119, March 1997. Description Including Multiplex Structure, Rates, and
Formats," ANSI T1.105, January 2001.
10.2 Informative References For information on the availability of the following documents,
please see http://www.itu.int
[G.707] ITU-T, "Network Node Interface for the Synchronous [G.707] ITU-T, "Network Node Interface for the Synchronous
Digital Hierarchy (SDH)," Recommendation G.707, October Digital Hierarchy (SDH)," Recommendation G.707, October
2000. 2000.
[G.783] ITU-T, "Characteristics of Synchronous Digital [G.783] ITU-T, "Characteristics of Synchronous Digital
Hierarchy (SDH) Equipment Functional Blocks," Hierarchy (SDH) Equipment Functional Blocks,"
Recommendation G.783, October 2000. Recommendation G.783, October 2000.
[G.806] ITU-T, "Characteristics of Transport Equipment ¡ [G.806] ITU-T, "Characteristics of Transport Equipment û
Description Methodology and Generic Functionality," Description Methodology and Generic Functionality,"
Recommendation G.806, October 2000. Recommendation G.806, October 2000.
[G.808.1] ITU-T, "Generic Protection Switching ¡ Linear trail and [G.808.1] ITU-T, "Generic Protection Switching û Linear trail and
subnetwork protection," Recommendation G.808.1, subnetwork protection," Recommendation G.808.1,
December 2003. December 2003.
[G.841] ITU-T, "Types and Characteristics of SDH Network [G.841] ITU-T, "Types and Characteristics of SDH Network
Protection Architectures," Recommendation G.841, 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.
[GMPLS-ARCH] E.Mannie (Editor), "Generalized MPLS Architecture," 10. Acknowledgments
Internet Draft, Work in progress, draft-ietf-ccamp-
gmpls-architecture-07.txt, May 2003.
E.Mannie, D.Papadimitriou et al.- Standards Track 19
[RFC3386] W.S.Lai, et al., "Network Hierarchy and Multilayer
Survivability," RFC 3386, November 2002.
[T1.105] ANSI, "Synchronous Optical Network (SONET): Basic
Description Including Multiplex Structure, Rates, and
Formats," ANSI T1.105, January 2001.
11. Acknowledgments
Many thanks to Adrian Farrel for having thoroughly review this Many thanks to Adrian Farrel for having thoroughly review this
document. document.
12. Editor's Addresses 11. Editor's Addresses
Eric Mannie Eric Mannie
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-8491 Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel.be EMail: dimitri.papadimitriou@alcatel.be
E.Mannie, D.Papadimitriou et al.- Standards Track 20 E.Mannie, D.Papadimitriou et al.- Expires March 2005 19
Full Copyright Statement Intellectual Property Statement
Copyright (C) The Internet Society (2004). This document is subject The IETF takes no position regarding the validity or scope of any
to the rights, licenses and restrictions contained in BCP 78 and Intellectual Property Rights or other rights that might be claimed
except as set forth therein, the authors retain all their rights. 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.
Disclaimer of Validity
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
E.Mannie, D.Papadimitriou et al.- Standards Track 21 Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
E.Mannie, D.Papadimitriou et al.- Expires March 2005 20
 End of changes. 

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