One document matched: draft-farrel-mpls-preemption-interim-00.txt
Network Working Group Adrian Farrel
Internet Draft Old Dog Consulting
Category: Informational
Expires: May 2004
November 2003
Interim Report on MPLS Pre-emption
draft-farrel-mpls-preemption-interim-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
This document is an interim report into pre-emption in MPLS systems.
At the 58th IETF, the MPLS Working Group determined that there are
several interpretations of how pre-emption should be achieved within
MPLS systems. This document is the result of the initial enquiries to
vendors and other implementors into the question of how and why they
offer pre-emption funtion in their MPLS inplementations.
This document is intended to be a short-lived document and only
exists to document the current findings. It will be superceded or
retired.
Farrel Page 1
draft-farrel-mpls-preemption-interim-00.txt November 2003
1. Introduction
The most recent charter of the MPLS working group includes the work
item to develop a solution for "soft pre-emption" within MPLS
systems. This work item was contested by some people who regard MPLS
signaling (and in particular RSVP-TE as documented by [RFC 3209]) to
already include mechanisms for soft pre-emption.
A common understanding of the correct behavior during pre-emption
will be beneficial to vendors trying to get their hardware to inter-
work, and to network operators trying to offer services in networks
built from equipment from more than one vendor.
Without commenting on the correct interpretation of pre-existing
documents, this document aims to establish the following.
- Behavioral characteristics of Admission Control in MPLS and GMPLS
systems.
- Desired characteristics of pre-emption.
- A terminology for soft and hard pre-emption.
- A record of implemented pre-emption behavior.
If necessary, a subsequent document will describe the conclusions of
the MPLS working group with regard to the correct interpretation of
the procedures for pre-emption.
2. Background
2.1 Default PathErr Processing
[RFC2205] defines RSVP procedures including the procedures for
handling PathErr messages that are used to report events or errors
from a downstream node to an upstream node. The predominant use of
PathErr in [RFC2205] is to report a problem that occurs while an RSVP
path is being established. There is no specific text that refers to
the use of a PathErr once a path has been established, but [RFC2205]
does include the following text.
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.
2.2 The Origins of Priority in RSVP
[RFC2751] introduces the concept of priority to RSVP and suggests how
it may be signaled using the Policy Data object.
Priority can be used in this context to modify the traditional first-
come first-served Capacity-based Admissions Control (CAC) into a
Priority-based Admisssions Control (PAC).
[RFC2751] concentrates mainly on PAC and says very little about the
operation of pre-emption. The following text is relevant.
When a previously admitted flow is preempted, a copy of the
preempting flow's PREEMPTION_PRI element is sent back toward the
PDP that originated the preempted PREEMPTION_PRI object. This PDP,
Farrel Page 1
draft-farrel-mpls-preemption-interim-00.txt November 2003
having information on both the preempting and the preempted
priorities may construct a higher priority PREEMPTION_PRI element
in an effort to re-instate the preempted flow.
However, [RFC2750] describes the processing of policy errors as
follows.
Policy errors are reported by either ResvErr or PathErr messages
with a policy failure error code in the ERROR_SPEC object.
2.3 Priority and Pre-emption in MPLS
[RFC3209] defines RSVP-TE and introduces the concept of setup and
holding priorities for LSPs. This enables the implementation of
PAC in MPLS systems, and facilitates pre-emption of a lower priority
LSP by a higher priority LSP.
Pre-emption in this case means that some or all of the system
resources previously reserved for the lower priority LSP are assigned
to the higher priority LSP.
[RFC3209] contains the following text.
When a new Path message is considered for admission, the bandwidth
requested is compared with the bandwidth available at the priority
specified in the Setup Priority.
If the requested bandwidth is not available a PathErr message is
returned with an Error Code of 01, Admission Control Failure, and
an Error Value of 0x0002. The first 0 in the Error Value
indicates a globally defined subcode and is not informational.
The 002 indicates "requested bandwidth unavailable".
If the requested bandwidth is less than the unused bandwidth then
processing is complete. If the requested bandwidth is available,
but is in use by lower priority sessions, then lower priority
sessions (beginning with the lowest priority) MAY be preempted to
free the necessary bandwidth.
When preemption is supported, each preempted reservation triggers
a TC_Preempt() upcall to local clients, passing a subcode that
indicates the reason. A ResvErr and/or PathErr with the code
"Policy Control failure" SHOULD be sent toward the downstream
receivers and upstream senders.
3. Ambiguity
Confusion and diverse implementations have arrisen owing to the lack
of definitive instructions for error handling within [RFC3209]. The
diversity of implementations has been driven both by assumed
interpretations of [RFC3209] and by the needs of specific Admission
Control implementations.
Farrel Page 1
draft-farrel-mpls-preemption-interim-00.txt November 2003
4. Admission Control
The implementation of Admission Control turns out to be a major
factor in the decision about how to implement pre-emption within an
MPLS system.
4.1 Capacity-based Admission Control (CAC)
CAC operates by allocating system resources to flows (for example,
LSPs) as a function of the bandwidth requested during signaling and
the capacity of the links or router that supports the flow. Each
router is responsible for managing its own resources.
When a request for more bandwidth than can be supported by the links
of router is receieved, the CAC request fails and a signaling error
is returned. The CAC request may fail because the requested resources
exceed the total available in the system. The request may also fail
if some resources have already been reserved for other flows meaning
that the requested resources exceed the currently avilable resources
on the links or router.
4.2 Policy-based Admission Control (PAC)
PAC is a modification of CAC that allows the available resources to
be subdivided by priority. This means that some of the resources can
be reserved for use only by higher priority flows. High priority
flows can use high and low priority resources, but low priority flows
can use only low priority resources.
4.3 Pre-emption
PAC facilitates pre-emption. A resource request for a high priority
flow may pre-empt a low priority flow, and commandeer its resources.
The low priority flow is usually notified through signaling.
4.4 Best-Effort Traffic
Best-effort traffic does not have any resources specifically reserved
for it. It is sent on the understanding that if there is no capacity
at some point in the network it will be discarded. If, however, there
are resources that are available either because they have not been
reserved or because the flow for which they were reserved is not
using them, then the best-effort traffic may get through.
4.5 Statistical Admissions Control
Some implementations of Admissions Control are statistical. This
means that CAC requests are managed against a count of available
resources. When a CAC request is successful the count of available
resources is decremented.
PAC may also be managed in a statistical model.
In a statistical Admissions Control implementation no resources are
specifically assigned to each flow, and there is no attempt to police
the flows at transit routers. It is a requirement of successful
operation that the edge nodes adhere to the implicit contract of
Farrel Page 1
draft-farrel-mpls-preemption-interim-00.txt November 2003
their resource requests. Policing is sometimes applied at the network
edges or through management applications.
A consequence of this is that if one flow exceeds its contract, other
flows will suffer.
It is hard to support best-effort traffic in a statistical CAC
system.
4.6 Per-flow Admission Control
Per-flow Admission Control operates as CAC or PAC, and explicitly
assigns resources for the use by the flow. This means that a flow
that stays within its contracted limits is guaranteed resources to
meet its contract regardless of the behavior of the other flows in
the system.
A flow that exceeds its contracted limits may see its excess traffic
discarded. However, if there are unused or unallocated resources in
the system, the excess traffic may use these.
Similarly, best-effort traffic can be supported in this Admission
Control model since it is clear that that traffic should only be
allowed when there are spare resources.
5. Pre-emption Models
There are two pre-emption models applicable to MPLS systems.
5.1 Soft Pre-emption
In soft pre-emption, a higher priority LSP commandeers the resources
previously assigned to a lower priority LSP. The lower priority LSP
is not torn down and can continue to forward traffic on a best-effort
basis.
Note that resource reservations on other LSRs are not changed, and
the degradation to best-effort happens only at the point of pre-
emption.
A notification is normally sent to upstream and downstream LSRs to
warn them that the expected levels of service have been disrupted at
one LSR along the LSP. This allows end-to-end or local repair to be
performed to re-instate the desired level of service.
5.2 Hard Pre-emption
In hard pre-emption, a higher priority LSP commandeers the resources
previously assigned to a lower priority LSP, and the lower priority
LSP is torn down at the point of pre-emption. That is, the labels are
released and the entry is removed from the LFIB. Any traffic that
arrives with the old label is black-holed.
A notification message is sent to upstream and downstream LSRs to
inform them of this event and, if the notified LSR is unable or
unwilling to perform local repair, it may also tear the LSP by
releasing resources and labels and forwarding the notification.
Farrel Page 1
draft-farrel-mpls-preemption-interim-00.txt November 2003
5.3 Head-end Teardown
Note that an ingress LSR that is informed of soft pre-emption may
respond by explicitly tearing down the pre-empted LSP. Although this
results in the release of labels and disruption of data traffic, it
is not counted as hard pre-emption. The distinction between soft and
hard pre-emption is made only at the LSR where the pre-emption
occurs, and only at the time of pre-emption.
5.4 Applicability of Pre-emption Models
It will be observed that since the soft pre-emption model degrades
the pre-empted LSP to best-effort, it is not well-suited to
statistical Admission Control. In this mode hard pre-emption is
more applicable.
Soft pre-emption can be used in per-flow admission control.
5.5 Methods of Notification
In the current confusion about the correct method of performing
pre-emption both soft and hard pre-emption implemtations use a
PathErr and ResvErr message containing the "Policy Control failure"
error code to notify upstream and downstream LSRs of the pre-emption
event.
There is no way to distinguish from the received message
whether the pre-emption point performed soft or hard pre-emption.
5.6 Interworking of Pre-emption Models
The two pre-emption models do not interwork satisfactorily with the
current usage of the same messages and error codes.
5.6.1 Hard Pre-emption in a Soft Pre-emption Network
Consider a pre-emption point that applies hard pre-emption in a
network of LSRs that assume soft pre-emption. The other LSRs will
assume that the LSP is up and will continue to send traffic which
will be black-holed.
The Path refresh from the LSR immediately upstream of the pre-empting
LSR will be rejected with an error of "Admission Control failure"
because it will be seen as a new LSP setup request. This error might
trigger the tear-dwon of the LSP or might simply be propagated to the
ingress.
The pre-empting LSR will cease to send Resv refreshes so the LSP will
eventually timeout from the upstream LSRs.
Similarly, the downstream LSRs will not receive Path refreshes and
may receive a ResvErr or ResvTear in response to its Resv refresh.
In this case there is heavy reliance on the ingress LSP deciding
that best-effort is not good enough. It must either re-route or
tear the LSP.
Farrel Page 1
draft-farrel-mpls-preemption-interim-00.txt November 2003
5.6.2 Soft Pre-emption in a Hard Pre-emption Network
If the pre-emption point performs soft pre-emption and signals this
event upstream and downstream to the remainder of the network, and if
the remainder of the network assumes that hard pre-emption has been
performed then the worst that happens is that labels are wasted at
the pre-emption point.
Upstream of the pre-emption point, the notification of pre-emption
causes the release of state, rsources and labels. This means that no
more traffic will be passed to the pre-emption point on the pre-
empted LSP. Also, no Path refresh will be sent, and the Resv refresh
received from the pre-emption point may be rejected with a ResvErr or
ResvTear. In time, the pre-emption point will time-out the LSP and
release the labels.
Downstream of the pre-emption point, the Path refresh from the pre-
emption point may cause the LSP to be re-established. This partial
LSP will never carry traffic and will be removed when the pre-emption
point times-out the LSP as described above.
6. Tying Resources to Labels
An LSP is defined by the existence of entries in the Label Forwarding
Information Base (LFIB) at each LSR along the LSP. These entries map
{incoming interface, incoming label} to {outgoing interface, outgoing
label}.
6.1 Packet-Based Networks
An LSP may exist with or without reserved resources at each or any
LSR along its path. An LSP with no resources reserved at any point is
described as 'best effort'. An LSP with no resources reserved at a
particular LSR or on a particular link is best effort through that
LSR or on that link.
In an MPLS network, a distinction should be drawn between the pre-
emption of resources (such as buffers) and the pre-emption of labels.
It is not a requirement that the release of resources forces a
release of label. The LSP may survive pre-emption with its resources
removed (best effort) or reduced (degraded).
Packet LSRs that are incapable or unwilling to offer best effort
LSPs, MAY choose to offer only hard pre-emption. This might arise
where admission control is purely an arithmetic accounting function,
and edge nodes are required to police flows.
Where soft pre-emption is appplied, it is usual to only release
resources at the LSRs where pre-emption occurs. That is, the
resources are left assigned to the LSP at all other LSRs.
Farrel Page 1
draft-farrel-mpls-preemption-interim-00.txt November 2003
6.2 Non-Packet Networks
For non-packet switching types (such as lambda switching) there is a
hard binding between resources and labels. In these cases, it is not
possible to pre-empt resources without releasing the label.
Hard pre-emption is usually applied in non-packet networks.
6.3 Separating Signaling State from LSP State
Some implementations may choose to retain signaling state for an LSP
even when the labels have been released during hard pre-emption.
This may be particualrly useful in optical networks where resources
are manually deprovisioned and reprovisioned.
7. Methods of Signaling Pre-emption
The poll of vendors and implementors has shown that several methods
for signaling pre-emption events have been implemented or considered
for implementation. These are presented below without comment upon
their efficacy or properness.
7.1 PathErr and ResvErr with Policy Control Failure Error Code
As described in [RFC3209] the pre-emption point sends a PathErr
upstream and a ResvErr downstream. The messages carry the "Policy
Control failure" error code.
This mechanism is used in both hard and soft pre-emption
implementations. In some implementations the ingress automatically
responds to the PathErr with a PathTear.
7.2 PathErr with State Removal
Using the mechanism described in [RFC3473] a PathErr is sent upstream
carrying the "Policy Control failure" error code and with the
Path_State_Removed flag set. At the same time, a PathTear is sent
downstream.
This mechanism is used in hard pre-emption implementations.
7.3 ResvTear and ResvErr
A ResvTear is sent upstream and a ResvErr carrying the "Policy
Control failure" error code is sent downstream. The ingress
automatically responds to the ResvTear with a PathTear.
This mechanism has been suggested for use in hard pre-emption
implementations.
Farrel Page 1
draft-farrel-mpls-preemption-interim-00.txt November 2003
7.4 Notify Message
The Notify message introduced in [RFC3473] is sent upstream and
downstream carrying the "Policy Control failure" error code. The
Admin_Status object is included with the D-bit set to indicate that
LSP teardown is required.
This mechanism has been suggested for use in hard pre-emption
implementations.
7.5 Resv Message with Record Route Object
A Resv message is sent upstream with a flag in the RRO subobject
conveying the information about pre-emption for a specific hop.
This mechanism is introduced in [SOFT-PREEMPT] to provide a way to
perform soft pre-emption in systems that use the technique described
in section 7.1 to perform hard pre-emption.
8. Error Codes and State Removal
The Addmission Control error code in [RFC2205] is defined as carrying
an Error Value of the form ssur cccc cccc cccc where it is mandated
that u = 1 to denote
u = 1: RSVP may use message to update local state and forward
the message. This means that the message is informational.
Note that a ResvErr may carry the InPlace flag in the ERROR_SPEC
object to indicate that the resources are still in place. This
is of no particular help during pre-emption.
GMPLS [RFC3473] introduced the Path_State_Removed flag for inclusion
in PathErr messages to indicate to an upstrem LSR that the downstream
LSR has completely removed the Path state for the LSP. The
implication being that the resources have been freed, the labels
released, and the LSP torn down.
9. A Side Note on PathErr Processing
One other factor should be brought into consideration: How is a
PathErr message handled when it is received for an established LSP
and the PathErr carries an error code other than "Policy Control
failure"?
10. Other Requirements
Two other notes on the requirements of pre-emption can be made.
10.1 Reducing the Impact of Pre-emption
Where the establishment of one LSP requires pre-emption of resources
at multiple LSRs, it is desireable that the same LSP be pre-empted
at each intermediate LSR when possible and subject to the local
policy.
Farrel Page 1
draft-farrel-mpls-preemption-interim-00.txt November 2003
Where the establishment of two or more further LSPs requires
pre-emption at different points in the network, it is desireable
that the same LSP be pre-empted in each case where possible
and subject to the local policy.
The coordination of LSPs for pre-emption is a matter for individual
implementations. The protocol messages used to indicate pre-emption
must make it possible for each LSR to gather sufficient information
to perform this function.
10.2 When To Apply Pre-emption
It is normal to apply pre-emption on the reverse leg of LSP setup
when processing Resv. However, when processing a Path message:
- The likely need for and possibility of pre-emption may be taken
into account during path computation and routing.
- Pre-emption may be applied on the forward leg of LSP setup so
that, if it is known that pre-emption will be required (if the LSP
sets up successfully), pre-emption can be performed ahead of time.
- In bidirectional LSPs (see [RFC3473]), and in particular when the
resource is bound to the label, it may be necessary to allocate
resources for the upstream data flow while processing the Path
message during LSP setup. This may require that pre-emption is
performed when processing the Path message.
11. Summary of Deployed Solutions
Appendix A lists some of the deployed solutions according to an
informal survey of implementors and vendors. This information was
garnered from a private email survey conducted by the co-chairs of
the CCAMP working group.
11.1 Soft Pre-emption
There is only one deployed solution for soft pre-emption.
- A PathErr with the code "Policy Control failure" is sent
upstream, and a ResvErr with the code "Policy Control
failure" is sent downstream.
There is a further solution for soft pre-emption under development.
- A Resv message MAY be sent upstream with a flag in RRO subobject
conveying the information about pre-emption for a specific hop.
11.2 Hard Pre-emption
There are two deployed solutions for hard pre-emption.
- A PathErr with the code "Policy Control failure" is sent upstream,
and a ResvErr with the code "Policy Control failure" is sent
downstream.
Farrel Page 1
draft-farrel-mpls-preemption-interim-00.txt November 2003
- A PathErr with the code "Policy Control failure" and the
Path_State_Removed flag (see [RFC3473]) set is sent upstream. At
the same time, a PathTear is sent downstream.
12. Security Considerations
This is an informational document that introduces no new protocols
nor protocol extensions. There are no security implications of this
document.
The attention of implementors is drawn to the security sections of
the documents describing the pre-emption signaling features that they
are implementing.
13. Acknowledgements
Thanks to Dimitri Papadimitriou, JP Vasseur, Arthi Ayyangar and
Kireeti Kompella for a detailed discussion and exposee of the
problems.
14. 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.
15. 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.
[RFC2750] Herzog, S., "RSVP Extensions for Policy Control",
RFC 2750, January 2000.
Farrel Page 1
draft-farrel-mpls-preemption-interim-00.txt November 2003
[RFC2751] Herzog, S., "Signaled Preemption Priority Policy
Element", RFC 2751, January 2000.
[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.
[RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description",
RFC 3471, January 2003.
[RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling -
RSVP-TE Extensions", RFC 3473 January 2003.
16. Informative References
[RFC2026] Bradner, S., "The Internet Standards Process
-- Revision 3", RFC 2026, October 1996.
[RFC3031] Rosen, E., Viswanathan, A., and Callon, R.,
"Multiprotocol Label Switching
Architecture", RFC 3031, January 2001.
[SOFTPREEMPT] Meyer, Maddux, Vasseur, Villamizar and Birjandi,
"MPLS Traffic Engineering Soft preemption",
draft-ietf-mpls-soft-preemption-01.txt, October 2003,
work in progress.
17. Authors' Addresses
Adrian Farrel
Old Dog Consulting
Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk
18. Full Copyright Statement
Copyright (C) The Internet Society (2003). 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
Farrel Page 1
draft-farrel-mpls-preemption-interim-00.txt November 2003
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.
Apendix A Implementation Reports
A.1 Company 1
Hardware vendor.
A.1.1 Soft Pre-emption
A Resv message is sent upstream with a flag in the RRO subobject
conveying the information about pre-emption for a specific hop.
Not currently deployed. Implementation under development.
A.1.2 Hard Pre-emption
A PathErr with the code "Policy Control failure" is sent upstream,
and a ResvErr with the code "Policy Control failure" is sent
downstream.
Significantly large deployment.
A.1.3 Processing of Other PathErrs for Established LSPs
Unknown.
A.2 Company 2
Hardware vendor.
A.2.1 Soft Pre-emption
Not currently supported.
A.2.2 Hard Pre-emption
A PathErr with the code "Policy Control failure" is sent upstream,
and a ResvErr with the code "Policy Control failure" is sent
downstream.
Significantly deployment.
A.2.3 Processing of Other PathErrs for Established LSPs
Unknown.
Farrel Page 1
draft-farrel-mpls-preemption-interim-00.txt November 2003
A.3 Company 3
Hardware vendor.
A.3.1 Soft Pre-emption
A PathErr with the code "Policy Control failure" is sent upstream,
and a ResvErr with the code "Policy Control failure" is sent
downstream. The ingress always responds with PathTear.
Some deployment.
A.3.2 Hard Pre-emption
Not supported.
A.3.3 Processing of Other PathErrs for Established LSPs
PathErr is informational only. It does not disrupt the state of
existing LSPs.
A.4 Company 4
Software vendor.
A.4.1 Soft Pre-emption
A PathErr with the code "Policy Control failure" is sent upstream,
and a ResvErr with the code "Policy Control failure" is sent
downstream.
Considerable deployment.
A.4.2 Hard Pre-emption
Not supported.
A.4.3 Processing of Other PathErrs for Established LSPs
PathErr is informational only. It does not disrupt the state of
existing LSPs.
A.5 Company 5
Hardware vendor.
A.5.1 Soft Pre-emption
A PathErr with the code "Policy Control failure" is sent upstream,
and a ResvErr with the code "Policy Control failure" is sent
downstream.
Some deployment.
Farrel Page 1
draft-farrel-mpls-preemption-interim-00.txt November 2003
A.5.2 Hard Pre-emption
A PathErr with the code "Policy Control failure" and the
Path_State_Removed flag (see [RFC3473]) set is sent upstream. At the
same time, a PathTear is sent downstream.
Some deployment.
A.5.3 Processing of Other PathErrs for Established LSPs
PathErr is informational only. it does not disrupt the state of
existing LSPs.
A.6 Company 6
Hardware vendor.
A.6.1 Soft Pre-emption
Not supported.
A.6.2 Hard Pre-emption
A PathErr with the code "Policy Control failure" is sent upstream,
and a ResvErr with the code "Policy Control failure" is sent
downstream. The ingress always responds with PathTear.
Under development.
A.6.3 Processing of Other PathErrs for Established LSPs
State is retained, but ingress always responds with PathTear.
A.7 Company 7
Software vendor.
A.7.1 Soft Pre-emption
A PathErr with the code "Policy Control failure" is sent upstream,
and a ResvErr with the code "Policy Control failure" is sent
downstream.
Significant deployment.
A.7.2 Hard Pre-emption
A PathErr with the code "Policy Control failure" and the
Path_State_Removed flag (see [RFC3473]) set is sent upstream. At the
same time, a PathTear is sent downstream.
A.7.3 Processing of Other PathErrs for Established LSPs
Depends on Path_State_Removed flag.
Farrel Page 1
draft-farrel-mpls-preemption-interim-00.txt November 2003
A.8 Company 8
Hardware vendor.
A.8.1 Soft Pre-emption
Not supported.
A.8.2 Hard Pre-emption
A PathErr with the code "Policy Control failure" is sent upstream,
and a ResvErr with the code "Policy Control failure" is sent
downstream.
Some deployment.
A.8.3 Processing of Other PathErrs for Established LSPs
The LSP is torn down.
A.9 Company 9
Hardware vendor.
A.9.1 Soft Pre-emption
Not supported.
A.9.2 Hard Pre-emption
A PathErr with the code "Policy Control failure" is sent upstream,
and a ResvErr with the code "Policy Control failure" is sent
downstream.
Some deployment.
A.9.3 Processing of Other PathErrs for Established LSPs
Unknown.
A.10 Company 10
Hardware vendor.
A.10.1 Soft Pre-emption
Not supported.
A.10.2 Hard Pre-emption
Not supported.
A.10.3 Processing of Other PathErrs for Established LSPs
The LSP is torn down.
Some deployment.
Farrel Page 1
| PAFTECH AB 2003-2026 | 2026-04-23 01:04:50 |