--- 1/draft-ietf-ccamp-gmpls-recovery-terminology-01.txt 2006-02-04 22:56:21.000000000 +0100 +++ 2/draft-ietf-ccamp-gmpls-recovery-terminology-02.txt 2006-02-04 22:56:21.000000000 +0100 @@ -1,28 +1,22 @@ CCAMP Working Group CCAMP GMPLS P&R Design Team Internet Draft -Expiration Date: May 2003 Eric Mannie (Consult) Editor - Dimitri Papadimitriou (Alcatel) Editor - - Deborah Brungard (AT&T) - Sudheer Dharanikota (Consult) - Jonathan Lang (Calient) - Guangzhi Li (AT&T) - Bala Rajagopalan (Tellium) - Yakov Rekhter (Juniper) +Category: Standard Track Eric Mannie (Editor) +Expiration Date: November 2003 Dimitri Papadimitriou (Editor) - 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 This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. @@ -35,45 +29,83 @@ http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. For potential updates to the above required-text see: http://www.ietf.org/ietf/1id-guidelines.txt 1. Abstract - This document defines a common terminology for Generalized MPLS - (GMPLS) based recovery mechanisms (i.e. protection and restoration) - that are under consideration by the CCAMP Working Group. + This document defines a common terminology for Generalized Multi- + Protocol Label Switching (GMPLS) based recovery mechanisms (i.e. + 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 -2. Conventions used in this document +2. Contributors - 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]. + This document is the result of the CCAMP Working Group Protection + and Restoration design team joint effort. The following are the + 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 This document defines a common terminology for Generalized MPLS (GMPLS) based recovery mechanisms (i.e. protection and restoration) that are under consideration by the CCAMP Working Group. The terminology proposed in this document is intended to be independent of the underlying transport technologies and borrows - from an ITU-T ongoing effort (G.gps - Generic Protection Switching - [G.gps]) and from the G.841 ITU-T Recommendation. The restoration - terminology and concepts have been gathered from numerous sources - including IETF drafts. + from an ITU-T ongoing effort, the Draft Recommendation [G.808.1] + (ex. G.GPS - Generic Protection Switching) and from the G.841 ITU-T + Recommendation. The restoration terminology and concepts have been + 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 denote both protection and restoration. The specific terms "protection" and "restoration" will only be used when differentiation is required. 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, segment and span (i.e. link) LSP recovery. Terminology for control plane recovery is not in the scope of this document. @@ -95,45 +127,51 @@ ensures that a single failure will not affect both the working and recovery LSPs. A bi-directional span between neighboring nodes is usually realized as a pair of unidirectional spans. The end-to-end path for a bi- directional LSP therefore consists of a series of bi-directional segments (i.e. Sub-Network Connections, or SNCs, in the ITU-T terminology) between the source and destination nodes, traversing intermediate nodes. -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 This section defines the following general terms common to both protection and restoration (i.e. recovery). In addition, most of these terms apply to end-to-end, segment and span LSP recovery. Note - that span recovery assumes that the nodes at each end of the span - did not fail, otherwise end-to-end or segment LSP recovery is used. + that span recovery does not protect the nodes at each end of the + span, otherwise end-to-end or segment LSP recovery should be used. The terminology and the definitions 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 common IETF terminology: An LSP is used as a generic term to designate either an SNC (Sub- Network Connection) or an NC (Network Connection) in ITU-T terminology. The ITU-T uses the term transport entity to designate either a link, an SNC or an NC. The term "Traffic" is used instead of "Traffic Signal". The term protection or restoration "scheme" is used instead of protection or restoration "architecture". - The reader is invited to read G.841 and G.gps for references to SDH - protection and ITU-T generic protection terminology. Note that - restoration is not in the scope of G.gps. + The reader is invited to read G.841 and G.808.1 for references to + SDH protection and ITU-T generic protection terminology. Note that + restoration is not in the scope of G.808.1. 4.1 Working and Recovery LSP/Span A working LSP/span is an LSP/span transporting "normal" user traffic. A recovery LSP/span is an LSP/span used to transport "normal" user traffic when the working LSP/span fails. Additionally, the recovery LSP/span may transport "extra" user traffic (i.e. pre- emptable traffic) when normal traffic is carried over the working LSP/span. @@ -150,31 +188,31 @@ B. Extra traffic: User traffic carried over recovery resources (e.g. a recovery LSP/span) when these resources are not being used for the recovery of normal traffic; i.e. when the recovery resources are in standby mode. When the recovery resources are required to recover normal traffic from the failed working LSP/span, the extra traffic is pre- empted. Extra traffic is not protected by definition, but may be restored. -E.Mannie, D.Papadimitriou et al.- Internet Draft û May 2003 3 C. Null traffic: Traffic carried over the recovery LSP/span if it is not used to carry normal or extra traffic. Null traffic can be any kind of traffic that conforms to the signal structure of the specific layer, and it is ignored (not selected) at the egress of the recovery LSP/span. 4.3 LSP/Span Protection and Restoration +E.Mannie, D.Papadimitriou et al.- Internet Draft - November 2003 4 The following subtle distinction is generally made between the terms "protection" and "restoration", even though these terms are often used interchangeably [TEWG]. The distinction between protection and restoration is made based on the resource allocation done during the recovery LSP/span establishment. The distinction between different types of restoration is made based on the level of route computation, signaling and resource allocation done during the restoration LSP/span establishment. @@ -205,41 +243,45 @@ resources may be pre-computed, signaled and selected a priori, but not cross-connected to restore a working LSP/span. The complete establishment of the restoration LSP/span occurs only after a failure of the working LSP/span, and requires some additional signaling. Both protection and restoration require signaling. Signaling to establish the recovery resources and signaling associated with the use of the recovery LSP(s)/span(s) are needed. -E.Mannie, D.Papadimitriou et al.- Internet Draft û May 2003 4 - 4.4 Recovery Scope Recovery can be applied at various levels throughout the network. 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 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 + +E.Mannie, D.Papadimitriou et al.- Internet Draft - November 2003 5 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 recovery. 4.5 Recovery Domain A recovery domain is defined as a set of nodes and spans over which one or more recovery schemes are provided. A recovery domain served by one single recovery scheme is referred to as a "single recovery domain", while a recovery domain served by multiple recovery schemes is referred to as a "multi recovery domain". + The recovery operation is contained within the recovery domain. A + GMPLS recovery domain must be entirely contained within a GMPLS + domain. A GMPLS domain may contain multiple recovery domains. + 4.6 Recovery Types The different recovery types can be classified depending on the number of recovery LSPs/spans that are protecting a given number of working LSPs/spans. The definitions given hereafter are from the point of view of a working LSP/span that needs to be protected by a recovery scheme. A. 1+1 type: dedicated protection @@ -259,23 +301,24 @@ restoration route. Note that there are no resources pre-established for this recovery type. This type is applicable to LSP/span restoration, but not to LSP/span protection. Span restoration can be for instance achieved by moving all the LSPs transported over of a failed span to a dynamically selected span. 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 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 using the recovery LSP/span resources. This type is applicable to LSP/span protection and LSP restoration, but not to span restoration. D. 1:N (N>1) type: shared recovery with extra traffic A specific recovery LSP/span is dedicated to the protection of up to N working LSPs/spans. The set of working LSPs/spans is explicitly @@ -292,45 +335,44 @@ decision. This type is applicable to LSP/span protection and LSP restoration, but not to span restoration. Note: a shared recovery where each recovery resource can be shared by a maximum of X LSPs/spans is not defined as a recovery type but as a recovery scheme. The choice of X is a network resource management policy decision. - E. M:N (M, N > 1; 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 specific working LSPs/spans. The two sets are explicitly identified. Extra traffic can be transported over the M recovery LSPs/spans when available. All the LSPs/spans must start and end at the same nodes. Sometimes, the working LSPs/spans are assumed to be resource disjoint in the network so that they do not share any failure probability, but this is not mandatory. Obviously, if several working LSPs/spans in the set of N are concurrently affected by some failure(s), the traffic on only M of these failed LSPs/spans may be recovered. Note that N can be arbitrarily large (i.e. infinite). The choice of N and M is a policy decision. This type is applicable to LSP/span protection and LSP restoration, but not to span restoration. -E.Mannie, D.Papadimitriou et al.- Internet Draft û May 2003 6 - 4.7 Bridge Types A bridge is the function that connects the normal traffic and extra traffic to the working and recovery LSP/span. +E.Mannie, D.Papadimitriou et al.- Internet Draft - November 2003 7 A. Permanent bridge Under a 1+1 type, the bridge connects the normal traffic to both the working and protection LSPs/spans. This type of bridge is not applicable to restoration types. There is of course no extra traffic connected to the recovery LSP/span. B. Broadcast bridge For 1:N and M:N types, the bridge permanently connects the normal @@ -363,30 +405,28 @@ outputs. This alternative works only in combination with a selector bridge. 4.9 Recovery GMPLS Nodes This section defines the GMPLS nodes involved during recovery. A. Ingress GMPLS node of an end-to-end LSP/segment LSP/span The ingress node of an end-to-end LSP/segment LSP/span is where the - 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 - terminology. + normal traffic may be bridged to the recovery end-to-end LSP/segment + LSP/span. Also known as source node in the ITU-T terminology. B. Egress GMPLS node of an end-to-end LSP/segment LSP/span +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 - 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 the ITU-T terminology. C. Intermediate GMPLS node of an end-to-end LSP/segment LSP A node along either the working or recovery end-to-end LSP/segment LSP route between the corresponding ingress and egress nodes. Also known as intermediate node in the ITU-T terminology. 4.10 Switching Mechanism @@ -420,29 +460,31 @@ 4.12 Failure Reporting This section gives (for information) several signal types commonly used in transport planes to report a failure condition. Note that fault reporting may require additional signaling mechanisms. A. Signal Degrade (SD): a signal indicating that the associated data has degraded. -E.Mannie, D.Papadimitriou et al.- Internet Draft û May 2003 8 B. Signal Fail (SF): a signal indicating that the associated data has failed. +E.Mannie, D.Papadimitriou et al.- Internet Draft - November 2003 9 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 - 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 This section defines several external commands, typically issued by an operator through the NMS/EMS, which can be used to influence or command the recovery schemes. A. Lockout of recovery LSP/span: A configuration action initiated externally that results in the @@ -466,28 +508,38 @@ the recovery LSP/span, unless an equal or higher priority switch command is in effect. E. Manual switch for normal traffic: A switch action initiated externally that switches normal traffic to the recovery LSP/span, unless a fault condition exists on other LSPs/spans (including the recovery LSP/span) or an equal or higher priority switch 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 A. Unidirectional recovery switching: A recovery switching mode in which, for a unidirectional fault (i.e. a fault affecting only one direction of transmission), only the - -E.Mannie, D.Papadimitriou et al.- Internet Draft û May 2003 9 normal traffic transported in the affected direction (of the LSP or span) is switched to the recovery LSP/span. B. Bi-directional recovery switching: A recovery switching mode in which, for a unidirectional fault, the normal traffic in both directions (of the LSP or span), including the affected direction and the unaffected direction, are switched to the recovery LSP/span. @@ -498,50 +550,50 @@ this span. In either case, the corresponding recovery switching actions are performed at the LSP level such that the ratio between the number of recovery switching messages and the number of recovered LSP (in one given direction) is minimized. If this ratio equals 1, one refers to full span recovery, otherwise, if this ratio is greater than 1 one refers to partial span recovery. A. Full Span Recovery All the S LSP carried over a given span are recovered under span - failure condition. Full span recovery is also referred to as ôbulk - recoveryö. + failure condition. Full span recovery is also referred to as "bulk + recovery". B. Partial Span Recovery Only a subset s of the S LSP carried over a given span are recovered under span failure condition. Both selection criteria of the entities belonging to this subset and the decision concerning the - recovery of the remaining (Sûs) LSP are based on local policy. + recovery of the remaining (S - s) LSP are based on local policy. 4.16 Recovery Schemes Related Time and Durations This section gives several typical timing definitions that are of importance for recovery schemes. A. Detection time: +E.Mannie, D.Papadimitriou et al.- Internet Draft - November 2003 11 The time between the occurrence of the fault or degradation and its detection. Note that this is a rather theoretical time since in practice this is difficult to measure. B. Correlation time: The time between detection of the fault or degradation and the reporting of the signal fail or degrade. This time is typically used in correlating related failures or degradations. C. 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 initialization of the recovery switching algorithm. This is useful when multiple layers of recovery are being used. D. Wait To Restore time: 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 select the normal traffic from. @@ -568,61 +620,75 @@ 4.19 Hitless Protection Switch Protection switch, which does not cause data loss, data duplication, data disorder, or bit errors upon recovery switching action. 4.20 Network Survivability The set of capabilities that allow a network to restore affected 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 multiple failures. 4.21 Survivable Network A network that is capable of restoring traffic in the event of a failure. 4.22 Escalation A network survivability action caused by the impossibility of the survivability function in lower layers. -E.Mannie, D.Papadimitriou et al.- Internet Draft û May 2003 11 - 5. Recovery Phases It is commonly accepted that recovery implies that the following generic operations need to be performed when an LSP/span or a node failure occurs: - Phase 1: Failure Detection - 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 - 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) See above. - Phase 5: Reversion (Normalization) See above. +E.Mannie, D.Papadimitriou et al.- Internet Draft - November 2003 13 The combination of Failure Detection and Failure Localization and Notification is referred to as Fault Management. 5.1 Entities Involved During Recovery The entities involved during the recovery operations can be defined as follows; these entities are parts of ingress, egress and intermediate nodes as defined previously: A. Detecting Entity (Failure Detection): @@ -636,156 +702,262 @@ and report the failure to the deciding entity. Fault reporting can be automatically performed by the deciding entity detecting the failure. C. Deciding Entity (part of the failure recovery decision process): An entity that makes the recovery decision or select the recovery resources. This entity communicates the decision to the impacted 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 process): An entity that participates in the recovery of the LSPs/spans. The process of moving failed LSPs from a failed (working) span to a protection span must be initiated by one of the nodes terminating the span, e.g. A or B. The deciding (and recovering) entity is referred to as the "master" while the other node is called the "slave" and corresponds to a recovering only entity. Note: The determination of the master and the slave may be based on configured information or protocol specific requirements. 6. Protection Schemes This section clarifies the multiple possible protection schemes and the specific terminology for the protection. - To be completed with references to ITU-T protection schemes and a - table summarizing the multiple ITU-T protection schemes. +6.1 1+1 protection + + 1+1 protection has one working LSP/span, one protection LSP/span and + a permanent bridge. At the ingress node, the normal traffic is + permanently bridged to both the working and protection LSP/span. At + +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 +E.Mannie, D.Papadimitriou et al.- Internet Draft - November 2003 15 This section clarifies the multiple possible restoration schemes and the specific terminology for the restoration. - To be completed when an agreement on restoration scheme definitions - and mechanisms has been achieved in other drafts. +7.1 Pre-planned LSP Restoration + + Also referred to as pre-planned LSP re-routing. Before failure + detection and/or notification, one or more restoration LSPs are + instantiated between the same ingress-egress node pair 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 This document does not introduce or imply any specific security consideration. -9. References +9. Intellectual Property Considerations - [RFC-2026] Bradner, S., ôThe Internet Standards Process -- - Revision 3ö, BCP 9, RFC 2026, October 1996. + This section is taken from Section 10.4 of [RFC2026]. - [RFC-2119] Bradner, S., ôKey words for use in RFCs to Indicate - Requirement Levelsö, BCP 14, RFC 2119, March 1997. + The IETF takes no position regarding the validity or scope of any + 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 - Digital Hierarchy (SDH)ö, Recommendation G.707, October - 2000. + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + 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 - Hierarchy (SDH) Equipment Functional Blocksö, - Recommendation G.783, October 2000. +10. References -E.Mannie, D.Papadimitriou et al.- Internet Draft û May 2003 13 - [G.806] ITU-T, ôCharacteristics of Transport Equipment û - Description Methodology and Generic Functionalityö, - Recommendation G.806, October 2000. +10.1 Normative References - [G.841] ITU-T, ôTypes and Characteristics of SDH Network - Protection Architecturesö, Recommendation G.841, + [G.707] ITU-T, "Network Node Interface for the Synchronous + 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. - [G.842] ITU-T, ôInterworking of SDH network protection - architecturesö, Recommendation G.842, October 1998. + [G.842] ITU-T, "Interworking of SDH network protection + architectures," Recommendation G.842, October 1998. - [G.gps] ITU-T ongoing work G.gps, "Generic Protection - Switching", ITU-T Draft (April, 2002). +E.Mannie, D.Papadimitriou et al.- Internet Draft - November 2003 17 + [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 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 - Restoration in Optical Mesh Networks", Internet Draft, +10.2 Informative References + + [BALA] B.Rajagopalan et al., "Signaling for Protection and + Restoration in Optical Mesh Networks," Internet Draft, Work in progress, draft-bala-protection-restoration- signaling-00.txt. - [GMPLS-ARCH] E.Mannie, Editor, "Generalized MPLS Architecture", - Internet Draft, Work in progress, draft-ietf-ccamp- - gmpls-architecture-03.txt, August 2002. + [G.783] ITU-T, "Characteristics of Synchronous Digital + Hierarchy (SDH) Equipment Functional Blocks," + Recommendation G.783, October 2000. - [TEWG] W.S Lai, et al., "Network Hierarchy and Multilayer - Survivability", Internet Draft, Work in progress, - draft-ietf-tewg-restore-hierarchy-01.txt, June 2002. + [G.806] ITU-T, "Characteristics of Transport Equipment û + Description Methodology and Generic Functionality," + 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 requirements," OIF Contribution 507, 2001. -10. Acknowledgments - - Valuable comments and input were received from many people. - -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 + [TEWG] W.S.Lai, et al., "Network Hierarchy and Multilayer + Survivability," Internet Draft, Work in progress, + draft-ietf-tewg-restore-hierarchy-01.txt, June 2002. - Jonathan P. Lang - Calient Networks - 25 Castilian - Goleta, CA 93117, USA +11. Acknowledgments -E.Mannie, D.Papadimitriou et al.- Internet Draft û May 2003 14 - Email: jplang@calient.net + Valuable comments and input were received from many people. - Guangzhi Li (AT&T) - 180 Park Avenue, - Florham Park, NJ 07932 - Email: gli@research.att.com - 973-360-7376 +12. Author's Addresses Eric Mannie (Consult) Email: eric_mannie@hotmail.com Dimitri Papadimitriou (Alcatel) Francis Wellesplein, 1 B-2018 Antwerpen, Belgium - Phone: +32 3 240-84-91 - Email: dimitri.papadimitriou@alcatel.be - Bala Rajagopalan (Tellium) - 2 Crescent Place - P.O. Box 901 - 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 - November 2003 18 + Phone: +32 3 240-8491 + Email: dimitri.papadimitriou@alcatel.be -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 "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 @@ -800,11 +972,11 @@ 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 +E.Mannie, D.Papadimitriou et al.- Internet Draft - November 2003 20