draft-ietf-ccamp-gmpls-recovery-terminology-00.txt   draft-ietf-ccamp-gmpls-recovery-terminology-01.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: December 2002 Eric Mannie (KPNQwest) Editor Expiration Date: May 2003 Eric Mannie (Consult) Editor
Dimitri Papadimitriou (Alcatel) Editor Dimitri Papadimitriou (Alcatel) Editor
Deborah Brungard (AT&T) Deborah Brungard (AT&T)
Sudheer Dharanikota (Nayna) Sudheer Dharanikota (Consult)
Jonathan Lang (Calient) Jonathan Lang (Calient)
Guangzhi Li (AT&T) Guangzhi Li (AT&T)
Bala Rajagopalan (Tellium) Bala Rajagopalan (Tellium)
Yakov Rekhter (Juniper) Yakov Rekhter (Juniper)
June 2002 November 2002
Recovery (Protection and Restoration) Terminology for GMPLS Recovery (Protection and Restoration) Terminology for GMPLS
draft-ietf-ccamp-gmpls-recovery-terminology-00.txt draft-ietf-ccamp-gmpls-recovery-terminology-01.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 45
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 GMPLS based recovery This document defines a common terminology for Generalized MPLS
mechanisms (i.e. protection and restoration) that are under (GMPLS) based recovery mechanisms (i.e. protection and restoration)
consideration by the CCAMP Working Group. that are under consideration by the CCAMP Working Group.
E.Mannie, D.Papadimitriou et al. 1
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [1]. this document are to be interpreted as described in RFC-2119 [1].
E.Mannie, D.Papadimitriou et al. 1
3. Introduction 3. Introduction
This document defines a common terminology for GMPLS based recovery This document defines a common terminology for Generalized MPLS
mechanisms (i.e. protection and restoration) that are under (GMPLS) based recovery mechanisms (i.e. protection and restoration)
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 (G.gps - Generic Protection Switching
[G.gps]) and from the G.841 ITU-T Recommendation. The restoration [G.gps]) and from the G.841 ITU-T Recommendation. The restoration
terminology and concepts have been gathered from numerous sources terminology and concepts have been gathered from numerous sources
including IETF drafts. including IETF drafts.
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
skipping to change at line 105 skipping to change at line 105
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 - December 2002 2 E.Mannie, D.Papadimitriou et al.- Internet Draft ű May 2003 2
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 assumes that the nodes at each end of the span
did not fail, otherwise end-to-end or segment LSP recovery is used. did not fail, otherwise end-to-end or segment LSP recovery is used.
The terminology and the definitions have been originally taken from The terminology and the definitions have been originally taken from
skipping to change at line 160 skipping to change at line 160
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 - December 2002 3 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
skipping to change at line 215 skipping to change at line 215
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 - December 2002 4 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
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
skipping to change at line 269 skipping to change at line 269
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 - December 2002 5 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
(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
skipping to change at line 320 skipping to change at line 320
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 - December 2002 6 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.
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
skipping to change at line 366 skipping to change at line 366
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.- Internet Draft - December 2002 7
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 working traffic may be bridged to the recovery end-to-end
E.Mannie, D.Papadimitriou et al.- Internet Draft ű May 2003 7
LSP/segment LSP/span. Also known as source node in the ITU-T LSP/segment LSP/span. Also known as source node in the ITU-T
terminology. 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
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 working 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.
skipping to change at line 421 skipping to change at line 421
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 requests are terminated; i.e. when the LSP/span if the switch 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 traffic does not return to the working LSP/span if the switch
requests are terminated. requests are terminated.
E.Mannie, D.Papadimitriou et al.- Internet Draft - December 2002 8
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.
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 (under discussion at the ITU-T).
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 (under discussion at the ITU-T).
4.13 External commands 4.13 External commands
skipping to change at line 477 skipping to change at line 476
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.
E.Mannie, D.Papadimitriou et al.- Internet Draft - December 2002 9
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.
4.15 Full versus Partial Span Recovery Switching 4.15 Full versus Partial Span Recovery Switching
Bulk LSP recovery is initiated upon reception on either span failure
notification or bulk failure notification of the S LSPs carried by
this span. In either case, the corresponding recovery switching
actions are performed at the LSP level such that the ratio between
the number of recovery switching messages and the number of
recovered LSP (in one given direction) is minimized. If this ratio
equals 1, one refers to full span recovery, otherwise, if this ratio
is greater than 1 one refers to partial span recovery.
A. Full Span Recovery A. Full Span Recovery
All the 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
restoration÷. recovery÷.
B. Partial Span Recovery B. Partial Span Recovery
Only a subset s of the S LSP carried over a given span are Only a subset s of the S LSP carried over a given span are recovered
recovered. Both selection criteria of the entities belonging to this under span failure condition. Both selection criteria of the
subset and the decision concerning the recovery of the remaining (Sű entities belonging to this subset and the decision concerning the
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:
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 - December 2002 10 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 583 skipping to change at line 591
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 - December 2002 11 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. TBD.
skipping to change at line 638 skipping to change at line 646
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 - December 2002 12 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.
skipping to change at line 676 skipping to change at line 684
To be completed when an agreement on restoration scheme definitions To be completed when an agreement on restoration scheme definitions
and mechanisms has been achieved in other drafts. and mechanisms has been achieved in other drafts.
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. References
[G.707] ITU-T Recommendation G.707, "Network Node Interface for [RFC-2026] Bradner, S., ˘The Internet Standards Process --
the Synchronous Digital Hierarchy (SDH)", October 2000. Revision 3÷, BCP 9, RFC 2026, October 1996.
[G.709] ITU-T Recommendation G.709, "Network Node Interface for [RFC-2119] Bradner, S., ˘Key words for use in RFCs to Indicate
the Optical Transport Network (OTN)", February 2001 Requirement Levels÷, BCP 14, RFC 2119, March 1997.
(and Amendment 1, October 2001).
[G.783] ITU-T Recommendation G.783,"Characteristics of [G.707] ITU-T, ˘Network Node Interface for the Synchronous
Synchronous Digital Hierarchy (SDH) Equipment Digital Hierarchy (SDH)÷, Recommendation G.707, October
Functional Blocks". 2000.
[G.798] ITU-T Recommendation G.798, "Characteristics of Optical [G.783] ITU-T, ˘Characteristics of Synchronous Digital
Transport Network (OTN) Equipment Functional Blocks". Hierarchy (SDH) Equipment Functional Blocks÷,
Recommendation G.783, October 2000.
E.Mannie, D.Papadimitriou et al.- Internet Draft - December 2002 13 E.Mannie, D.Papadimitriou et al.- Internet Draft ű May 2003 13
[G.806] ITU-T Recommendation G.806, "Characteristics of [G.806] ITU-T, ˘Characteristics of Transport Equipment ű
Transport Equipment ű Description Methodology and Description Methodology and Generic Functionality÷,
Generic Functionality". Recommendation G.806, October 2000.
[G.841] ITU-T Recommendation G.841, "Types and Characteristics [G.841] ITU-T, ˘Types and Characteristics of SDH Network
of SDH Network Protection Architectures". Protection Architectures÷, Recommendation G.841,
October 1998.
[G.842] ITU-T Recommendation G.842, "Interworking of SDH [G.842] ITU-T, ˘Interworking of SDH network protection
network protection architectures". architectures÷, Recommendation G.842, October 1998.
[G.gps] ITU-T on-going work G.gps, "Generic Protection [G.gps] ITU-T ongoing work G.gps, "Generic Protection
Switching", ITU-T Draft (April, 2002). Switching", ITU-T Draft (April, 2002).
[ANSI-T1.105]"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, 2000. Formats", ANSI T1.105, January 2001.
[BALA] Rajagopalan, Bala et al, "Signaling for Protection and [BALA] B.Rajagopalan et al, "Signaling for Protection and
Restoration in Optical Mesh Networks", Internet Draft, 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, "GMPLS Architecture", Internet Draft, [GMPLS-ARCH] E.Mannie, Editor, "Generalized MPLS Architecture",
Work in progress, draft-ietf-ccamp-gmpls-architecture- Internet Draft, Work in progress, draft-ietf-ccamp-
02.txt, February 2002. gmpls-architecture-03.txt, August 2002.
[TEWG] W.S Lai, et al., "Network Hierarchy and Multilayer [TEWG] W.S Lai, et al., "Network Hierarchy and Multilayer
Survivability", Internet Draft, Work in progress, Survivability", Internet Draft, Work in progress,
draft-team-tewg-restore-hierarchy-00.txt, July 2001. draft-ietf-tewg-restore-hierarchy-01.txt, June 2002.
[SUDHEER] Sudheer Dharanikota et al., "NNI Protection and [SUDHEER] S.Dharanikota et al., "NNI Protection and restoration
restoration requirements," OIF Contribution 507, 2001. requirements," OIF Contribution 507, 2001.
10. Acknowledgments 10. Acknowledgments
Valuable comments and input were received from many people. Valuable comments and input were received from many people.
11. Author's Addresses 11. Author's Addresses
Deborah Brungard Deborah Brungard (AT&T)
AT&T
Rm. D1-3C22 Rm. D1-3C22
200 S. Laurel Ave. 200 S. Laurel Ave.
Middletown, NJ 07748 Middletown, NJ 07748, USA
USA
Email: dbrungard@att.com Email: dbrungard@att.com
Sudheer Dharanikota Sudheer Dharanikota (Consulting)
Nayna Networks Inc Email: sudheer@ieee.org
481 Sycamore Drive
Milpitas, CA 95035
USA
Email: sudheer@nayna.com
E.Mannie, D.Papadimitriou et al.- Internet Draft - December 2002 14
Jonathan P. Lang Jonathan P. Lang
Calient Networks Calient Networks
25 Castilian 25 Castilian
Goleta, CA 93117 Goleta, CA 93117, USA
E.Mannie, D.Papadimitriou et al.- Internet Draft ű May 2003 14
Email: jplang@calient.net Email: jplang@calient.net
Guangzhi Li Guangzhi Li (AT&T)
AT&T
180 Park Avenue, 180 Park Avenue,
Florham Park, NJ 07932 Florham Park, NJ 07932
gli@research.att.com Email: gli@research.att.com
973-360-7376 973-360-7376
Eric Mannie Eric Mannie (Consult)
KPNQwest Email: eric_mannie@hotmail.com
Terhulpsesteenweg 6A
1560 Hoeilaart
Belgium
Phone: +32 2 658 56 52
Email: eric.mannie@ebone.com
Dimitri Papadimitriou Dimitri Papadimitriou (Alcatel)
Alcatel
Francis Wellesplein, 1 Francis Wellesplein, 1
B-2018 Antwerpen B-2018 Antwerpen, Belgium
Belgium
Phone: +32 3 240-84-91 Phone: +32 3 240-84-91
Email: dimitri.papadimitriou@alcatel.be Email: dimitri.papadimitriou@alcatel.be
Bala Rajagopalan Bala Rajagopalan (Tellium)
Tellium, Inc.
2 Crescent Place 2 Crescent Place
P.O. Box 901 P.O. Box 901
Oceanport, NJ 07757-0901 Oceanport, NJ 07757-0901, USA
USA
Phone: +1 732 923 4237 Phone: +1 732 923 4237
Email: braja@tellium.com Email: braja@tellium.com
Yakov Rekhter Yakov Rekhter (Juniper)
Juniper
Email: yakov@juniper.net Email: yakov@juniper.net
E.Mannie, D.Papadimitriou et al.- Internet Draft - December 2002 15 E.Mannie, D.Papadimitriou et al.- Internet Draft ű May 2003 15
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
E.Mannie, D.Papadimitriou et al.- Internet Draft ű May 2003 16
 End of changes. 

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