Summary

  • RFC 5151 governs RSVP-TE LSPs crossing ASes, IGP areas or GMPLS overlays.
  • Each domain may use contiguous, nested or stitched signaling, subject to ingress constraints and local border policy.
  • Borders may reject internal ERO disclosure, expand loose hops and choose an exit without exporting the complete computation.
  • A border may generalize a node-specific PathErr into a domain-level error when confidentiality requires it.
  • PathErr must not simply be suppressed, except while a permitted crankback attempt is under way.
  • A successful crankback causes the held error to be discarded; failure requires it to continue upstream.
  • RRO internal hops may be replaced by a domain identifier or removed, although the border itself must remain visible.
  • RFC 5151 says signaling still works after that filtering, while management diagnostics may become inoperable.
  • RRO-dependent Fast Reroute can also become inefficient because label and merge-point evidence is missing.
  • Replacing a Notify recipient enables local action but creates border processing and forwarding whose cost grows with domain count.
  • Bit 4 can require contiguous signaling and report method behavior; it does not prove diagnostic completeness or delivery.
  • End-to-end assurance needs separate receipts for border decisions, disclosed evidence, hidden paths, recovery actions and observed traffic.

A path can survive an amputated record

Record Route Object is optional. It supports loop detection and describes the hops an LSP traversed, but RFC 5151 gives a domain border explicit authority to filter that description for confidentiality. A list of internal identifiers can become one AS number. It can disappear entirely, leaving only the borders.

The border cannot erase itself. It must remain present in the RRO. That rule preserves an administrative skeleton: the ingress can see that the path crossed a named boundary even when it cannot see what happened inside.

The specification is unusually direct about the consequence. Filtering does not hamper signaling, but the lost information may make management diagnostics inoperable or force coordination among administrators of several domains. “The LSP is up” and “the failure can be isolated from the ingress” are therefore separate service properties.

Three signaling methods distribute authority differently

A contiguous LSP keeps one RSVP session and LSP ID along the entire path. A nested design carries the end-to-end LSP inside one or more hierarchical LSPs. A stitched design joins separately signaled segments while producing one contiguous path in the data plane. One end-to-end route may mix all three by domain.

The ingress can constrain the choice, but it does not own every decision. Each border applies domain policy and chooses within the remaining freedom. A transit operator may require stitching precisely because it wants to reoptimize its internal segment without handing that timing to the ingress. If the ingress insists on contiguous signaling, the domain may reject the setup; the ingress then avoids the domain, relaxes the condition or fails the service.

This is a control bargain, not merely a packet format. The provider asking for end-to-end visibility and the domain protecting internal autonomy have legitimate but incompatible objectives. The protocol records some of the bargain. It does not manufacture a shared diagnostic operating model.

ERO expansion names the next authority

At a border, the received Explicit Route Object reflects the computation method, the TE visibility available to earlier nodes and policies applied along the way. A domain may reject an ERO that names internal nodes. The normal response is Inter-domain explicit route rejected; security policy may instead drop the Path silently or return different information.

If the next item is a loose IP or AS hop, the border expands it through local computation. If nothing follows the local border, the RSVP Session destination becomes the next loose hop. An ERO referring to a TE link created by an H-LSP or stitched segment cannot be continued as an ordinary contiguous LSP; capability, signaled constraints and local policy select nesting or stitching.

The resulting ERO is proof of the route description that survived each authority. It is not a receipt for every candidate examined, every excluded risk or every policy reason that shaped the exit.

A PathErr can become a statement about a whole domain

Setup failure sends PathErr toward the ingress. Every border along the return path sees it. A border may replace “node X failed for reason Y” with “domain B failed” when confidentiality is specifically required. Non-border nodes should not rewrite the message, and borders should not do so casually.

The error may not be suppressed merely to make the failure disappear. One exception creates an important time boundary: a border may hold the PathErr while it attempts crankback. It can compute another route inside the domain or choose another downstream domain if local policy and the Path parameters permit.

If a later attempt succeeds, the held error must be discarded. If all attempts fail, it must travel upstream, possibly with aggregated crankback detail. A missing PathErr is consequently ambiguous until the attempt ledger is joined: it can mean no failure, retry in progress or successful alternate setup. The success receipt is the later established path, not the silence itself.

Fast Reroute consumes evidence that confidentiality can remove

RRO filtering is not limited to human troubleshooting. RFC 5151 notes that procedures depending on RRO information can become inefficient. MPLS-TE Fast Reroute uses that information to determine labels and the downstream merge point.

Protection across loose hops has another dependency. The node expanding the backup route needs the protected path between the point of local repair and the merge point so that the backup remains disjoint. RRO, DETOUR and route-exclusion mechanisms carry parts of that knowledge. If domains expose only a boundary skeleton, disjointness needs another trusted coordination channel or a computation authority with sufficient visibility.

A configured bypass tunnel is therefore not a diversity receipt. The chain must name the protected risk, the working path evidence available to the computation point, the exclusion applied, the selected backup path and the observed switch. Otherwise “protected” can mean only that another LSP exists.

Notify interception moves the receipt

GMPLS Notify can travel directly rather than hop by hop. A border that wants to observe the event for local protection is encouraged to replace the Notify Request recipient with its own address. Some messages originally intended for the ingress must then be examined, processed and forwarded at each boundary.

That rewrite enables fast local authority. It also changes what an upstream observer can prove. Receipt by the border proves delivery to the border. It does not prove that the original ingress received an equivalent event after filtering, modification and forwarding.

RFC 5151 states that the processing and forwarding cost grows linearly with the number of domains. Confidentiality policy can further modify the content. An alerting design that counts the first Notify without tracing the forwarding chain turns local observability into an end-to-end claim.

Bit 4 constrains method, not outcome

The ingress can set Contiguous LSP in bit 4 of the Attributes Flags TLV. A border receiving the set bit must not nest or stitch. When the bit is clear, local policy may choose either. Transit nodes must not modify the request.

A node that recognizes the bit but cannot support contiguous operation returns Routing Problem value 28. A capable border or loose-hop expander signals contiguously and, when an RRO is present, reports that behavior in an RRO Attributes subobject. Unknown TLV or bit handling preserves the object unchanged.

These rules provide a valuable method receipt. They say which signaling construction was required and acknowledged. They do not say that RRO internals were disclosed, a failure cause will remain precise, a backup is disjoint or customer traffic arrived.

Local optimization can accumulate into end-to-end drift

Contiguous make-before-break is initiated by the ingress. In nested or stitched designs, a domain may reoptimize its H-LSP or segment independently so long as entry and exit borders remain fixed. This preserves local autonomy and can reduce the scope of change.

It can also split incentives. A transit domain may accept the service it delivers locally and decline to reoptimize, while the cumulative effect across domains troubles the head end. The ingress may request end-to-end action; a transit domain may ignore the request. Per-domain action also cannot choose new borders, while end-to-end action can.

The management record should therefore preserve who saw degradation, who controlled each segment, which request was made, which domains acted and what traffic changed. A completed make-before-break procedure is not a universal performance receipt.

Security protects a relationship, not a diagnosis

Neighbouring administrators must satisfy themselves that a suitable trust relationship exists before enabling inter-domain RSVP-TE. They may coordinate keys, enforce contract attributes at borders, rate-limit setup and error notifications, and filter outbound objects. If trust is absent, the RFC recommends not deploying the signaling and disabling it on inter-domain interfaces.

Those safeguards are necessary because an inter-domain control plane exposes resources and topology. They also explain why evidence may be restricted. A valid authenticated neighbor does not prove the neighbor disclosed an internal cause, selected a physically disjoint path, forwarded a Notify unchanged or restored the data plane.

The durable operating model is not “disclose everything.” It is to define the minimum evidence each party will expose, the private evidence it will retain, the correlation identifiers used across boundaries, and the escalation procedure that can assemble the chain without pretending one RRO contains it all.

Sources

  1. RFC 5151, HTML
  2. RFC 5151, text
  3. RFC Editor record
  4. IETF Datatracker record
  5. RFC 5151 history
  6. RFC 5151 references
  7. RFC 5151 errata
  8. RFC 3209
  9. RFC 3473
  10. RFC 4206
  11. RFC 4420
  12. RFC 5150
  13. RFC 4726
  14. RFC 4208
  15. RFC 4920
  16. RFC 4090
  17. RFC 4873
  18. RFC 4874
  19. RFC 4655
  20. RFC 4216
  21. RFC 4105
  22. RFC 2747
  23. RFC 5152
  24. IANA RSVP parameters
  25. Minimum Initial Specification
  26. On Reality Layers
  27. Running-Code Primacy