Network Working Group Adrian Farrel Internet Draft Old Dog Consulting Category: Standards Track Updates: RFC 3209 and RFC 3473 Expires: October 2004 April 2004 Multiprotocol Label Switching Pre-emption draft-farrel-mpls-preemption-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [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. Abstract Multiprotocol Label Switching (MPLS) signaling is documented in "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, using mechanisms inherited from "Resource ReserVation Protocol -- Version 1 Functional Specification", RFC 2205. MPLS includes the concept of pre-emption where, for administrative reasons such as contention for system resources, a new Label Switched Path (LSP) may displace an existing LSP. This document clarifies the procedures for MPLS pre-emption in the light of implementation experience. The procedures in this document updae those described in RFC 2205 and RFC 3209, but apply only to RSVP-TE used in the MPLS context. Farrel Page 1 draft-farrel-mpls-preemption-01.txt April 2004 1. Introduction Multiprotocol Label Switching (MPLS) traffic engineering Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering extensions (RSVP-TE). These extensions include support for the concept of pre-emption such that a high priority LSP may commandeer the resources of a lower priority LSP [RFC3209]. The signaling procedures for pre-emption described in [RFC3209] have proven to be sufficiently unclear that various different implementations have been deployed. In order that pre-emption can be successfully deployed in the future, multi-vendor networks, this document clarifies the procedures. 1.1 Summary of Unclarity The lack of clarity in interpretation of [RFC3209] centers around whether MPLS pre-emption is "hard" or "soft". In soft pre-emption the resources of the pre-empted LSP are sequestered for the new LSP, but the old LSP remains in place. Signaling state is not removed, labels are not removed, the data forwarding path remains intact, but the traffic is forwarded only as "best effort" over the links/nodes at which pre-emption has occurred. In hard pre-emption the resources of the old LSP are re-allocated to the new LSP in exactly the same way, but the old LSP is torn down. The forwarding path is immediately broken and each LSR along the LSP is notified that the LSP is no longer active. Signaling state is discarded. 1.2 Summary of Solution This document defines MPLS pre-emption mechanisms according to local policy on the pre-empting node, and according to the error code reported in the PathErr/ResvErr message at all other nodes. Both soft and hard pre-emption are supported. New RSVP Error Values are defined to distinguish the cases. 1.3 Backwards Compatibility It is not possible to provide interoperable backwards compatiblity between the two interpretations of [RFC3209] since they are fundamentally different. However, the solution proposed in this document is fully backward compatible with existing implementations since [RFC3209] only specifies an RSVP Error Code for use during pre-emption and does not provide a qualifying Error Value. Thus, existing implementations have no reason to check the Error Value and are not susceptible to a change in that value. Farrel Page 2 draft-farrel-mpls-preemption-01.txt April 2004 Note that it is possible that some existing implementations use the Error Value suggested in [RFC2750]. 5 = ERR_PREEMPT : Flow was preempted This would not affect backwards compatibility unless existing implementations give other Error Values different treatments within the same "Policy Control failure" Error Code. 1.4 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]. 2. General Priority and Pre-emption Procedures This document makes no changes to the procedures for signaling LSP setup and holding priorities as described in [RFC3209]. This document makes no change to the mechanisms by which the need for pre-emption is determined, or by which LSPs to be pre-empted are selected. 2.1 Choice of Hard or Soft Pre-emption It is a local implementation or policy choice whether hard or soft pre-emption is applied. This choice is made at the pre-empting LSR. 3. Hard Pre-emption Procedures 3.1 Pre-empting LSR When an LSR determines that it is pre-empting an LSP and that it will apply hard pre-emption it MUST: - surrender all resources for the old LSP - immediately stop forwarding data on the old LSP - treat received labeled packets for the old LSP as having an unknown label - send a PathErr upstream for the old LSP carrying the "Policy Control failure"/"Hard Pre-empted" error - send a ResvErr downstream for the old LSP carrying the "Policy Control failure"/"Hard Pre-empted" error and with the inPlace flag clear - discard all Path and Resv state for the LSP. An LSR MAY retain memory of discarded Path and Resv state for a short period to prevent refresh messages from attempting to re-establish state or causing subsequent error messages. Farrel Page 3 draft-farrel-mpls-preemption-01.txt April 2004 3.2 Upstream LSRs 3.2.1 Transit LSRs An upstream transit LSR that receives a PathErr message carrying the "Policy Control failure"/"Hard Pre-empted" error, MUST: - surrender all resources for the LSP - immediately stop forwarding data on the LSP - treat received labeled packets for the LSP as having an unknown label - send a PathErr further upstream carrying the "Policy Control failure"/"Hard Pre-empted" error - discard all Path and Resv state for the LSP. An LSR MAY retain memory of discarded Path state for a short period to prevent refresh messages from attempting to re-establish state or causing subsequent error messages. 3.2.2 Ingress LSR An ingress LSR that receives a PathErr message carrying the "Policy Control failure"/"Hard Pre-empted" error, MUST: - surrender all resources for the LSP - immediately stop forwarding data on the LSP - discard all Path and Resv state for the LSP. An ingress LSR SHOULD NOT send a PathTear for the pre-empted LSP. An ingress LSR MAY attempt to re-establish the pre-empted LSP according to local policy. 3.3 Downstream LSRs 3.3.1 Transit LSRs A downstream transit LSR that receives a ResvErr message carrying the "Policy Control failure"/"Hard Pre-empted" error, MUST: - surrender all resources for the LSP - immediately stop forwarding data on the LSP - treat received labeled packets for the LSP as having an unknown label - send a ResvErr further downstream carrying the "Policy Control failure"/"Hard Pre-empted" error and with the inPlace flag clear - discard all Path and Resv state for the LSP. An LSR MAY retain memory of discarded Resv state for a short period to prevent refresh messages from causing subsequent error messages. 3.3.2 Egress LSR An egress LSR that receives a ResvErr message carrying the "Policy Control failure"/"Hard Pre-empted" error, MUST: - surrender all resources for the LSP - immediately stop forwarding data on the LSP - discard all Path and Resv state for the LSP. An egress LSR MUST NOT send further messages for the pre-empted LSP. Farrel Page 4 draft-farrel-mpls-preemption-01.txt April 2004 4. Soft Pre-emption Procedures 4.1 Pre-empting LSR When an LSR determines that it is pre-empting an LSP and that it will apply soft pre-emption it MUST: - surrender all resources for the old LSP - send a PathErr upstream for the old LSP carrying the "Policy Control failure"/"Soft Pre-empted" error - send a ResvErr downstream for the old LSP carrying the "Policy Control failure"/"Soft Pre-empted" error and with the inPlace flag set - retain full Path and Resv state for the old LSP - continue to send and process refresh messages for the old LSP - continue to forward data on the old LSP. A pre-empting LSR MAY modify the service delivered on the old LSP according to the reduced resources. This MAY result in traffic being treated as "best effort" and not delivered. A pre-empting LSR MAY use the receipt of a Path refresh message as a trigger to attempt to re-allocate the required resources, but it MUST NOT send a subsequent PathErr message if this attempt fails. A pre-empting LSR SHOULD use the receipt of a modified (i.e. trigger) Path message to attempt to re-allocate the required resources. If such an attempt is not successful, it SHOULD return a PathErr with the appropriate error according to the failure (probably Admission Control Failure) and continue to retain the LSP and the signaling state. 4.2 Upstream LSRs 4.2.1 Transit LSRs An upstream transit LSR that receives a PathErr message carrying the "Policy Control failure"/"Soft Pre-empted" error, MUST: - retain all resources allocated to the LSP - send a PathErr further upstream carrying the "Policy Control failure"/"Soft Pre-empted" error - retain full Path and Resv state for the old LSP - continue to send and process refresh messages for the old LSP - continue to forward data on the old LSP. An LSR MAY retain knowledge of the fact that the LSP has been pre- empted to help in future choices of LSPs that are pre-empted at this LSR. 4.2.2 Ingress LSR An ingress LSR that receives a PathErr message carrying the "Policy Control failure"/"Soft Pre-empted" error, MUST: - retain all resources allocated to the LSP - retain full Path and Resv state for the old LSP - continue to send and process refresh messages for the old LSP - continue to forward data on the old LSP. Farrel Page 5 draft-farrel-mpls-preemption-01.txt April 2004 An ingress LSR SHOULD take action according to local policy to attempt to repair or re-route the LSP (by chaning its priority, resource requirements or path), or tear the LSP by sending a PathTear message. 4.3 Dowstream LSRs 4.3.1 Transit LSRs A downstream transit LSR that receives a ResvErr message carrying the "Policy Control failure"/"Soft Pre-empted" error, MUST: - retain all resources allocated to the LSP - send a ResvErr further downstream carrying the "Policy Control failure"/"Soft Pre-empted" error and with the inPlace flag set - retain full Path and Resv state for the old LSP - continue to send and process refresh messages for the old LSP - continue to forward data on the old LSP. An LSR MAY retain knowledge of the fact that the LSP has been pre- empted to help in future choices of LSPs that are pre-empted at this LSR. 4.3.2 Egress LSR An egress LSR that receives a ResvErr message carrying the "Policy Control failure"/"Soft Pre-empted" error, MUST: - retain all resources allocated to the LSP - retain full Path and Resv state for the old LSP - continue to send and process refresh messages for the old LSP - continue to forward data from the old LSP. An egress LSR SHOULD NOT send any further messages for the pre-empted LSP as a specific result of receiving the ResvErr. In particular, it SHOULD NOT trigger a ResvTear or PathErr message. 5. Conversion Between Soft and Hard Pre-emption A transit LSR MUST NOT attempt to convert from hard to soft pre- emption while forwarding an error message. The rules described in the previous sections MUST be followed and will prevent this operation. A transit or egress LSR MAY convert from soft to hard pre-emption. Such an LSR MAY (under local policy control) determine that a soft pre-emption event is a trigger for hard pre-emption. In this case, LSR act as though it is the pre-empting LSR (which, in fact it is) and starts the procedures for hard pre-emption. An ingress LSR MUST not convert from soft to hard pre-emption. It should send a PathTear if that is what it wishes to achieve. 6. Control of Pre-emption Type It is possible that an ingress LSR will want to control the way in which a particular LSP is pre-empted if it is displaced by another LSP within the network. That is, as a function of the service, the ingress may want to specify that the LSP must only be soft or hard pre-empted. Farrel Page 6 draft-farrel-mpls-preemption-01.txt April 2004 Similarly (although less likely) an ingress LSR may wish to specify how a new LSP should pre-empt any other LSPs that it needs to displace. If such features are required they should be added using new fields in the LSP Attributes TLV of the LSP_ATTRIBUTES or LSP_REQUIRED_ ATTRIBUTES objects of the Path message [ATTRIB]. 7. Unchanged Processing 7.1 RSVP-TE This document in no way changes the processing for any other situation in RSVP-TE. 7.1.1 PathErr with "Policy Control failure" This document does not change the behavior of LSRs receiving PathErr messages carrying the "Policy Control failure" Error Code with Error Values other than the two specified in this document. This leaves exsting implementations free to continue the pre-emption behavior that they already have. 7.1.2 Other PathErr Processing The procedures in this document applies only to PathErr messages that carry the "Policy Control failure"/"Hard Pre-empted" or the "Policy Control failure"/"Soft Pre-empted" error. No change in processing is intended or applied for PathErr messages carrying any other combination of Error Code and Error Value in any other circumstances. In particular, the following text from [RFC2205] is assumed to apply in all cases except for pre-emption. There are two RSVP error messages, ResvErr and PathErr. PathErr messages are very simple; they are simply sent upstream to the sender that created the error, and they do not change path state in the nodes though which they pass. 8. GMPLS RSVP-TE is extended for use in GMPLS by [RFC3473]. [RFC3473] inherits the pre-emption procedures as described in [RFC3209] and [RFC2205] without further modification. The procedures in sections 3, 4 and 5 of this document are intended to clarify and supersede the pre-emption procedures for GMPLS. The following sections explain how hard and soft pre-emption procedures SHOULD be applied in GMPLS. 8.1 Path State Removal [RFC3473] introduces the Path_State_Removed flag to be carried on the PathErr message to indicate that the LSP to which the PathErr message applies has had its state removed by the sender. All upstream LSRs receiving this flag MUST also remove their Path state. Farrel Page 7 draft-farrel-mpls-preemption-01.txt April 2004 The meaning and use of the Path_State_Removed flag is not changed by this document. During soft pre-emption, the Path_State_Removed flag MUST not be set. During hard pre-emption, the Path_State_Removed flag MAY be set. Note however, that if the Path_State_Removed flag is set by the pre- empting LSR, it SHOULD send PathTear downsteam in place of ResvErr. It is RECOMMENDED that the Path_State_Removed flag be set during hard pre-emption. 8.2 Issues with Pre-emption in GMPLS 8.2.1 Packet-Switching and Non-Packet-Switching Pre-emption GMPLS extends MPLS for use in packet-switching (PSC) and non-packet- switching (non-PSC) environments. It must always be remembered that GMPLS is equally applicable to PSC environments. In non-PSC networks network resources are directly identified with GMPLS labels. For example, a lable may indicate a specific timeslot, wavelength or fiber. So, when a resource is pre-empted, the labels is re-used by the pre-empting LSP. This is different from PSC networks (in MPLS or GMPLS) where a distinct label may be used for the new LSP even though the old resources are re-used. 8.2.2 Issues with Label Suggestion in GMPLS Suggested Label is used in GMPLS systems to allow an upstream LSR to make a strong suggestion about which label the downstream LSR should allocate for traffic flowing from the upstream to downstream LSR. This feature allows the upstream LSR to "pipeline" the programming of its cross-connects which may be particularly useful in some optical systems where such programming may take a relatively lare amount of time compared with the desired setup time of the LSP. The downstream LSR that receives a Path message carrying a Suggested Label Object is permitted to refuse the selection and prefer a different label. This would happen, for example, if the label was already in use, or was not suitable for some other reason (such as limited label conversion capabilities at the downstream LSR). A Label Set may be used to impose absolute control on the choice of label by the downstream LSR. A Label Set with just one member (which clearly should not differ from the Suggested Label if one is present) allows the upstream LSR to specify the label that the downstream LSR must use. In such a case the choices for the downstream LSR are restricted to use of the speified label or rejection of the LSP. In the case of pre-emption, the upstream LSR chooses which resources to pre-empt and therefore which label the downstream LSR will re-use. It MUST signal that label in a Label Set Object with only one member on the Path message for the new LSP, and MAY also use a Suggested Label Object. The upstream LSR SHOULD issue the pre-emption messages (PathErr, ResvErr or PathTear) before forwarding the Path message for the new Farrel Page 8 draft-farrel-mpls-preemption-01.txt April 2004 LSP. This allows a reasonable chance that the downstream LSR will have already freed the pre-empted resources before processing the Path for the new LSP. However, there remains the possibility that the new Path message will be received before the resources have been freed; in this case the downstream LSR is required to perform pre- emption on its upstream interface as directed by the Label Set Object. Note that these requirement need not apply for a PSC LSP since a completely new label may be used (as in MPLS) and discretion for the choice of label may safely be left with the downstream LSR. 8.2.3 Issues with Bi-Directional LSPs in GMPLS GMPLS introduces bi-directional LSPs. Although these LSPs are primarily considered for TDM and optical LSPs, there is no limitation that denies their use for packet-based LSPs. The two-way Path/Resv exchange for LSP establishment means that the reverse direction data path must be established as the Path message traverses the network so that all resources and cross- connections are in place and operational at the time that the egress has completed processing the Path message. This requirement is achieved through the Upstream Label Object carried on the Path message to indicate the label that the upstream LSR requires the downstream LSR to use for data flowing in the reverse direction. Two problems arise with this mechanism in pre-emption. The first problem is exactly as described in the previous section. That is, if the new Path message is processed at the downstream LSR before it is fully aware of the pre-emption event, it will perceive that the resources are still in use and must also apply pre-emption. The second problem relates to the risk of misconnection. Since the new reverse direction data path is being installed as the new Path message transits the network, a fully functional LSP is already in place between the ingress and the pre-empting LSR - or rather, the LSP is between the pre-empting LSR and the ingress. Now, if the pre-empted resource on the LSR's downstream interface is immediately cross-connected into the new LSP a misconnection will be established since the downstream LSR is unaware of the pre-emption event and is still transmitting data for the old LSP on the pre-empted resource (that is, with the pre-empted label). There is, therefore, a double requirement to ensure that the downstream LSR is fully informed of the pre-emption event before the upstream LSR assigns the resource to the new LSP in the case where the Upstream Label Object is used to indicate the pre-empted resource. Note that this requirement need not apply for a bi- directional PSC LSP if the upstream LSR chooses an entirely new label for the reverse path. Farrel Page 9 draft-farrel-mpls-preemption-01.txt April 2004 8.2.4 Considerations for Alarm Suppression Optical systems may report alarms when they detect signal degradation or failure. In GMPLS this may result in alarms being raised unnecessarily during LSP establishment or teardown. To combat this problem, the Administrative Status Object carried on Path and Resv messages may be used to disable and enable alarm reporting on an LSP. The act of pre-empting an active LSP may cause alarms to be raised. Although this is often considered to be a desirable method of fault isolation and detection it may not be such a good idea during hard pre-emption, since the pre-empted LSP is completely torn down and alarm-based recovery action may be considered inappropriate. In this case the pre-empting LSR may choose to operate the alarm suppression techniques refered to above. During soft pre-emption, however, alarms may be considered desirable as they may trigger isolation of the pre-empting LSR and recovery of the pre-empted LSP faster than the propagation of the PathErr would do. In any case, it should be observed that there is a trade-off between rapid pre-emption and alarm-free pre-emption. 8.3 Notes on Hard and Soft Pre-emption in GMPLS Systems 8.3.1 Comments on Hard Pre-emption in GMPLS Systems As described earlier in this document, hard pre-emption means that the entire pre-empted LSP is torn down. Hard pre-emption is often considered the 'natural' behavior in optical systems. 8.3.2 Comments on Soft Pre-emption in GMPLS Systems As described earlier in this document, soft pre-emption means that the pre-empted LSP is not torn down. However, note that in all non-PSC systems where the label as well as the resources are pre-empted, the old LSP cannot continue to carry traffic through the pre-empting LSR. There is no concept of over- subscription of a labeled resource, and no way to carry the pre- empted traffic as best effort. Nevertheless, there is value in soft pre-emption in a non-PSC system since the LSP may be repaired more easily than it might be fully resignaled. In particular, if the pre-empted LSP is protected, it may be possible to continue to carry traffic with virtually no interruption - effectively, the pre-emption event is just a fault that is handled as any other link or node fault would be handled. Farrel Page 10 draft-farrel-mpls-preemption-01.txt April 2004 8.4 General Procedures for Pre-emption in GMPLS Systems 1. Choose which resources to pre-empt, remove them from use and break their cross-connects. Note that if the pre-empting LSP is bi-directional, these resources may come from one or two LSPs, and if from two LSPs they may be uni- or bi-directional. The pre- empting LSR SHOULD NOT pipeline this action by sending the new Path message before the deallocation of resources has completed since this might lead to the forward direction path becoming misconnected if the downstream LSR is able to re-assign the resources more quickly. 2a. If the pre-emption is hard, send PathTear for the pre-empted LSP(s). 2b. If the pre-emption is soft, send ResvErr with "Policy Control failure"/"Soft Pre-empted" for the pre-empted LSP(s). 3a. If the pre-emption is hard, send PathErr with "Policy Control failure"/"Hard Pre-empted" and the Path_State_Removed flag set for the pre-empted LSP(s). 3b. If the pre-emption is soft, send PathErr with "Policy Control failure"/"Soft Pre-empted" for the pre-empted LSP. The Path_ State_Removed flag MUST be clear. 4. Reserve the pre-empted resources for the new LSP, possibly cross- connect the forward resources according to local policy. The LSR MUST NOT cross-connect the reverse path resources of a bi- directional LSP. 5a. Build a Path message with Label Set with a single member indicating the pre-empted forward direction resources. A Suggested Label MAY also be used. 5b. If the pre-empting LSP is bi-direcitonal, include an Upstream Label Object. 5c. Send the Path message. 6. Receive a Resv from the downstream LSR. 7a. Cross-connect the forward path resources if not already done. 7b. If the pre-empting LSP is bi-direcitonal, cross-connect the reverse path resources. 7c. Continue as normal. Note that step 1 may cause alarms to be raised for the old LSP. If alarm supression is desired (see section 8.2.4) the pre-empting LSR MAY expand step 1 as follows. 1a. Choose which resource to pre-empt. 1b. Send a Resv message with Administrative Status Object to disable alarms for the pre-empted LSP. 1c. Receive a Path message indicating that alarms are disabled. 1d. Remove the pre-empted resource from use and break its cross- connect. Farrel Page 11 draft-farrel-mpls-preemption-01.txt April 2004 At the downstream LSR (with respect to the new LSP) the processing is RECOMMENDED to be as follows: A. Receive PathTear, ResvErr and/or PathErr for the old LSP(s). Bi. Release the resources associated with the LSP on the interface to the pre-empting LSP, and remove any cross-connects. Bii. If the pre-emption is hard, the LSR SHOULD release all other resources associated with the LSP and forward the PathTear (and/or PathErr). Biii. If the pre-emption is soft the LSR MUST NOT release the pre- empted LSP's resources on its downstream interface, but the LSR SHOULD forward the PathErr/ResvErr. Biv. LSPs further downstream MUST NOT release any resources associated with the pre-empted LSP. This means that those LSRs MUST examine the Error Node Address in the Error Spec Object of the ResvErr/PathErr message to determine whether they are immediately downstream of the pre-empting LSR. C. Receive the Path message for the new LSP and process as normal. D. Receive the Resv for the new LSP and process as normal, forwarding it to the upstream LSR. Note that there is some risk that step C will occur before step B has completed. It is RECOMMENDED that: - The pre-empting LSP not perform step 5 until the Message ID Ack has been received for the PathTear, ResvErr or PathErr sent in steps 2 and 3. - The downstream LSR perform pre-emption on its upstream interface according to the single element in the Label Set of the received Path message if the indicated label is not already free (and assuming that the LSR is pre-emption capable and the priorities of the associated LSPs support the pre-emption). Similar pre-emption should be performed in the case of a bi-directional pre-empting LSP using the label in the Upstream Label Object. The downstream LSR MAY also choose to suspend the processing of a received Path message with a single element in the Label Set Object and/or an Upstream Label Object if that label is known to be in the process of being released. 8.5 Asymmetric Pre-emption in GMPLS Note that pre-emption in GMPLS for a new bi-directional LSP MAY be asymmetric. That is, pre-emption may only be required in one direction, or may cause the pre-emption of different LSPs in each directions. Similarly, a new unidirectional LSP may cause the pre-emption of resources in only one direction of a bidirectional LSP. Further, a new LSP may pre-empt an LSP that was orriginally set up in the oposite direction. Whenever resources for only one direction of a bi-directional LSP are pre-empted, the pre-empting LSR MUST pre-empt the entire LSP. It is RECOMMENDED that an LSR choosing which LSPs to pre-empt should consider reducing the number of pre-empted LSPs as one of the factors that govern its choice. Farrel Page 12 draft-farrel-mpls-preemption-01.txt April 2004 9. IANA Considerations This document introduces two new Error Values for the Error Code "Policy control failure". They may be used on PathErr and ResvErr messages. Error Value Meaning TBD Hard Pre-emption TBD Soft Pre-emption The values are to be assigned by IANA. It is strongly suggested that values in excess of 32 be used and that a value of zero definitely NOT be used. 10. Security Considerations Neither interpretation of pre-emption changes the fundamentals of security as expressed in [RFC3209] and [RFC3473]. Note, however that there are some risks of misconnection described in section 8 for bi-directional non-packet-switching LSPs in GMPLS. Such misconnections would potentially compromise private data nad the procedures identified SHOULD be followed to avoid this risk. 11. Acknowledgements I would like to thank Loa Andersson for encouraging me to write this document, and John Drake for his careful review. Dimitri Papadimitriou provided valuable discussion. 12. Intellectual Property Consideration 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. Farrel Page 13 draft-farrel-mpls-preemption-01.txt April 2004 12.1 IPR Disclosure Acknowledgement By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 13. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReserVation Protocol -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling - RSVP-TE Extensions", RFC 3473 January 2003. [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004. [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. [ATTRIB] Farrel, A. (Editor), "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE", draft-ietf-mpls-rsvpte-attributes-03.txt, March 2004, work in progress. 14. Informative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. [RFC2750] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000. 15. Authors' Address Adrian Farrel Old Dog Consulting Phone: +44 (0) 1978 860944 EMail: adrian@olddog.co.uk 16. Full Copyright Statement Copyright (C) The Internet Society (2004). 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. Farrel Page 14 draft-farrel-mpls-preemption-01.txt April 2004 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. Farrel Page 15