operations. Per-component flooding of SRLG identifiers would deeply
impact the scalability of the link state routing protocol.
Therefore, one may rely on the usage of an on-line accessible network
management system.
9. Summary and Conclusions
The following table summarizes the different recovery types and
schemes analyzed throughout this document.
--------------------------------------------------------------------
| Path Search (computation and selection)
--------------------------------------------------------------------
| Pre-planned (a) | Dynamic (b)
--------------------------------------------------------------------
| | faster recovery | Does not apply
| | less flexible |
| 1 | less robust |
| | most resource-consuming |
Path | | |
Setup ------------------------------------------------------------
| | relatively fast recovery | Does not apply
| | relatively flexible |
| 2 | relatively robust |
| | resource consumption |
| | depends on sharing degree |
------------------------------------------------------------
| | relatively fast recovery | less faster (computation)
| | more flexible | most flexible
| 3 | relatively robust | most robust
| | less resource-consuming | least resource-consuming
| | depends on sharing degree |
--------------------------------------------------------------------
1a. Recovery LSP setup (before failure occurrence) with resource
reservation (i.e., signaling) and selection is referred to as LSP
protection.
2a. Recovery LSP setup (before failure occurrence) with resource
reservation (i.e., signaling) and with resource pre-selection is
referred to as pre-planned LSP re-routing with resource pre-
selection. This implies only recovery LSP activation after
failure occurrence.
3a. Recovery LSP setup (before failure occurrence) with resource
reservation (i.e., signaling) and without resource selection is
referred to as pre-planned LSP re-routing without resource pre-
selection. This implies recovery LSP activation and resource
(i.e., label) selection after failure occurrence.
3b. Recovery LSP setup after failure occurrence is referred to as to
as LSP re-routing, which is full when recovery LSP path
computation occurs after failure occurrence.
Thus, the term pre-planned refers to recovery LSP path pre-
computation, signaling (reservation), and a priori resource selection
(optional), but not cross-connection. Also, the shared-mesh recovery
scheme can be viewed as a particular case of 2a) and 3a), using the
additional constraint described in Section 8.4.3.
The implementation of these recovery mechanisms requires only
considering extensions to GMPLS signaling protocols (i.e., [RFC3471]
and [RFC3473]). These GMPLS signaling extensions should mainly focus
in delivering (1) recovery LSP pre-provisioning for the cases 1a, 2a,
and 3a, (2) LSP failure notification, (3) recovery LSP switching
action(s), and (4) reversion mechanisms.
Moreover, the present analysis (see Section 8) shows that no GMPLS
routing extensions are expected to efficiently implement any of these
recovery types and schemes.
10. Security Considerations
This document does not introduce any additional security issue or
imply any specific security consideration from [RFC3945] to the
current RSVP-TE GMPLS signaling, routing protocols (OSPF-TE, IS-IS-
TE) or network management protocols.
However, the authorization of requests for resources by GMPLS-capable
nodes should determine whether a given party, presumably already
authenticated, has a right to access the requested resources. This
determination is typically a matter of local policy control, for
example, by setting limits on the total bandwidth made available to
some party in the presence of resource contention. Such policies may
become quite complex as the number of users, types of resources, and
sophistication of authorization rules increases. This is
particularly the case for recovery schemes that assume pre-planned
sharing of recovery resources, or contention for resources in case of
dynamic re-routing.
Therefore, control elements should match the requests against the
local authorization policy. These control elements must be capable
of making decisions based on the identity of the requester, as
verified cryptographically and/or topologically.
11. Acknowledgements
The authors would like to thank Fabrice Poppe (Alcatel) and Bart
Rousseau (Alcatel) for their revision effort, and Richard Rabbat
(Fujitsu Labs), David Griffith (NIST), and Lyndon Ong (Ciena) for
their useful comments.
Thanks also to Adrian Farrel for the thorough review of the document.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January
2003.
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004.
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201, October
2005.
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing
Extensions in Support of Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC
4204, October 2005.
[RFC4209] Fredette, A., Ed. and J. Lang, Ed., "Link Management
Protocol (LMP) for Dense Wavelength Division
Multiplexing (DWDM) Optical Line Systems", RFC 4209,
October 2005.
[RFC4427] Mannie E., Ed. and D. Papadimitriou, Ed., "Recovery
(Protection and Restoration) Terminology for Generalized
Multi-Protocol Label Switching (GMPLS)", RFC 4427, March
2006.
12.2. Informative References
[BOUILLET] E. Bouillet, et al., "Stochastic Approaches to Compute
Shared Meshed Restored Lightpaths in Optical Network
Architectures," IEEE Infocom 2002, New York City, June
2002.
[DEMEESTER] P. Demeester, et al., "Resilience in Multilayer
Networks," IEEE Communications Magazine, Vol. 37, No. 8,
pp. 70-76, August 1998.
[GLI] G. Li, et al., "Efficient Distributed Path Selection for
Shared Restoration Connections," IEEE Infocom 2002, New
York City, June 2002.
[IPO-IMP] Strand, J. and A. Chiu, "Impairments and Other
Constraints on Optical Layer Routing", RFC 4054, May
2005.
[KODIALAM1] M. Kodialam and T.V. Lakshman, "Restorable Dynamic
Quality of Service Routing," IEEE Communications
Magazine, pp. 72-81, June 2002.
[KODIALAM2] M. Kodialam and T.V. Lakshman, "Dynamic Routing of
Restorable Bandwidth-Guaranteed Tunnels using Aggregated
Network Resource Usage Information," IEEE/ ACM
Transactions on Networking, pp. 399-410, June 2003.
[MANCHESTER] J. Manchester, P. Bonenfant and C. Newton, "The
Evolution of Transport Network Survivability," IEEE
Communications Magazine, August 1999.
[RFC3386] Lai, W. and D. McDysan, "Network Hierarchy and
Multilayer Survivability", RFC 3386, November 2002.
[T1.105] ANSI, "Synchronous Optical Network (SONET): Basic
Description Including Multiplex Structure, Rates, and
Formats," ANSI T1.105, January 2001.
[WANG] J. Wang, L. Sahasrabuddhe, and B. Mukherjee, "Path vs.
Subpath vs. Link Restoration for Fault Management in
IP-over-WDM Networks: Performance Comparisons Using
GMPLS Control Signaling," IEEE Communications Magazine,
pp. 80-87, November 2002.
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.709] ITU-T, "Network Node Interface for the Optical Transport
Network (OTN)," Recommendation G.709, February 2001 (and
Amendment no.1, October 2001).
[G.783] ITU-T, "Characteristics of Synchronous Digital Hierarchy
(SDH) Equipment Functional Blocks," Recommendation
G.783, October 2000.
[G.798] ITU-T, "Characteristics of optical transport network
hierarchy equipment functional block," Recommendation
G.798, June 2004.
[G.806] ITU-T, "Characteristics of Transport Equipment -
Description Methodology and Generic Functionality",
Recommendation G.806, October 2000.
[G.841] ITU-T, "Types and Characteristics of SDH Network
Protection Architectures," Recommendation G.841, October
1998.
[G.842] ITU-T, "Interworking of SDH network protection
architectures," Recommendation G.842, October 1998.
[G.874] ITU-T, "Management aspects of the optical transport
network element," Recommendation G.874, November 2001.
Editors’ Addresses
Dimitri Papadimitriou
Alcatel
Francis Wellesplein, 1
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel.be
Eric Mannie
Perceval
Rue Tenbosch, 9
1000 Brussels
Belgium
Phone: +32-2-6409194
EMail: eric.mannie@perceval.net
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
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.
Intellectual Property
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 documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).