Internet DRAFT - draft-farrel-mpls-preemption

draft-farrel-mpls-preemption




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