One document matched: draft-farrel-mpls-preemption-01.txt
Differences from draft-farrel-mpls-preemption-00.txt
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
| PAFTECH AB 2003-2026 | 2026-04-23 09:07:06 |