One document matched: 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: July 2004 January 2004
Multiprotocol Label Switching Pre-emption
draft-farrel-mpls-preemption-00.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-00.txt January 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-00.txt January 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-00.txt January 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-00.txt January 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-00.txt January 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. Unchanged Processing
6.1 RSVP-TE
This document in no way changes the processing for any other
situation in RSVP-TE.
Farrel Page 6
draft-farrel-mpls-preemption-00.txt January 2004
6.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.
6.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.
6.2 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 this document are intended to clarify and supersede
the pre-emption procedures for GMPLS.
6.2.1 Path State Removal
Note that [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.
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_Reomved flag is set by the pre-
empting LSR, it SHOULD send PathTear downsteam in place of ResvErr.
Farrel Page 7
draft-farrel-mpls-preemption-00.txt January 2004
7. 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.
8. Security Considerations
Neither interpretation of pre-emption changes the fundamentals of
security as expressed in [RFC3209].
9. Acknowledgements
I would like to thank Loa Andersson for encouraging me to write this
document.
10. Intellectual Property Consideration
The IETF takes no position regarding the validity or scope
of any intellectual property 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; neither does it represent that it has made any
effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track
and standards-related documentation can be found in BCP-11.
Copies of claims of rights made available for publication
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
implementors or users of this specification can be obtained
from the IETF Secretariat.
The IETF invites any interested party to bring to its
attention any copyrights, patents or patent applications, or
other proprietary rights which may cover technology that may
be required to practice this standard. Please address the
information to the IETF Executive Director.
11. 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.
Farrel Page 8
draft-farrel-mpls-preemption-00.txt January 2004
[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.
12. 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.
13. Authors' Addresses
Adrian Farrel
Old Dog Consulting
Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk
14. Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights
Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on
or otherwise explain it or assist in its implementation may
be prepared, copied, published and distributed, in whole or
in part, without restriction of any kind, provided that the
above copyright notice and this paragraph are included on
all such copies and derivative works. However, this
document itself may not be modified in any way, such as by
removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which
case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to
translate it into languages other than English.
The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its
successors or assigns. This document and the information
contained herein is provided on an "AS IS" basis and THE
INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
Farrel Page 9
| PAFTECH AB 2003-2026 | 2026-04-23 09:13:18 |