--- 1/draft-ietf-mpls-rsvp-lsp-fastreroute-01.txt 2006-02-05 00:42:31.000000000 +0100 +++ 2/draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt 2006-02-05 00:42:31.000000000 +0100 @@ -1,22 +1,22 @@ Internet Draft Ping Pan, Ed (Ciena Corp) -Expires: May 2003 Der-Hwa Gan (Juniper Networks) +Expires: Aug 2003 Der-Hwa Gan (Juniper Networks) George Swallow (Cisco Systems) Jean Philippe Vasseur (Cisco Systems) Dave Cooper (Global Crossing) Alia Atlas, Ed (Avici Systems) Markus Jork (Avici Systems) Fast Reroute Extensions to RSVP-TE for LSP Tunnels - draft-ietf-mpls-rsvp-lsp-fastreroute-01.txt + draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt 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. @@ -27,82 +27,82 @@ 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. Abstract - This document defines extensions to and describes the use of RSVP - [RSVP, RSVP-TE] to establish backup LSP tunnels for local repair of - LSP tunnels. These mechanisms enable the re-direction of traffic + This document defines extensions to and describes the use of RSVP to + establish backup label-switched path (LSP) tunnels for local repair + of LSP tunnels. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds in the event of a failure. Two methods are defined here. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point; by taking advantage of MPLS label stacking, this bypass tunnel can protect a set of protected LSPs that have similar backup constraints. Both methods can be used to protect links and nodes during network failure. The described behavior and - extensions to RSVP allow LERs and LSRs to implement either or both - methods and to interoperate in a mixed network. + extensions to RSVP allow nodes to implement either or both methods + and to interoperate in a mixed network. Contents 1 Introduction ............................................. 4 2 Terminology ............................................... 4 3 Local Repair Techniques ................................... 6 - 3.1 One-to-one Backup ....................................... 6 - 3.2 Facility Backup ......................................... 7 + 3.1 One-to-one Backup .................................... 6 + 3.2 Facility Backup ...................................... 7 4 RSVP Extensions ........................................... 8 - 4.1 FAST_REROUTE Object ..................................... 8 - 4.2 DETOUR Object ........................................... 11 - 4.3 SESSION_ATTRIBUTE Flags ................................. 12 - 4.4 RRO IPv4/IPv6 Sub-Object Flags .......................... 13 + 4.1 FAST_REROUTE Object .................................... 8 + 4.2 DETOUR Object .......................................... 11 + 4.3 SESSION_ATTRIBUTE Flags ................................ 12 + 4.4 RRO IPv4/IPv6 Sub-Object Flags ......................... 13 5 Head-End Behavior ......................................... 14 6 Point of Local Repair Behavior ............................ 15 - 6.1 Signaling a Backup Path ................................. 16 - 6.1.1 Backup Path Identification: Sender-Template Specific ... 17 - 6.1.2 Backup Path Identification: Path-Specific ............. 18 - 6.2 Procedures for Backup Path Computation .................. 18 - 6.3 Signaling Backups for One-To-One Protection ............. 20 - 6.3.1 Make-Before-Break with Detour LSPs .................... 21 - 6.3.2 Message Handling ...................................... 21 - 6.3.3 Local Reroute of Traffic Onto Detour LSP .............. 22 - 6.4 Signaling for Facility Protection ....................... 23 - 6.4.1 Discovering Downstream Labels ......................... 23 - 6.4.2 Procedures for the PLR before Local Repair ............ 23 - 6.4.3 Procedures for the PLR during Local Repair ............ 23 - 6.4.4 Processing backup tunnel's ERO ........................ 24 - 6.5 PLR Procedures During Local Repair ...................... 25 - 6.5.1 Notification of local repair .......................... 25 - 6.5.2 Revertive Behavior .................................... 26 + 6.1 Signaling a Backup Path ................................ 16 + 6.1.1 Backup Path Identification: Sender-Template Specific . 17 + 6.1.2 Backup Path Identification: Path-Specific ........... 18 + 6.2 Procedures for Backup Path Computation ................. 18 + 6.3 Signaling Backups for One-To-One Protection ............ 20 + 6.3.1 Make-Before-Break with Detour LSPs .................. 21 + 6.3.2 Message Handling .................................... 21 + 6.3.3 Local Reroute of Traffic Onto Detour LSP ............ 22 + 6.4 Signaling for Facility Protection ...................... 23 + 6.4.1 Discovering Downstream Labels ....................... 23 + 6.4.2 Procedures for the PLR before Local Repair .......... 23 + 6.4.3 Procedures for the PLR during Local Repair .......... 23 + 6.4.4 Processing backup tunnel's ERO ...................... 24 + 6.5 PLR Procedures During Local Repair ..................... 25 + 6.5.1 Notification of local repair ........................ 25 + 6.5.2 Revertive Behavior .................................. 26 7 Merge Node Behavior ....................................... 27 - 7.1 Handling Backup Path Messages Before Failure ............ 27 + 7.1 Handling Backup Path Messages Before Failure ........... 27 7.1.1 Merging Backup Paths using the Sender-Template - Specific Method ....................................... 28 - 7.1.2 Merging Detours using Path-Specific Method ............ 28 - 7.1.2.1 An Example on Path Message Merging .................. 29 - 7.1.3 Message Handling for Merged Detours ................... 30 - 7.2 Handling Failures ....................................... 30 + Specific Method ..................................... 28 + 7.1.2 Merging Detours using Path-Specific Method .......... 28 + 7.1.2.1 An Example on Path Message Merging ............... 29 + 7.1.3 Message Handling for Merged Detours ................. 30 + 7.2 Handling Failures ...................................... 30 8 Behavior of all LSRs ...................................... 31 - 8.1 Merging Detours in Path-Specific Method ................. 31 + 8.1 Merging Detours in Path-Specific Method ................ 31 9 Security Considerations ................................... 32 10 IANA Guidelines ........................................... 32 11 Intellectual Property Considerations ...................... 32 12 Full Copyright Statement .................................. 32 13 Acknowledgments ........................................... 33 - 14 References ................................................ 33 + 14 Normative References ...................................... 33 15 Author Information ........................................ 33 1. Introduction This document extends RSVP [RSVP] to establish backup LSP tunnels for the local repair of LSP tunnels. This technique is presented to meet the needs of real-time applications, such as voice over IP, for which it is highly desirable to be able to re-direct user traffic onto backup LSP tunnels in 10s of milliseconds. This timing requirement can be satisfied by computing and signaling @@ -126,20 +126,33 @@ protection are described. In Section 5, the behavior of an LER which wishes to request local protection for an LSP is presented. The behavior of a potential point of local repair (PLR) is given in Section 6; this describes how to determine the appropriate strategy to use for protecting an LSP and how to implement each of the strategies. The behavior of a merge node, the LSR where a protected LSP and its backup LSP rejoin, is described in Section 7. Finally, the required behavior of other nodes in the network is discussed in Section 8. + For the techniques discussed in this document to function properly, + there are three assumptions which must be made. First, an LSR + which is on the path of a protected LSP SHOULD always assume that + it is a merge point; this is necessary because the facility backup + method does not signal backups through a bypass tunnel before + failure. Second, if the one-to-one backup method is used and a + DETOUR object is included, the LSRs in the traffic-engineered + network should support the DETOUR object; this is necessary so that + the Path message containing the DETOUR object is not rejected. + Third, understanding of the DETOUR object is required to support + the path-specific method which requires that LSRs in the + traffic-engineered network be capable of merging detours. + 2. Terminology 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 [RFC-WORDS]. The reader is assumed to be familiar with the terminology in [RSVP] and [RSVP-TE]. LSR - Label Switch Router @@ -470,21 +482,23 @@ is preferred. This field is mandatory, and is used by the MP for merging rules discussed below. There can be more than one pair of (PLR_ID, Avoid_Node_ID) entries in a DETOUR object. If detour merging is desired, after each merging operation, the Detour Merge Point should combine all the merged detours in the subsequent Path messages. The high-order bit of the C-Class is zero; LSRs that do not support the DETOUR objects MUST reject any Path message containing a DETOUR - object and send a PathErr to notify the PLR. + object and send a PathErr to notify the PLR. This PathErr SHOULD + be generated as specified in [RSVP] for unknown objects with a + class-num of the form "0bbbbbbb". 4.3. SESSION_ATTRIBUTE Flags To explicitly request bandwidth and node protection, two new flags are defined in the SESSION_ATTRIBUTE object. For both C-Type 1 and 7, the SESSION_ATTRIBUTE object currently has the following flags defined: Local protection desired: 0x01 @@ -588,25 +603,25 @@ SESSION_ATTRIBUTE object or include a FAST_REROUTE object in the PATH message or both. It is recommended that the "local protection desired" flag in the SESSION_ATTRIBUTE object always be set. If a head-end LSR signals a FAST_REROUTE object, it MUST be stored for Path refreshes. The head-end LSR of a protected LSP MUST set the "label recording desired" flag in the SESSION_ATTRIBUTE object. This facilitates the use of the facility backup technique. If node protection is desired, the head-end LSR should set the "node protection desired" - flag in the SESSION_ATTRIBUTE object; if only link protection is - desired, this flag should be cleared. Similarly, if a guarantee of - bandwidth protection is desired, then the "bandwidth protection - desired" flag in the SESSION_ATTRIBUTE object should be set; - otherwise, this flag should be cleared. + flag in the SESSION_ATTRIBUTE object; otherwise this flag should be + cleared. Similarly, if a guarantee of bandwidth protection is + desired, then the "bandwidth protection desired" flag in the + SESSION_ATTRIBUTE object should be set; otherwise, this flag should + be cleared. If the head-end LSR determines that control of the backup paths for the protected LSP is desired, then the LSR should include the FAST_REROUTE object. The attribute filters, bandwidth, hop-limit and priorities will be used by the PLRs when determining the backup paths. If the head-end LSR desires that the protected LSP be protected via the one-to-one backup technique, then head-end LSR should include a FAST_REROUTE object and set the "one-to-one backup desired" flag. @@ -641,21 +656,24 @@ A PLR MUST consider an LSP as having asked for local protection if the "local protection desired" flag is set in the SESSION_ATTRIBUTE object and/or the FAST_REROUTE object is included. If the FAST_REROUTE object is included, a PLR SHOULD consider providing one-to-one protection if the "one-to-one desired" is set and SHOULD consider providing facility backup if the "facility backup desired" flag is set when determining whether to provide local protection and which technique to use to provide that local protection. If the "node protection desired" flag is set, the PLR SHOULD try to provide node protection; if this is not feasible, the PLR SHOULD - then try to provide link protection. + then try to provide link protection. If the "bandwidth protection + guaranteed" flag is set, the PLR SHOULD try to provide a bandwidth + guarantee; if this is not feasible, the PLR SHOULD then try to + provide a backup without a guarantee of the full bandwidth. The following treatment for the RRO IPv4 or IPv6 sub-object's flags must be followed if an RRO is included in the protected LSP's RESV message. Based on this additional information the head-end may take appropriate actions. - Until a PLR has a backup path available, the PLR MUST clear the relevant four flags in the corresponding RRO IPv4 or IPv6 sub-object. @@ -737,24 +756,25 @@ backup path must inherit its LSP ID from the associated protected LSP. Thus, the only field in the SESSION and SENDER_TEMPLATE objects which could be varied between a backup path and a protected LSP is the "IPv4 (or IPv6) tunnel sender address" in the SENDER_TEMPLATE. There are two different methods to uniquely identify a backup path. These are described below. 6.1.1. Backup Path Identification: Sender-Template-Specific + In this approach, the SESSION object and the LSP_ID are copied from the protected LSP. The "IPv4 tunnel sender address" is set to an address of the PLR. If the head-end of a tunnel is also acting as - the PLR, it must choose an IP address different from the one used + the PLR, it MUST choose an IP address different from the one used in the SENDER_TEMPLATE of the original LSP tunnel. When using the sender-template-specific approach, the protected LSPs and the backup paths SHOULD use the Shared Explicit (SE) style. This allows bandwidth sharing between multiple backup paths. The backup paths and the protected LSP MAY be merged by the Detour Merge Points, when the ERO from the MP to the egress is the same on each LSP to be merged, as specified in [RSVP-TE]. 6.1.2. Backup Path Identification: Path-Specific @@ -767,21 +787,21 @@ Thus, the backup paths use the same SESSION and SENDER_TEMPLATE objects as the ones used in the protected LSP. The presence of DETOUR object in Path messages signifies a backup path; the presence of FAST_REROUTE object and/or the "local protection requested" flag in the SESSION_ATTRIBUTE object indicates a protected LSP. In the path-message-specific approach, when an LSR receives multiple Path messages which have the same SESSION and SENDER_TEMPLATE objects and also have the same next-hop, that LSR - must merge the Path messages. Without this behavior, the multiple + MUST merge the Path messages. Without this behavior, the multiple RESV messages received back would not be distinguishable as to which backup path each belongs to. This merging behavior does reduce the total number of RSVP states inside the network at the expense of merging LSPs with different EROs. 6.2 Procedures for Backup Path Computation Before a PLR can create a detour or a bypass tunnel, the desired explicit route must be determined. This can be done using a CSPF. @@ -842,23 +862,23 @@ would be used twice in the event of a failure. - The backup LSP cannot traverse the downstream node and/or link whose failure is being protected against. Note that if the PLR is the penultimate hop, node protection is not possible and only the downstream link can be avoided. The backup path may be computed to be SRLG disjoint from the downstream node and/or link being avoided. - The backup path must satisfy the resource requirements of the - protected LSP. This SHOULD consider the link attribute - filters, bandwidth, and hop limits determined from the - FAST_REROUTE object and SESSION_ATTRIBUTE object. + protected LSP. This includes the link attribute filters, + bandwidth, and hop limits determined from the FAST_REROUTE + object and SESSION_ATTRIBUTE object. If such computation succeeds, the PLR should attempt to establish a backup path. The PLR may schedule a re-computation at a later time to discover better paths that may have emerged. If for any reason, the PLR is unable to bring up a backup path, it must schedule a retry at a later time. 6.3 Signaling Backups for One-To-One Protection Once a PLR has decided to locally protect an LSP with one-to-one @@ -876,33 +896,33 @@ DETOUR object MAY be added to the PATH message. - If the path-specific method is to be used, then the PLR MUST add a DETOUR object to the PATH message. - The SESSION_ATTRIBUTE flags "Local protection desired", "Bandwidth protection desired" and "Node protection desired" MUST be cleared. The "Label recording desired" flag MAY be modified. If the Path Message contained a FAST_REROUTE object, and the ERO is not completely strict, the Include-any, Exclude-any, and - Include-all fields of the FAST_REROUTE object should be copied to + Include-all fields of the FAST_REROUTE object SHOULD be copied to the corresponding fields of the SESSION_ATTRIBUTE object. - If the protected LSP's Path message contained a FAST_REROUTE object, this MUST be removed from the detour LSP's PATH message. - - The PLR must generate an EXPLICIT_ROUTE object toward the egress. + - The PLR MUST generate an EXPLICIT_ROUTE object toward the egress. First, the PLR must remove all sub-objects preceding the first - address belonging to the Merge Point. Then the PLR should add + address belonging to the Merge Point. Then the PLR SHOULD add sub-objects corresponding to the desired backup path between the PLR and the MP. - - The SENDER_TSPEC object should contain the bandwidth information + - The SENDER_TSPEC object SHOULD contain the bandwidth information from the received FAST_REROUTE object, if included in the protected LSP's PATH message. - The RSVP_HOP object containing one of the PLR's IP address. - The detour LSPs MUST use the same reservation style as the protected LSP. This must be correctly reflected in the SESSION_ATTRIBUTE object. Detour LSPs are regular LSPs in operation. Once a detour path is @@ -1006,24 +1026,25 @@ When MPs use per-interface-label spaces, the PLR must send Path messages (for each protected LSP using a bypass tunnel) via that bypass tunnel prior to the failure in order to discover the appropriate MP label. The signaling procedures for this are in Section 6.4.3 below. 6.4.2. Procedures for the PLR before Local Repair A PLR which determines to use facility-backup to protect a given - LSP SHOULD select a bypass tunnel to use taking into account + LSP should select a bypass tunnel to use taking into account whether node protection is to be provided, what bandwidth was requested and whether a bandwidth guarantee is desired, and what link attribute filters were specified in the FAST_REROUTE object. + The selection of a bypass tunnel for a protected LSP is performed by the PLR when the LSP is first setup. 6.4.3. Procedures for the PLR during Local Repair When the PLR detects a link or/and node failure condition, it needs to reroute the data traffic onto the bypass tunnel and to start sending the control traffic for the protected LSP onto the bypass tunnel. @@ -1034,38 +1055,38 @@ - The SESSION is unchanged. - The SESSION_ATTRIBUTE is unchanged except as follows: The "Local protection desired", "Bandwidth protection desired", and "Node protection desired" flags SHOULD be cleared. The "Label recording desired" MAY be modified. - The IPv4 (or IPv6) tunnel sender address of the SENDER_TEMPLATE is set to an address belonging to the PLR. - - The RSVP_HOP object must contain an IP source address + - The RSVP_HOP object MUST contain an IP source address belonging to the PLR. Consequently, the MP will send messages back to the PLR using as a destination that IP address. - - The PLR must generate an EXPLICIT_ROUTE object toward the + - The PLR MUST generate an EXPLICIT_ROUTE object toward the egress. Detailed ERO processing is described below. - The RRO object may need to be updated, as described in Section 6.5. The PLR sends Path, PathTear, and ResvConf messages via the backup tunnel. The MP sends Resv, ResvTear, and PathErr messages by directly addressing them to the address in the RSVP_HOP object contents as specified in [RSVP]. If it is necessary to signal the backup prior to failure to determine the MP label to use, then the same Path message is sent. - In this case, the PLR should continue to send Path messages for the + In this case, the PLR SHOULD continue to send Path messages for the protected LSP along the normal route. PathTear messages should be duplicated, with one sent along the normal route and one sent thru the bypass tunnel. The MP should duplicate the Resv and ResvTear messages and sent them to both the PLR and the LSR indicated by the protected LSP's RSVP_HOP object. 6.4.4. Processing backup tunnel's ERO Procedures for ERO processing are described in [RSVP-TE]. This section describes additional ERO update procedures for Path messages @@ -1075,42 +1096,38 @@ unmodified ERO might contain the IP address of a bypassed node (in the case of a NNHOP Backup Tunnel), or of an interface which is currently down (in the case of a NHOP Backup Tunnel). For this reason, the PLR invoke the following ERO procedures before sending a Path message via a bypass tunnel. Sub-objects belonging to abstract nodes which precede the Merge Point are removed, along with the first sub-object belonging to the MP. A sub-object identifying the Backup Tunnel destination is then added. - More specifically, the PLR must: + More specifically, the PLR MUST: - remove all the sub-objects proceeding the first address belonging to the MP. - replace this first MP address with an IP address of the MP. (Note that this could be same address that was just removed.) 6.5. PLR Procedures During Local Repair In addition to the technique specific signaling and packet treatment, there is common signaling which should be followed. During fast reroute, for each protected LSP containing an RRO object, the PLR obtains the RRO from the protected LSP's stored - RESV and updates it by inserting an IPv4 sub-object with the IPv4 - address of the outbound interface address the traffic is forwarded - onto. - - The PLR MUST update the IPv4 or IPv6 sub-object it - inserted into the RRO by setting the "Local protection in use" and - "Local Protection Available" flags. + RESV. The PLR MUST update the IPv4 or IPv6 sub-object it inserted + into the RRO by setting the "Local protection in use" and "Local + Protection Available" flags. 6.5.1. Notification of local repair In many situations, the route used during a Local Repair will be less than optimal. The purpose of Local Repair is to keep high priority and loss sensitive traffic flowing while a more optimal re-routing of the tunnel can be effected by the head-end of the tunnel. Thus the head-end needs to know of the failure so it may re-signal an LSP which is optimal. @@ -1227,49 +1245,50 @@ 7.1.1. Merginging Backup Paths using the Sender-Template Specific Method An LSR may receive multiple Path messages for one or more backup LSPs and, possibly, the protected LSP. Each of these Path messages will have a different SENDER_TEMPLATE. The protected LSP can be recognized because it will either include the FAST_REROUTE object, have the "local protection desired" flag set in the SESSION_ATTRIBUTE object or both. If the outgoing interface and next-hop LSR are the same, then the - Path messages are eligible for merging. As specified in [RSVP], - only those Path messages whose ERO from that LSR to the egress is - the same can be merged. If merging occurs and one of the Path - messages merged was for the protected LSP, then the final Path - message to be sent MUST be that of the protected LSP. This merges - the backup LSPs into the protected LSP at that LSR. Once the final - Path message has been identified, the MP MUST start to refresh it - downstream periodically. + Path messages are eligible for merging. Similar to that specified + in [RSVP-TE] for merging of RESV messages, only those Path messages + whose ERO from that LSR to the egress is the same can be merged. + If merging occurs and one of the Path messages merged was for the + protected LSP, then the final Path message to be sent MUST be that + of the protected LSP. This merges the backup LSPs into the + protected LSP at that LSR. Once the final Path message has been + identified, the MP MUST start to refresh it downstream + periodically. If merging occurs and all the Path messages were for backup LSPs, then the DETOUR object, if any, should be altered as specified in Section 8.1 7.1.2. Merging Detours using the Path-Specific Method An LSR (that is, an MP) may receive multiple Path messages from different interfaces with identical SESSION and SENDER_TEMPLATE objects. In this case, Path state merging is REQUIRED. The merging rule is the following: For all Path messages that do not have either a FAST_REROUTE or a DETOUR object, or the MP is the egress of the LSP, no merging is required. The messages are processed according to [RSVP-TE]. Otherwise, the MP MUST record the Path state as well as their incoming interface. If the Path messages do not share outgoing - interface and next-hop LSR, the MP must consider them as independent - LSPs, and must not merge them. + interface and next-hop LSR, the MP MUST consider them as independent + LSPs, and MUST NOT merge them. For all the Path messages that share the same outgoing interface and next-hop LSR, the MP runs the following procedure to select one of them as the Path message to forward downstream. 1. Eliminate from consideration those that traverse nodes that other Path messages want to avoid. 2. If one LSP is originated from this node, this must be the final LSP. Quit. @@ -1326,24 +1346,24 @@ 7.1.3. Message Handling for Merged Detours When an LSR receives a ResvTear for an LSP, the LSR must determine whether it has an alternate associated LSP. For instance, if the ResvTear was received for a protected LSP, but an associated backup LSP has not received a ResvTear, then the LSR has an alternate associated LSP. If the LSR does not have an alternate associated LSP, then the MP MUST propogate the ResvTear toward the LSP's ingress and, for each backup LSP merged into that LSP at this LSR, - the ResvTear should also be propogated along the backup LSP. + the ResvTear SHOULD also be propogated along the backup LSP. The MP may receive PathTear messages for some of the merging LSPs. - No PathTear message should be propagated downstream until the MP + PathTear messages SHOULD NOT be propagated downstream until the MP has received PathTear messages for each of the merged LSPs. However, the fact that one or more of the merged LSPs has been torn down should be reflected in the downstream message, such as by changing the DETOUR object, if any. 7.2. Handling Failures When a downstream LSR detects a local link failure, for any protected LSPs routed over the failed link, Path and Resv state MUST NOT be cleared and PathTear and ResvErr messages MUST NOT be @@ -1453,42 +1473,33 @@ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 13. Acknowledgments We would like to acknowledge input and helpful comments from Rob Goguen, Tony Li, Yakov Rekhter and Curtis Villamizar. Especially, we thank those, who have been involved in interoperability testing and field trails, and provided invaluable ideas and suggestions. They are Rob Goguen, Carol Iturralde, Brook Bailey, Safaa Hasan, - and Richard Southern. + Richard Southern, and Bijan Jabbari. -14. References +14. Normative References [RSVP] R. Braden, Ed., et al, "Resource ReSerVation protocol (RSVP) -- version 1 functional specification," RFC2205, September 1997. [RSVP-TE] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP tunnels", RFC3029, December 2001. [RFC-WORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. - [OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF, - draft-katz-yeung-ospf-traffic-05.txt, June 2001. - - [ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft- - ietf-isis-tr affic-03.txt, June 2001. - - [RSVP-REFRESH] L. Berger, et al, "RSVP Refresh Overhead Reduction - Extensions", RFC2961. - [RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434. 15. Author Information Ping Pan CIENA Corp. 10480 Ridgeview Court Cupertino, CA 95014 e-mail: ppan@ciena.net