Internet Draft Ajay Sathyanath Zbigniew Dziong Expires April 2003 Ramesh Nagarajan Y.T. Wang Bharat T. Doshi Lucent Technologies October 2002 OSPF-TE Extensions for Shared Mesh Protection 1. Status of this Memo This document is an Internet-Draft and is in full conformance with 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. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference 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. 2. Abstract This document describes extensions to the OSPF[1]/OSPF-TE[2] protocol to support Sharing/Restoration information, using opaque LSAs. The extension presented here enables the source router to obtain a backup route to a destination such that minimal amount of protection bandwidth reservation is needed. In other words, we provide a method by which one may easily increase sharing of backup links significantly, without having to go through each and every possible backup route. 3. Introduction This document specifies a method of adding shared mesh protection information to OSPF [1]/OSPF-TE[2]. Sharing/Restoration information is needed so as to enable routers identify the optimal combination of primary and restoration paths, from source to destination, such that shared-mesh-protection-ospf-extension-Sathyanath October 2002 draft-sathyanath-ospf-mpls-shared-protection-00.txt [Page 2] the amount of bandwidth that needs to be reserved on the restoration path is minimal. There are many kinds of restoration, and this document makes no effort to talk about the various kinds, or the pros and cons of any. For a more detailed discussion of the framework of MPLS-based recovery, one should refer to [3]. For shared mesh protection discussion, one should refer to [9]. In this document we address the issue of supporting shared mesh protection, in meshed networks, that is guaranteed for one failure at a time. Here we assume that the restoration path is disjoint from the primary path and is pre-computed and reserved at the time of the primary path setup. In particular it means that the restoration bandwidth is only reserved for the pre-computed protection path. Once the failure of a primary path is identified, the protection path is activated by physically allocating the reserved bandwidth, thus fast restoration can be supported. This feature allows to share the reserved restoration bandwidth on a particular link among multiple other connections that do not have common elements (links, nodes) in their primary paths (except the source and destination nodes). The pre-computation of the protection path can be done in several ways depending on the available information. The simplest way is to calculate a disjoint path using the same link weights as the ones used for calculation of the primary path. In this case one can use the RSVP extensions [4] to compute locally, at every router along the protection path, the amount of shared protection bandwidth required on each of the links constituting the restoration path. While some sharing of protection bandwidth may be realized in this approach, the amount of bandwidth reserved for recovery is usually not minimized since the sharing potential on each of the links is not known before the protection path choice is made at the source router. In the remainder of this document we describe extensions to OSPF-TE that provide sufficient information for efficient backup path calculation that significantly improves the network utilization. Given a primary path between a source-destination pair, there are a couple of methods to compute the optimal backup path. One way would be to compute the `N' disjoint paths (with respect to the given primary), and then start the resource signaling procedure (through protocols like RSVP) to compute the least amount of bandwidth that is required to be reserved on each hop (link). Extensions to RSVP-TE have been proposed to allow for this above computation, refer [4]. However, this leads to sending signaling messages across each of the nodes that constitute a backup path with likely crank-backs. The proposed extensions to OSPF-TE allow to compute the primary and backup paths combination that utilizes the network resources shared-mesh-protection-ospf-extension-Sathyanath October 2002 draft-sathyanath-ospf-mpls-shared-protection-00.txt [Page 3] efficiently with minimum signaling/crankback load. The extensions to OSPF-TE are meant to work alongside the RSVP-TE extensions [4]. Whilst, the latter provides the minimal topological information needed for guaranteed restoration, the former allows for efficient use of network resources. At the time of writing this document, there is no support in IS-IS to provide for the computation of backup paths. It is expected that the traffic engineering, and restoration extensions to IS-IS will continue to mirror those in OSPF. 3.1. Applicability Many of the extensions specified in this document are modeled after the extensions proposed by a popular draft on OSPF-TE [2]. The information made available by these extensions can be used to build an extended link state database just as router LSAs are used to build a "regular" link state database; the difference is that the extended link state database (referred to below as the TE/Share database) has additional link attributes. Uses of the TE/Share database include: - monitoring the extended link attributes, and o global optimal protection path computation. In order to support sharing/restoration, every router maintains a local sharing (now called TE/Share) database. This database contains an entry for every link that the router owns. Every link 'L' has information (bandwidth, link-id), about all the links in the network for which link 'L' provides restoration capacity. Since the above information could be huge, only changes in this database are advertised. A link is usually composed of two IP-addresses, and of course a router makes advertisements only about its side of the link (the outgoing interface). For example, let a link 'L' be part of a backup path, for which the primary path, of B1 bandwidth, passes through links L1, L2, and L3. Assuming that link L is not a part of any other backup path, then the advertisements of link L would be "B1::L1,L2,L3". If link 'L' now is used to provide restoration for another primary path, of B2 bandwidth, that passes through links L2, L4, L5. The advertisements of link L would then be "B1+B2:: L2; B2::L4,L5". We note here, that the new advertisement contained no information for links L1 and L3, as its protection bandwidth (as seen from L) did not change. Note that B1+B2 bandwidth is now required to protect against the failure of link L2 ; as two primary paths use link L2, each of which require B1 and B2 bandwidths, respectively. Every time a link is used as a backup link, by reserving the required shared-mesh-protection-ospf-extension-Sathyanath October 2002 draft-sathyanath-ospf-mpls-shared-protection-00.txt [Page 4] bandwidth, the TE/Share database is updated to reflect the changes. We must note here that this document does not overtly encourage the TE/Share database to be different from the LSA database. However, since we intend to keep the LSA advertisements as small as possible, we encourage only the changes to the TE/Share database to be advertised. This above criterion would demand a separate database on most OSPF implementations. This document does not provide a way to compute primary or backup paths, which is and should be implementation dependent. It however provides information needed to enable the choice of the best backup route (with respect to a given primary) from a network utilization standpoint. Note that the primary path is provided as a list of router-ids by the route-database module. However, to find out if indeed a primary path can be supported through the specified router- ids, and to determine the exact links it traverses through, a signaling protocol such as the proposed extension to RSVP-TE [4] would be required. 3.2. Basic Concept Let us call the set of links that constitute the primary path as the `P-Set'. Let the candidate backup path of the P-set in question be B-set : "L1, L2,...LN". Let B-Li set denote the set of links carrying the primay paths being protected by backup paths that use link Li. The following cases are then possible: a) If any of the B-Li-Set is null, then that link Li would have to reserve the required backup bandwidth. There is no sharing possible as far as Li is concerned, and this represents the initial case for Li, should this backup path be chosen. b) If the intersection between P-Set and any of the B-Li-Set of the B-set is null, then Li can potentially provide backup bandwidth sharing for the specified primary path, P-set. In particular, if the required backup bandwidth is less than what has already been reserved on Li, then no extra bandwidth reservation is required. Else, the difference between what is needed and what is already reserved is the additional amount of bandwidth required to support the new backup path, B-set. c) Let the non-null intersection between the P-Set and any of the B-Li-Set be represented as "La, Lb, Lc,...". Let each of the links in the above set have advertised bandwidths "Ba,Bb, Bc,...", respectively. Also, let the amount of backup bandwidth already reserved on link Li be Bm = MAX [Ba, Bb, Bc,...] shared-mesh-protection-ospf-extension-Sathyanath October 2002 draft-sathyanath-ospf-mpls-shared-protection-00.txt [Page 5] and the restoration bandwidth needed to support the new backup route be Br. Then, the amount of additional backup bandwidth that is required to be reserved in Li, is given by: MAX [ Z(Ba+Br - Bm), Z(Bb+Br - Bm), Z(Bc+Br - Bm),... ] Where Z(x) = x } if x > 0 = 0 } if x <= 0 Example: L1 L2 [R1:Source]-------------[R2]---------[R5:destination] | \ / | | \ L3 L4 / | | \-----------[R3]-----------/ | | L5 L6 | ------------[R4]----------------------- Consider the above figure which is a part of a network. Consider the primary path "L1, L2" with 4 units of bandwidth. Also let us assume that there are 2 possible disjoint routes (with respect to the primary path) to the destination, and that they are "L3, L4" and "L5, L6". Further, let us assume that the entries of current TE/Share DB are as shown below: Entry for L3 in TE/Share DB --> "4::L1, L8; 5::L10" Entry for L4 in TE/Share DB --> "4::L8, L9" Entry for L5 in TE/Share DB --> "4::L9, L10" Entry for L6 in TE/Share DB --> "4::L8, L10" where N::A,B,C means that links A, B, and C are the primary links, and that they need protection from this link of N units of bandwidth. S Now router R1, would compare the primary path "L1, L2" against the entries for every link in a backup path, and repeat this for all possible backup paths. Thus on comparing with path "L3, L4", it is found that link L1 is shared and that if router R1 were to choose this backup path, L3 would need to reserve 3 (4 + 4 - 5) additional units of bandwidth and none for L4. If however, backup path "L5, L6" were chosen, the intersection of P-set "L1,L2" and the B-set "L8,L9,L10" is null and no additional units of bandwidth would need to be reserved (since 4 units have been reserved already). Therefore under such circumstances the backup path "L5, L6" may be considered as a better backup path. shared-mesh-protection-ospf-extension-Sathyanath October 2002 draft-sathyanath-ospf-mpls-shared-protection-00.txt [Page 6] On the other hand, if the entries corresponding to L3 and L4 remain unaltered, but those corresponding to L5 and L6 have changed to as shown below: Entry for L5 in TE/Share DB --> "1::L9, L10" Entry for L6 in TE/Share DB --> "1::L8, L10" Then, we see that choosing the backup path "L5, L6" would require a total of 6 additional units of bandwidth, 3 each by link L5 and L6, to support a primary path of 4 units of bandwidth. This means that in this case, the path "L3, L4" would be a better choice since one needs to reserve only a total of 3 additional units of bandwidth. 3.3. Limitations The extensions specified in this document capture the reservation state of point-to-point links. The reservation state of multi-access links is not accurately reflected, except in the special case that there are only two devices in the multi-access subnetwork. This document also does not support unnumbered links. This deficiency is addressed in [5]; see also [6] and [7]. 4.0. LSA Format and Proposed Extensions The following subsections describe the LSA format and the proposed extensions. 4.1. LSA type This extension makes use of the Opaque LSA [8]. Three types of Opaque LSAs exist, each of which has different flooding scope. This proposal uses only Type 10 LSAs, which have area flooding scope. One new LSA is defined, the Shared Restoration LSA. This LSA describes routers, point-to-point links, and connections to multi- access networks (similar to a Router LSA). For traffic engineering purposes, the existing Network LSA suffices for describing multi- access links, so no additional LSA is defined for this purpose. 4.2. LSA ID The LSA ID of an Opaque LSA is defined as having eight bits of type and 24 bits of type-specific data. The Shared Restoration LSA uses type 2. The remaining 24 bits are broken up into eight bits of shared-mesh-protection-ospf-extension-Sathyanath October 2002 draft-sathyanath-ospf-mpls-shared-protection-00.txt [Page 7] reserved space (which must be zero) and sixteen bits of instance: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | Reserved | Instance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Instance field is an arbitrary value used to maintain multiple Shared Restoration LSAs. A maximum of 65536 Shared Restoration LSAs may be sourced by a single system. The LSA ID has no topological significance. 4.3. LSA Format Overview The LSA format is as explained. 4.3.1. LSA Header The Shared Restoration LSA starts with the standard LSA header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | Reserved | Instance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.3.2. TLV Header The LSA payload consists of one or more nested Type/Length/Value (TLV) triplets for extensibility. The format of each TLV is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ shared-mesh-protection-ospf-extension-Sathyanath October 2002 draft-sathyanath-ospf-mpls-shared-protection-00.txt [Page 8] | Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Length field defines the length of the value portion in octets (thus a TLV with no value portion would have a length of zero). The TLV is padded to four-octet alignment; padding is not included in the length field (so a three octet value would have a length of three, but the total size of the TLV would be eight octets). Nested TLVs are also 32-bit aligned. Unrecognized types are ignored. All types between 32768 and 65535 are reserved for vendor-specific extensions. All other undefined type codes are reserved for future assignment by IANA. 4.4. Extensions of LSA payload details A Shared Restoration LSA contains one top-level TLV. There is only one top-level TLV defined: 1 - Restoration TLV 4.4.1. Restoration TLV The Restoration TLV describes a single link of the advertising router. Only one Restoration TLV shall be carried in each LSA. The Link TLV is type 1, the length is variable and describes the length of the value field. The Link Type (1 octet), Local Interface Index (4 octets), Local Interface IP Addr (4 octets) are mandatory, i.e., must appear exactly once. The value of the reserved field should be zero, and is reserved for future use. All other fields defined are present conditional to the value of the Resource Flag field. The Link Type field defines the type of the link: 1 - Point-to-point, 2 - Multiaccess The Local Interface IP Address field specifies the IP address of the interface corresponding to this link. This field is 4 octets in length. Presently only IPV4 is supported, in the future, if IPV6 addresses are required, the Reserved field can be used to specify this and the length of the TLV can be appropriately increased. The first octet of the value field, the Resource Flag, describes the kind of resources that follow. If Resource Flag is set to `0x01', shared-mesh-protection-ospf-extension-Sathyanath October 2002 draft-sathyanath-ospf-mpls-shared-protection-00.txt [Page 9] only the Restoration bandwidth and the Maximum Restoration Bandwidth is present, where restoration bandwidth is the currently allocated restoration bandwidth on that link and the Maximum Restoration Bandwidth is the maximum amount of restoration bandwidth allowed on that link. Both the Restoration Bandwidth and the Maximum Restoration Bandwidth field are expressed in IEEE floating point format, and specified in bytes. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resource Flag | Link Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Interface IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Restoration Bandwidth On This Link | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Restoration Bandwidth On this Link | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If the Resource Flag is set to `0x10', the Restoration Bandwidth and the Maximum Restoration Bandwidth fields are absent. What follows in the LSA, are the various primary links that this link provides backup for, and the bandwidth on each of them. The Bandwidth field describes the amount of Bandwidth in IEEE format, in bytes. The Primary Links fields following the Bandwidth field are the primary links for which this link provides backup for, and whose bandwidth on each of them is specified by the Bandwidth field. Once again only IPV4 addresses are supported. The Reserved field may be used in the future to indicate IPV6 addresses. The Number of Primary Links field describes the number of primary links that follow the Bandwidth field. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resource Flag | Link Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Interface IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Primary Links | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Primary Link -1 (IP Addr) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ........... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Primary Link -N (IP Addr) | shared-mesh-protection-ospf-extension-Sathyanath October 2002 draft-sathyanath-ospf-mpls-shared-protection-00.txt [Page 10] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Primary Links | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Primary Link -1 (IP Addr) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ........... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Primary Link -N (IP Addr) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ........... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ........... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Primary Link -N (IP Addr) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If the Resource Flag is set to `0x20', once again the Restoration Bandwidth and Maximum Restoration Bandwidth fields are absent. What follows in the LSA, are the various primary links that this link provides backup for. This case is similar to the case `0x10', except that this case addresses the issue of finding bandwidth sharing, rather than the actual amount of bandwidth that is shared. In a way, this is a binary form of the previous case, wherein the problem of "can sharing be done" is addressed in a true or false form. Once again all IP addresses are IPV4, with the insight that the Reserved field may be used in the future to indicate IPV6 addresses. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resource Flag | Link Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Interface IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Primary Link -1 (IP Addr) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ........... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ........... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Primary Link -N (IP Addr) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cases, wherein the Resource Flag is set to `0x11', and `0x21' are shared-mesh-protection-ospf-extension-Sathyanath October 2002 draft-sathyanath-ospf-mpls-shared-protection-00.txt [Page 11] similar to cases `0x10' and `0x20', respectively. However, the Restoration Bandwidth and the Maximum Restoration Bandwidth fields are also present. Note that with resource flag set to 0x11, the source router would have most and sufficiently detailed information about the constraint and degree of sharing of link restoration bandwidths during the computation of backup path. Use of other modes trades away the network utilization with less information for advertisement and local bookkeeping. 5.0. Elements of Procedure Routers shall originate Shared Restoration LSAs whenever the TE/Share database, as described in section 1.1 changes, and whenever otherwise required by OSPF (an LSA refresh, for example). Upon receipt of a changed Shared Restoration LSA, a router should update its TE/Share database. No SPF or other route calculations are necessary. 6.0. Compatibility Issues There should be no inter-operability issues with routers that do not implement these extensions, as the Opaque LSAs will be silently ignored. The result is however the network will not be able to utilize the resource efficiently and may fail to find backup path when there is a viable one. 7.0. Security Considerations This document raises no new security issues for OSPF. 8.0. Acknowledgments We would like to thank Akber Qureshi, and Bharath Ramanna for providing insight, and and with their helpful comments. 9.0. References [1] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [2] Dave Katz, Derek Yeung, et al, "Traffic Engineering Extensions to OSPF", Internet Draft. [3] Vishal Sharma, Fiffi Hellstrand, et.al, "Framework for MPLS-based Recovery," IETF draft-ietf-mpls-recovery-frmwrk-07.txt, sept,2002 shared-mesh-protection-ospf-extension-Sathyanath October 2002 draft-sathyanath-ospf-mpls-shared-protection-00.txt [Page 12] [4] Hua Autumn Liuh, et al, "RSVP-TE Extension for Shared Mesh Protection", IETF draft-liu-rsvp-mpls-shared-protection-00.txt, Oct.,2002 [5] Kompella, K., Rekhter, Y., et al, "OSPF Extensions in Support of Generalized MPLS," IETF draft-ietf-ccamp-ospf-gmpls-extensions- 08.txt, Aug 2002 [6] Kompella, K., Rekhter, Y., and Kullberg, A., "Signaling Unnumbered Links in CR-LDP," IETF draft-ietf-mpls-crldp-unnum-07.txt. July 2002 [7] Kompella, K., and Rekhter, Y., "Signaling Unnumbered Links in RSVP-TE," IETF draft-ietf-mpls-rsvp-unnum-07.txt, July 2002 [8] Coltun, R., "The OSPF Opaque LSA Option," RFC 2370, July 1998. [9] Qureshi, M., et.al, "MPLS-TE Shared Mesh Protection,", IETF draft-qureshi-mpls-shared-protection-00.txt, Oct.,2002 10.0. Intellectual Property Considerations Lucent Technologies Inc. may own intellectual property in some on some of the technologies disclosed in this document. The patent licensing policy of Lucent Technologies Inc. with respect to any patents or patent applications relating to this submission is stated in the March 1, 1999, letter to the IETF from Dr Roger E. Stricker, Intellectual Property Vice President, Lucent Technologies, Inc. This letter is on file in the offices of the IETF Secretariat. 11.0. Author Information Ajay Sathyanath Lucent Technologies 101 Crawfords Corner Rd. Holmdel, NJ 07733 e-mail: ajays@lucent.com phone: +1 732 332 6049 Zbigniew Dziong Lucent Technologies 101 Crawfords Corner Rd. Holmdel, NJ 07733 e-mail: zdziong@lucent.com phone: +1 732 949 2459 Ramesh Nagarajan Lucent Technologies shared-mesh-protection-ospf-extension-Sathyanath October 2002 draft-sathyanath-ospf-mpls-shared-protection-00.txt [Page 13] 101 Crawfords Corner Rd. Holmdel, NJ 07733 e-mail: rameshn@lucent.com phone: +1 732 949 2761 Y.T. Wang Lucent Technologies 101 Crawfords Corner Rd. Holmdel, NJ 07733 e-mail: ytwang@lucent.com phone: +1 732 949 0676 Bharat T. Doshi Lucent Technologies 101 Crawfords Corner Rd. Holmdel, NJ 07733 e-mail: bdoshi@lucent.com phone: +1 732 332 0823 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 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. shared-mesh-protection-ospf-extension-Sathyanath October 2002