--- 1/draft-ietf-ccamp-gmpls-recovery-terminology-05.txt 2006-02-04 22:56:24.000000000 +0100 +++ 2/draft-ietf-ccamp-gmpls-recovery-terminology-06.txt 2006-02-04 22:56:24.000000000 +0100 @@ -1,22 +1,22 @@ CCAMP Working Group CCAMP GMPLS P&R Design Team Internet Draft Category: Informational Eric Mannie (Editor) -Expiration Date: March 2005 Dimitri Papadimitriou (Editor) +Expiration Date: October 2005 Dimitri Papadimitriou (Editor) - October 2004 + April 2005 Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) - draft-ietf-ccamp-gmpls-recovery-terminology-05.txt + draft-ietf-ccamp-gmpls-recovery-terminology-06.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions 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. @@ -31,21 +31,21 @@ material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice - Copyright (C) The Internet Society (2004). All Rights Reserved. + Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document defines a common terminology for Generalized Multi- Protocol Label Switching (GMPLS) based recovery mechanisms (i.e. protection and restoration). The terminology is independent of the underlying transport technologies covered by GMPLS. E.Mannie, D.Papadimitriou et al. - Informational 1 @@ -54,136 +54,139 @@ Status of this Memo .............................................. 1 Abstract ......................................................... 1 Table of Contents ................................................ 2 1. Contributors .................................................. 3 2. Introduction .................................................. 3 3. Conventions used in this document ............................. 4 4. Recovery Terminology Common to Protection and Restoration ..... 4 4.1 Working and Recovery LSP/Span ................................ 5 4.2 Traffic Types ................................................ 5 4.3 LSP/Span Protection and Restoration .......................... 6 - 4.4 Recovery Scope ............................................... 6 + 4.4 Recovery Scope ............................................... 7 4.5 Recovery Domain .............................................. 7 4.6 Recovery Types ............................................... 7 4.7 Bridge Types ................................................. 9 4.8 Selector Types ............................................... 9 4.9 Recovery GMPLS Nodes ........................................ 10 4.10 Switch-over Mechanism ...................................... 10 4.11 Reversion operations ....................................... 10 4.12 Failure Reporting .......................................... 11 4.13 External commands .......................................... 11 4.14 Unidirectional versus Bi-Directional Recovery Switching .... 12 4.15 Full versus Partial Span Recovery Switching ................ 12 4.16 Recovery Schemes Related Time and Durations ................ 13 - 4.17 Impairment ................................................. 13 + 4.17 Impairment ................................................. 14 4.18 Recovery Ratio ............................................. 14 4.19 Hitless Protection Switch-over ............................. 14 4.20 Network Survivability ...................................... 14 4.21 Survivable Network ......................................... 14 4.22 Escalation ................................................. 14 5. Recovery Phases .............................................. 14 5.1 Entities Involved During Recovery ........................... 15 6. Protection Schemes ........................................... 16 6.1 1+1 Protection .............................................. 16 6.2 1:N (N >= 1) 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 ................................. 17 7. Restoration Schemes .......................................... 17 7.1 Pre-planned LSP Restoration ................................. 17 - 7.1.1 Shared-Mesh Restoration ................................... 17 + 7.1.1 Shared-Mesh Restoration ................................... 18 7.2 LSP Restoration ............................................. 18 7.2.1 Hard LSP Restoration ...................................... 18 7.2.2 Soft LSP Restoration ...................................... 18 8. Security Considerations ...................................... 18 - 9. References ................................................... 18 - 9.1 Normative References ........................................ 18 - 9.2 Informative References ...................................... 18 - 10. Acknowledgments ............................................. 19 - 11. Editor's Address ............................................ 19 - Intellectual Property Statement ................................. 20 - Disclaimer of Validity .......................................... 20 + 9. IANA Considerations .......................................... 18 + 10. References .................................................. 18 + 10.1 Normative References ....................................... 18 + 10.2 Informative References ..................................... 19 + 11. Acknowledgments ............................................. 20 + 12. Editor's Address ............................................ 20 + Intellectual Property Statement ................................. 21 -E.Mannie, D.Papadimitriou et al.- Expires March 2005 2 - Copyright Statement ............................................. 20 +E.Mannie, D.Papadimitriou et al.- Expires October 2005 2 + Disclaimer of Validity .......................................... 21 + Copyright Statement ............................................. 21 1. Contributors 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 document: Deborah Brungard (AT&T) Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ 07748, USA EMail: dbrungard@att.com Sudheer Dharanikota EMail: sudheer@ieee.org - Jonathan P. Lang (Rincon Networks) + Jonathan P. Lang (Sonos) + 506 Chapala Street + Santa Barbara, CA 93101, USA EMail: jplang@ieee.org Guangzhi Li (AT&T) 180 Park Avenue, Florham Park, NJ 07932, USA EMail: gli@research.att.com Eric Mannie EMail: eric_mannie@hotmail.com Dimitri Papadimitriou (Alcatel) - Fr. Wellesplein, 1 - B-2018, Antwerpen, Belgium + Francis Wellesplein, 1 + B-2018 Antwerpen, Belgium EMail: dimitri.papadimitriou@alcatel.be - Bala Rajagopalan - EMail: braj@earthlink.net + Bala Rajagopalan (Intel Broadband Wireless Division) + 2111 NE 25th Ave. + Hillsboro, OR 97124, USA + EMail: bala.rajagopalan@intel.com Yakov Rekhter (Juniper) 1194 N. Mathilda Avenue Sunnyvale, CA 94089, USA EMail: yakov@juniper.net 2. Introduction 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. + protection and restoration). +E.Mannie, D.Papadimitriou et al.- Expires October 2005 3 The terminology proposed in this document is independent of the underlying transport technologies and borrows from the G.808.1 ITU-T Recommendation [G.808.1] and from the G.841 ITU-T Recommendation [G.841]. The restoration terminology and concepts have been gathered from numerous sources including IETF drafts. -E.Mannie, D.Papadimitriou et al.- Expires March 2005 3 In the context of this document, the term "recovery" denotes both protection and restoration. The specific terms "protection" and "restoration" will only be used when differentiation is required. This document focuses on the terminology for the recovery of Label Switched Paths (LSPs) controlled by a GMPLS control plane. The proposed terminology applies to end-to-end, segment, and span (i.e. link) recovery. Note that the terminology for recovery of the control plane itself is not in the scope of this document. Protection and restoration of switched LSPs under tight time constraints is a challenging problem. This is particularly relevant to optical networks that consist of Time Division Multiplex (TDM) and/or all-optical (photonic) cross-connects referred to as GMPLS nodes (or simply nodes, or even sometimes "Label Switching Routers, - or LSRs") connected in a general topology [GMPLS-ARCH]. + or LSRs") connected in a general topology [RFC3945]. Recovery typically involves the activation of a recovery (or - alternate) LSP when a failure is encountered in the working (or - primary) LSP. + alternate) LSP when a failure is encountered in the working LSP. A working or recovery LSP is characterized by an ingress interface, an egress interface, and a set of intermediate nodes and spans through which the LSP is routed. The working and recovery LSPs are typically resource disjoint (e.g. node and/or span disjoint). This ensures that a single failure will not affect both the working and recovery LSPs. A bi-directional span between neighboring nodes is usually realized as a pair of unidirectional spans. The end-to-end path for a bi- @@ -196,27 +199,27 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 4. Recovery Terminology Common to Protection and Restoration This section defines the following general terms common to both protection and restoration (i.e. recovery). In addition, most of these terms apply to end-to-end, segment and span LSP recovery. Note + +E.Mannie, D.Papadimitriou et al.- Expires October 2005 4 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.808.1]. However, for generalization, the following language that - -E.Mannie, D.Papadimitriou et al.- Expires March 2005 4 is not directly related to recovery has been adapted to GMPLS and the common IETF terminology: An LSP is used as a generic term to designate either an SNC (Sub- Network Connection) or an NC (Network Connection) in ITU-T terminology. The ITU-T uses the term transport entity to designate either a link, an SNC or an NC. The term "Traffic" is used instead of "Traffic Signal". The term protection or restoration "scheme" is used instead of protection or restoration "architecture". @@ -250,28 +253,27 @@ LSP/span) when these resources are not being used for the recovery of normal traffic; i.e. when the recovery resources are in standby mode. When the recovery resources are required to recover normal traffic from the failed working LSP/span, the extra traffic is pre- empted. Extra traffic is not protected by definition, but may be restored. Moreover, extra traffic does not need to commence or be terminated at the ends of the LSPs/spans that it uses. C. Null traffic: +E.Mannie, D.Papadimitriou et al.- Expires October 2005 5 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. -E.Mannie, D.Papadimitriou et al.- Expires March 2005 5 - 4.3 LSP/Span Protection and Restoration The following subtle distinction is generally made between the terms "protection" and "restoration", even though these terms are often used interchangeably [RFC3386]. The distinction between protection and restoration is made based on the resource allocation done during the recovery LSP/span establishment. The distinction between different types of restoration is made based on the level of route computation, @@ -304,27 +306,28 @@ 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.- Expires October 2005 6 + 4.4 Recovery Scope Recovery can be applied at various levels throughout the network. An LSP may be subject to local (span), segment, and/or end-to-end recovery. -E.Mannie, D.Papadimitriou et al.- Expires March 2005 6 Local (span) recovery refers to the recovery of an LSP over a link between two nodes. End-to-end recovery refers to the recovery of an entire LSP from its source (ingress node end-point) to its destination (egress node end- point). Segment recovery refers to the recovery over a portion of the network of a segment LSP (i.e. an SNC in the ITU-T terminology) of an end-to-end LSP. Such recovery protects against span and/or node @@ -357,27 +360,27 @@ One dedicated protection LSP/span protects exactly one working LSP/span and the normal traffic is permanently duplicated at the ingress node on both the working and protection LSPs/spans. No extra traffic can be carried over the protection LSP/span. This type is applicable to LSP/span protection, but not to LSP/span restoration. B. 0:1 type: unprotected +E.Mannie, D.Papadimitriou et al.- Expires October 2005 7 No specific recovery LSP/span protects the working LSP/span. However, the working LSP/span can potentially be restored through any alternate available route/span, with or without any pre-computed restoration route. Note that there are no resources pre-established for this recovery type. -E.Mannie, D.Papadimitriou et al.- Expires March 2005 7 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 One specific recovery LSP/span protects exactly one specific working LSP/span but the normal traffic is transmitted only over one LSP (working or recovery) at a time. Extra traffic can be transported @@ -410,27 +413,26 @@ as a recovery scheme. The choice of X is a network resource management policy decision. E. M:N (M, N > 1, N >= M) type: A set of M specific recovery LSPs/spans protects a set of up to N specific working LSPs/spans. The two sets are explicitly identified. Extra traffic can be transported over the M recovery LSPs/spans when available. All the LSPs/spans must start and end at the same nodes. +E.Mannie, D.Papadimitriou et al.- Expires October 2005 8 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 - -E.Mannie, D.Papadimitriou et al.- Expires March 2005 8 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. 4.7 Bridge Types A bridge is the function that connects the normal traffic and extra traffic to the working and recovery LSP/span. @@ -464,25 +466,25 @@ A. Selective selector Is a selector that extracts the normal traffic from either the working LSP/span output or the recovery LSP/span output. B. Merging selector For 1:N and M:N protection types, the selector permanently extracts the normal traffic from both the working and recovery LSP/span + +E.Mannie, D.Papadimitriou et al.- Expires October 2005 9 outputs. This alternative works only in combination with a selector bridge. -E.Mannie, D.Papadimitriou et al.- Expires March 2005 9 - 4.9 Recovery GMPLS Nodes This section defines the GMPLS nodes involved during recovery. A. Ingress GMPLS node of an end-to-end LSP/segment LSP/span The ingress node of an end-to-end LSP/segment LSP/span is where the normal traffic may be bridged to the recovery end-to-end LSP/segment LSP/span. Also known as source node in the ITU-T terminology. @@ -517,26 +519,25 @@ LSP/span, the action of connecting the normal traffic to the recovery LSP/span. 4.11 Reversion operations A revertive recovery operation refers to a recovery switching operation, where the traffic returns to (or remains on) the working LSP/span if the switch-over requests are terminated; i.e. when the working LSP/span has recovered from the failure. +E.Mannie, D.Papadimitriou et al.- Expires October 2005 10 Therefore a non-revertive recovery switching operation is when the traffic does not return to the working LSP/span if the switch-over requests are terminated. -E.Mannie, D.Papadimitriou et al.- Expires March 2005 10 - 4.12 Failure Reporting This section gives (for information) several signal types commonly used in transport planes to report a failure condition. Note that fault reporting may require additional signaling mechanisms. A. Signal Degrade (SD): a signal indicating that the associated data has degraded. B. Signal Fail (SF): a signal indicating that the associated data @@ -546,22 +547,23 @@ associated group data has degraded. D. Signal Fail Group (SFG): a signal indicating that the associated group has failed. Note: SDG and SFG definitions are under discussion at the ITU-T. 4.13 External commands This section defines several external commands, typically issued by - an operator through the NMS/EMS, which can be used to influence or - command the recovery schemes. + an operator through the Network Management System (NMS)/Element + Management System (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 recovery LSP/span being temporarily unavailable to transport traffic (either normal or extra traffic). B. Lockout of normal traffic: A configuration action initiated externally that results in the @@ -570,27 +572,27 @@ allowed on the recovery LSP/span. C. Freeze: A configuration action initiated externally that prevents any switch-over action to be taken, and as such freezes the current state. D. Forced switch-over for normal traffic: +E.Mannie, D.Papadimitriou et al.- Expires October 2005 11 A switch-over action initiated externally that switches normal traffic to the recovery LSP/span, unless an equal or higher priority switch-over command is in effect. E. Manual switch-over for normal traffic: -E.Mannie, D.Papadimitriou et al.- Expires March 2005 11 A switch-over action initiated externally that switches normal traffic to the recovery LSP/span, unless a fault condition exists on other LSPs/spans (including the recovery LSP/span) or an equal or higher priority switch-over command is in effect. F. Manual switch-over for recovery LSP/span: A switch-over action initiated externally that switches normal traffic to the working LSP/span, unless a fault condition exists on the working LSP/span or an equal or higher priority switch-over @@ -623,27 +625,27 @@ 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 +E.Mannie, D.Papadimitriou et al.- Expires October 2005 12 All the S LSP carried over a given span are recovered under span failure condition. Full span recovery is also referred to as "bulk recovery". B. Partial Span Recovery -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 under span failure condition. Both selection criteria of the entities belonging to this subset and the decision concerning the recovery of the remaining (S - s) LSP are based on local policy. 4.16 Recovery Schemes Related Time and Durations This section gives several typical timing definitions that are of importance for recovery schemes. @@ -675,47 +677,47 @@ The total recovery time is defined as the sum of the detection, the correlation, the notification and the recovery switching time. F. Wait To Restore time: A period of time that must elapse 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. +E.Mannie, D.Papadimitriou et al.- Expires October 2005 13 Note: the hold-off time is defined as the time between the reporting of signal fail or degrade, and the initialization of the recovery switching operation. This is useful when multiple layers of recovery are being used. 4.17 Impairment -E.Mannie, D.Papadimitriou et al.- Expires March 2005 13 A defect or performance degradation, which may lead to SF or SD trigger. 4.18 Recovery Ratio The quotient of the actually recovery bandwidth divided by the traffic bandwidth which is intended to be protected. 4.19 Hitless Protection Switch-over Protection switch-over, which does not cause data loss, data duplication, data disorder, or bit errors upon recovery switching action. 4.20 Network Survivability The set of capabilities that allow a network to restore affected traffic in the event of a failure. The degree of survivability is - determined by the networkÆs capability to survive single and + 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 @@ -729,27 +731,26 @@ - Phase 1: Failure Detection 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. +E.Mannie, D.Papadimitriou et al.- Expires October 2005 14 - Phase 2: Failure Localization (and Isolation) 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 - -E.Mannie, D.Papadimitriou et al.- Expires March 2005 14 can then take accurate decision to achieve finer grained recovery switching action(s). - Phase 3: Failure Notification Failure notification phase is used 1) to inform intermediate nodes that LSP(s)/span(s) failure has occurred and has been detected 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. @@ -782,26 +783,26 @@ and report the failure to the deciding entity. Fault reporting can be automatically performed by the deciding entity detecting the failure. C. Deciding Entity (part of the failure recovery decision process): An entity that makes the recovery decision or selects the recovery resources. This entity communicates the decision to the impacted LSPs/spans with the recovery actions to be performed. +E.Mannie, D.Papadimitriou et al.- Expires October 2005 15 D. Recovering Entity (part of the failure recovery activation process): An entity that participates in the recovery of the LSPs/spans. -E.Mannie, D.Papadimitriou et al.- Expires March 2005 15 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 @@ -834,28 +835,28 @@ Unprotected extra traffic can be transported over the protection LSP/span whenever the protection LSP/span is not used to carry a normal traffic. 6.3 M:N (M, N > 1, N >= M) Protection M:N protection has N working LSPs/spans carrying normal traffic and M protection LSP/span that may carry extra-traffic. +E.Mannie, D.Papadimitriou et al.- Expires October 2005 16 At the ingress, the normal traffic is either permanently connected to its working LSP/span and may be connected to one of the protection LSPs/spans (case of broadcast bridge), or is connected to either its working 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. -E.Mannie, D.Papadimitriou et al.- Expires March 2005 16 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. 6.4 Notes on Protection Schemes 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. @@ -887,27 +888,27 @@ working LSP and requires some additional restoration signaling. Therefore, this mechanism protects against working LSP failure(s) but requires activation of the restoration LSP after failure occurrence. After the ingress node has activated the restoration LSP, the latter can carry the normal traffic. Note: when each working LSP is recoverable by exactly one restoration LSP, one refers also to 1:1 (pre-planned) re-routing without extra-traffic. +E.Mannie, D.Papadimitriou et al.- Expires October 2005 17 + 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 - -E.Mannie, D.Papadimitriou et al.- Expires March 2005 17 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 computed after failure detection and/or notification. In this case, one also refers to "Full LSP Re- @@ -924,96 +925,112 @@ alternate LSP (i.e. break-before-make). 7.2.2 Soft LSP Restoration Also referred to as soft LSP re-routing. A re-routing operation where the LSP is released after the full establishment of an alternate LSP (i.e. make-before-break). 8. Security Considerations - This document does not introduce or imply any specific security - consideration. + Security considerations are detailed in [ANAL] and [FUNCT]. -9. References +9. IANA Considerations -9.1 Normative References + This document defines no new code points and requires no action by + IANA. + +10. References + +10.1 Normative References + + [ANAL] D.Papadimitriou and E.Mannie (Editors), "Analysis of + Generalized Multi-Protocol Label Switching (GMPLS)- + based Recovery Mechanisms (including Protection and + Restoration)", Internet Draft (Work in progress), April + 2005. + +E.Mannie, D.Papadimitriou et al.- Expires October 2005 18 + [FUNCT] J.P.Lang, B.Rajagopalan and D.Papadimitriou (Editors), + "Generalized MPLS Recovery Functional Specification," + Internet Draft (Work in progress), April 2005. [RFC2026] S.Bradner, "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997. [RFC3667] S.Bradner, "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004. [RFC3668] S.Bradner, Ed., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. -9.2 Informative 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. +10.2 Informative References [RFC3386] W.S.Lai, et al., "Network Hierarchy and Multilayer Survivability," RFC 3386, November 2002. + [RFC3945] E.Mannie (Editor), "Generalized Multi-Protocol Label + Switching (GMPLS) Architecture," RFC 3945, October + 2004. + [T1.105] ANSI, "Synchronous Optical Network (SONET): Basic Description Including Multiplex Structure, Rates, and Formats," ANSI T1.105, January 2001. 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 Digital Hierarchy (SDH)," Recommendation G.707, October 2000. [G.783] ITU-T, "Characteristics of Synchronous Digital Hierarchy (SDH) Equipment Functional Blocks," 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," 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, December 2003. [G.841] ITU-T, "Types and Characteristics of SDH Network Protection Architectures," Recommendation G.841, October 1998. +E.Mannie, D.Papadimitriou et al.- Expires October 2005 19 [G.842] ITU-T, "Interworking of SDH network protection architectures," Recommendation G.842, October 1998. -10. Acknowledgments +11. Acknowledgments Many thanks to Adrian Farrel for having thoroughly review this document. -11. Editor's Addresses +12. Editor's Addresses Eric Mannie EMail: eric_mannie@hotmail.com - Dimitri Papadimitriou (Alcatel) + Dimitri Papadimitriou + Alcatel Francis Wellesplein, 1 B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 EMail: dimitri.papadimitriou@alcatel.be -E.Mannie, D.Papadimitriou et al.- Expires March 2005 19 +E.Mannie, D.Papadimitriou et al.- Expires October 2005 20 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC @@ -1037,20 +1054,20 @@ This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement - Copyright (C) The Internet Society (2004). This document is subject + Copyright (C) The Internet Society (2005). 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 +E.Mannie, D.Papadimitriou et al.- Expires October 2005 21