Supported Platforms
Improving Traffic Engineering Database Accuracy with RSVP PathErr Messages
An essential element of RSVP-based traffic engineering is the traffic engineering database. The traffic engineering database contains a complete list of all network nodes and links participating in traffic engineering, and a set of attributes each of those links can hold. (For more information about the traffic engineering database, see Constrained-Path LSP Computation.) One of the most important link attributes is bandwidth.
Bandwidth availability on links changes quickly as RSVP LSPs are established and terminated. It is likely that the traffic engineering database will develop inconsistencies relative to the real network. These inconsistencies cannot be fixed by increasing the rate of IGP updates.
Link availability can share the same inconsistency problem. A link that becomes unavailable can break all existing RSVP LSPs. However, its unavailability might not readily be known by the network.
When you configure the rsvp-error-hold-time statement, a source node (ingress of an RSVP LSP) learns from the failures of its LSP by monitoring PathErr messages transmitted from downstream nodes. Information from the PathErr messages is incorporated into subsequent LSP computations, which can improve the accuracy and speed of LSP setup. Some PathErr messages are also used to update traffic engineering database bandwidth information, reducing inconsistencies between the traffic engineering database and the network.
You can control the frequency of IGP updates by using the update-threshold statement. See Configuring RSVP Interfaces.
This section discusses the following topics:
PathErr Messages
PathErr messages report a wide variety of problems by means of different code and subcode numbers. You can find a complete list of these PathErr messages in RFC 2205, Resource Reservation Protocol (RSVP), Version 1, Functional Specification and RFC 3209, RSVP-TE: Extensions to RSVP for LSP Tunnels.
When you configure the rsvp-error-hold-time statement, two categories of PathErr messages, which specifically represent link failures, are examined:
- Link bandwidth is low for this LSP: Requested bandwidth
unavailable—code 1, subcode 2
This type of PathErr message represents a global problem that affects all LSPs transiting the link. They indicate that the actual link bandwidth is lower than that required by the LSP, and that it is likely that the bandwidth information in the traffic engineering database is an overestimate.
When this type of error is received, the available link bandwidth is reduced in the local traffic engineering database, affecting all future LSP computations.
- Link unavailable for this LSP:
- Admission Control failure—code 1, any subcode except 2
- Policy Control failures—code 2
- Service Preempted—code 12
- Routing problem—no route available toward destination—code 24, subcode 5
These types of PathErr messages are generally pertinent to the specified LSP. The failure of this LSP does not necessarily imply that other LSPs could also fail. These errors can indicate maximum transfer unit (MTU) problems, service preemption (either manually initiated by the operator or by another LSP with a higher priority), that a next-hop link is down, that a next-hop neighbor is down, or service rejection because of policy considerations. It is best to route this particular LSP away from the link.
Identifying the Problem Link
Each PathErr message includes the sender’s IP address. This information is propagated unchanged toward the ingress router. A lookup in the traffic engineering database can identify the node that originated the PathErr message.
Each PathErr message carries enough information to identify the RSVP session that triggered the message. If this is a transit router, it simply forwards the message. If this router is the ingress router (for this RSVP session), it has the complete list of all nodes and links the session should traverse. Coupled with the originating node information, the link can be uniquely identified.
Configuring the Router to Improve Traffic Engineering Database Accuracy
To improve the accuracy of the traffic engineering database, configure the rsvp-error-hold-time statement. When this statement is configured, a source node (ingress of an RSVP LSP) learns from the failures of its LSP by monitoring PathErr messages transmitted from downstream nodes. Information from the PathErr messages is incorporated into subsequent LSP computations, which can improve the accuracy and speed of LSP setup. Some PathErr messages also are used to update traffic engineering database bandwidth information, reducing inconsistencies between the traffic engineering database and the network.
To configure how long MPLS should remember RSVP PathErr messages and consider them in CSPF computation, include the rsvp-error-hold-time statement:
You can include this statement at the following hierarchy levels:
- [edit protocols mpls]
- [edit logical-systems logical-system-name protocols mpls]
The time can be a value from 1 to 240 seconds. The default is 25 seconds. Configuring a value of 0 disables the monitoring of PathErr messages.
