[3] K. Owens, V. Sharma, and M. Oommen, "Network Survivability
Considerations for Traffic Engineered IP Networks", Work in
Progress.
[4] V. Sharma, B. Crane, S. Makam, K. Owens, C. Huang, F.
Hellstrand, J. Weil, L. Andersson, B. Jamoussi, B. Cain, S.
Civanlar, and A. Chiu, "Framework for MPLS-based Recovery", Work
in Progress.
[5] M. Thorup, "Fortifying OSPF/ISIS Against Link Failure",
http://www.research.att.com/~mthorup/PAPERS/lf_ospf.ps
[6] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I. and X. Xiao,
"Overview and Principles of Internet Traffic Engineering", RFC
3272, May 2002.
[7] S. Dharanikota, R. Jain, D. Papadimitriou, R. Hartani, G.
Bernstein, V. Sharma, C. Brownmiller, Y. Xue, and J. Strand,
"Inter-domain routing with Shared Risk Groups", Work in
Progress.
[8] N. Harrison, P. Willis, S. Davari, E. Cuevas, B. Mack-Crane, E.
Franze, H. Ohta, T. So, S. Goldfless, and F. Chen, "Requirements
for OAM in MPLS Networks," Work in Progress.
[9] D. Allan and M. Azad, "A Framework for MPLS User Plane OAM,"
Work in Progress.
[10] S. Kini, M. Kodialam, T.V. Lakshman, S. Sengupta, and C.
Villamizar, "Shared Backup Label Switched Path Restoration,"
Work in Progress.
[11] G. Li, C. Kalmanek, J. Yates, G. Bernstein, F. Liaw, and V.
Sharma, "RSVP-TE Extensions For Shared-Mesh Restoration in
Transport Networks", Work in Progress.
[12] P. Pan (Editor), D.H. Gan, G. Swallow, J. Vasseur, D. Cooper, A.
Atlas, and M. Jork, "Fast Reroute Extensions to RSVP-TE for LSP
Tunnels", Work in Progress.
[13] A. Atlas, C. Villamizar, and C. Litvanyi, "MPLS RSVP-TE
Interoperability for Local Protection/Fast Reroute", Work in
Progress.
[14] A. Chiu and J. Strand, "Joint IP/Optical Layer Restoration after
a Router Failure", Proc. OFC'2001, Anaheim, CA, March 2001.
[15] K. Kompella and Y. Rekhter, "Multi-area MPLS Traffic
Engineering", Work in Progress.
[16] G. Ash, et. al., "Requirements for Multi-Area TE", Work in
Progress.
[17] A. Iwata, N. Fujita, G.R. Ash, and A. Farrel, "Crankback Routing
Extensions for MPLS Signaling", Work in Progress.
[18] C-Y Lee, A. Celer, N. Gammage, S. Ghanti, G. Ash, "Distributed
Route Exchangers", Work in Progress.
[19] C-Y Lee and S. Ghanti, "Path Request and Path Reply Message",
Work in Progress.
[20] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J.
McManus, "Requirements for Traffic Engineering Over MPLS", RFC
2702, September 1999.
[21] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC2401, November 1998.
8. Acknowledgments
A lot of the direction taken in this document, and by the team in its
initial effort was steered by the insightful questions provided by
Bala Rajagoplan, Greg Bernstein, Yangguang Xu, and Avri Doria. The
set of questions is attached as Appendix A in this document.
After the release of the first draft, a number of comments were
received. Thanks to the inputs from Jerry Ash, Sudheer Dharanikota,
Chuck Kalmanek, Dan Koller, Lyndon Ong, Steve Plote, and Yong Xue.
9. Contributing Authors
Jim Boyle (PDNets), Rob Coltun (Movaz), Tim Griffin (AT&T), Ed Kern,
Tom Reddington (Lucent) and Malin Carlzon.
Appendix A: Questions used to help develop requirements
A. Definitions
1. In determining the specific requirements, the design team should
precisely define the concepts "survivability", "restoration",
"protection", "protection switching", "recovery", "re-routing"
etc. and their relations. This would enable the requirements doc
to describe precisely which of these will be addressed. In the
following, the term "restoration" is used to indicate the broad
set of policies and mechanisms used to ensure survivability.
B. Network types and protection modes
1. What is the scope of the requirements with regard to the types of
networks covered? Specifically, are the following in scope:
Restoration of connections in mesh optical networks (opaque or
transparent)
Restoration of connections in hybrid mesh-ring networks
Restoration of LSPs in MPLS networks (composed of LSRs overlaid on
a transport network, e.g., optical)
Any other types of networks?
Is commonality of approach, or optimization of approach more
important?
2. What are the requirements with regard to the protection modes to
be supported in each network type covered? (Examples of protection
modes include 1+1, M:N, shared mesh, UPSR, BLSR, newly defined
modes such as P-cycles, etc.)
3. What are the requirements on local span (i.e., link by link)
protection and end-to-end protection, and the interaction between
them? E.g.: what should be the granularity of connections for
each type (single connection, bundle of connections, etc).
C. Hierarchy
1. Vertical (between two network layers):
What are the requirements for the interaction between restoration
procedures across two network layers, when these features are
offered in both layers? (Example, MPLS network realized over pt-
to-pt optical connections.) Under such a case,
(a) Are there any criteria to choose which layer should provide
protection?
(b) If both layers provide survivability features, what are the
requirements to coordinate these mechanisms?
(c) How is lack of current functionality of cross-layer
coordination currently hampering operations?
(d) Would the benefits be worth additional complexity associated
with routing isolation (e.g. VPN, areas), security, address
isolation and policy / authentication processes?
2. Horizontal (between two areas or administrative subdivisions
within the same network layer):
(a) What are the criteria that trigger the creation of protocol or
administrative boundaries pertaining to restoration? (e.g.,
scalability? multi-vendor interoperability? what are the
practical issues?) multi-provider? Should multi-vendor
necessitate hierarchical separation?
When such boundaries are defined:
(b) What are the requirements on how protection/restoration is
performed end-to-end across such boundaries?
(c) If different restoration mechanisms are implemented on two
sides of a boundary, what are the requirements on their
interaction?
What is the primary driver of horizontal hierarchy? (select one)
- functionality (e.g. metro -v- backbone)
- routing scalability
- signaling scalability
- current network architecture, trying to layer on TE on top
of an already hierarchical network architecture
- routing and signalling
For signalling scalability, is it
- manageability
- processing/state of network
- edge-to-edge N^2 type issue
For routing scalability, is it
- processing/state of network
- are you flat and want to go hierarchical
- or already hierarchical?
- data or TDM application?
D. Policy
1. What are the requirements for policy support during
protection/restoration, e.g., restoration priority, preemption,
etc.
E. Signaling Mechanisms
1. What are the requirements on the signaling transport mechanism
(e.g., in-band over SDH/SONET overhead bytes, out-of-band over an
IP network, etc.) used to communicate restoration protocol
messages between network elements? What are the bandwidth and
other requirements on the signaling channels?
2. What are the requirements on fault detection/localization
mechanisms (which is the prelude to performing restoration
procedures) in the case of opaque and transparent optical
networks? What are the requirements in the case of MPLS
restoration?
3. What are the requirements on signaling protocols to be used in
restoration procedures (e.g., high priority processing, security,
etc)?
4. Are there any requirements on the operation of restoration
protocols?
F. Quantitative
1. What are the quantitative requirements (e.g., latency) for
completing restoration under different protection modes (for both
local and end-to-end protection)?
G. Management
1. What information should be measured/maintained by the control
plane at each network element pertaining to restoration events?
2. What are the requirements for the correlation between control
plane and data plane failures from the restoration point of view?
Editors' Addresses
Wai Sum Lai
AT&T
200 Laurel Avenue
Middletown, NJ 07748, USA
Phone: +1 732-420-3712
EMail: wlai@att.com
Dave McDysan
WorldCom
22001 Loudoun County Pkwy
Ashburn, VA 20147, USA
EMail: dave.mcdysan@wcom.com
Full Copyright Statement
Copyright (C) The Internet Society (2002). 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.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.