Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE
Extracted elements (27)
Crankback is not intended to supplement or replace TE flooding (OSPF/IS-IS); information gathered from crankback is used only to compute an alternate path for the specific LSP being signaled, not to influence path computations of other LSPs, keeping the mechanisms independent and avoiding the overhead of available-link-bandwidth flooding.
Explicit re-routing indications are used rather than implicit inference from error codes because implicit indication (e.g., via CV34 in TDM networks) can lead to futile re-routing attempts: a node re-routes without knowing where blockage occurred, and may route through the same congested point. Explicit crankback separately conveys where blockage occurred and whether alternate routing should be attempted.
This document does not introduce backward compatibility issues provided that existing implementations conform to the TLV processing rules defined in RFC 3471 and RFC 3473. LSRs not supporting these extensions can continue to process PathErr, ResvErr, or Notify messages carrying the newly defined IF_ID ERROR_SPEC TLVs.
All LSRs MUST be prepared to receive and forward any TLV as per RFC 3473, including obsoleted TLV types 4 and 5. An LSR that proposes to perform crankback re-routing SHOULD support receipt and processing of all fundamental crankback TLVs.
Each repair point SHOULD apply a locally configurable limit to the number of attempts it makes to re-route an LSP, to prevent excessive network usage in the event of significant faults.
For LSP recovery downstream of the fault, if the reservation style is Shared Explicit (SE), the detecting LSR MAY choose not to send a PathTear — this leaves downstream LSP state in place to facilitate make-before-break repair. If no PathTear is sent immediately, the unused state will timeout per RFC 2205 rules.
If End-to-end Re-routing is indicated, or if Segment-based or Boundary Re-routing is allowed and the detecting node chooses not to make re-routing attempts (or has exhausted all possible attempts), the detecting node MUST return a protocol error indication and SHOULD include full crankback information.
The repair point LSR SHOULD maintain a history table of all experienced blockages for an LSP (at least until routing protocol updates the state) so path computations can detour all blockages. The history table SHOULD be discarded using a timer no larger than the LSP retry timer configured on the ingress LSR.
Under End-to-end Re-routing, nodes detecting failures MUST report an error and SHOULD supply crankback information; intermediate nodes SHOULD NOT attempt re-routing.
Under No Re-routing mode, intermediate nodes SHOULD NOT attempt re-routing after failure; nodes detecting failures MUST report an error and MAY supply crankback information. This is the default and backwards compatible option.
When a node gives up re-routing attempts after accumulating multiple failures, it MUST propagate the failure message further upstream and include crankback information when it does so, using TLVs 26 and 27 for compression of accumulated failure lists.
When a node that was responsible for expanding or replacing the explicit route cannot or chooses not to perform crankback re-routing, it MUST update the crankback information with regard to the explicit route that it received before forwarding the PathErr message upstream.
When a ResvErr carrying crankback information is received at an egress LSR that supports crankback extensions, and after all local recovery procedures have failed, it SHOULD generate a PathErr message carrying the crankback information and send it to the ingress LSR.
When crankback information is reported, the IF_ID ERROR_SPEC object MUST be used, and at least one of the TLVs in the range 1 through 3 MUST be present in the IF_ID ERROR_SPEC object.
Crankback is a scheme whereby setup failure information is returned from the point of failure to allow new setup attempts avoiding blocked resources. It applies to both LSP setup failures and LSP recovery to indicate the location of failed links or nodes.
Four re-routing behavior flags are defined for the LSP_ATTRIBUTES object: No Re-routing (default), End-to-end Re-routing, Boundary Re-routing (ABRs/ASBRs only), and Segment-based Re-routing (any node). These values are mutually exclusive and control which nodes may attempt re-routing after failure.
No new object is used to distinguish Path/Resv messages for an alternate LSP under crankback re-routing. The alternate LSP uses the same SESSION and SENDER_TEMPLATE/FILTER_SPEC objects as the initial LSP.
Three bits are defined for inclusion in the LSP Attributes TLV of LSP_ATTRIBUTES object: bit 1 (End-to-end re-routing desired), bit 2 (Boundary re-routing desired), bit 3 (Segment-based re-routing desired). These convey the Re-routing Flag on Path messages.
TLVs 4 and 5 (COMPONENT_IF_DOWNSTREAM and COMPONENT_IF_UPSTREAM) are obsoleted by RFC 4201 and SHOULD NOT be used to identify component interfaces in IF_ID ERROR_SPEC objects, though LSRs MUST still be prepared to receive them.
IANA assigned error value 22 ('Re-routing limit exceeded') for the 'Routing Problem' error code (24) in the 'RSVP Parameters' registry subregistry 'Error Codes and Globally-Defined Error Value Sub-Codes'.
IANA assigned new TLV type values 6-27 in the 'Interface_ID Types' subregistry of the 'GMPLS Signaling Parameters' registry for the new IF_ID_ERROR_SPEC TLV types defined in Section 6.2.
IANA assigned three new bit allocations from the 'Attributes Flags' subregistry of 'RSVP TE Parameters' registry for the LSP_ATTRIBUTES object: bits 1, 2, and 3 for end-to-end, boundary, and segment-based re-routing flags respectively.
Crankback is envisaged as an inter-domain mechanism, and crankback information exchanged over trust domain borders is expected to be of little or no value and likely ignored. Reporting domains should apply information aggregation to preserve confidentiality of network topology. A malicious domain could report that neither it nor its downstream neighbor can provide a path, but this may be detected using indirect path computation via PCE (RFC 4655).
If a malicious user gains protocol access to the network, crankback information might be used to prevent establishment of valid LSPs. Existing RSVP-TE security features (authentication, anti-tampering, anti-spoofing from RFC 2205/3209/3473) SHOULD be made available by all implementations offering crankback, and re-routing attempt thresholds are particularly useful as a defense.
New IF_ID ERROR_SPEC TLV types 6-27 are defined for crankback reporting: types 6-7 (DOWNSTREAM/UPSTREAM_LABEL, variable length GMPLS label), type 8 (NODE_ID, 8 bytes, 32-bit Router ID), types 9/22 (OSPF_AREA, 8 bytes, 4-octet area identifier), types 10/23 (ISIS_AREA, variable 2-11 bytes + length field), types 11/24 (AUTONOMOUS_SYSTEM, 8 bytes, 32-bit AS number), types 12/13/25 (ERO subobjects, variable), types 14-20 (interface/label identifiers), types 26/27 (NODE_EXCLUSIONS and LINK_EXCLUSIONS, variable-length lists).
The ISIS_AREA TLVs (types 10 and 23) encode a variable-length IS-IS area identifier (2-11 octets) preceded by a 1-octet Length field, padded with trailing zeroes to a four-octet boundary.
The NODE_ID TLV (type 8) and REPORTING_NODE_ID TLV (type 21) each carry a 32-bit Router ID in the value field, used to identify the TE Router ID or Router ID within the IGP.