Summary

  • RFC 5150 combines dedicated GMPLS segment LSPs, or S-LSPs, into one end-to-end LSP.
  • An S-LSP admits at most one e2e LSP and allocates its whole bandwidth to that association.
  • The head end requests stitching with bit 5 in LSP_ATTRIBUTES; the egress answers with the matching ready bit in RRO.
  • A capable egress also returns a non-null S-LSP label; unsupported stitching uses Routing Problem value 30.
  • The ready exchange confirms declared protocol participation, not the later e2e forwarding state.
  • S-LSP endpoints may appear adjacent in the TE topology although no data-plane forwarding adjacency exists.
  • Label and Upstream Label values exchanged across the e2e S-LSP hop are explicitly meaningless and must be ignored.
  • Actual continuity requires local swap programming at both segment boundaries and, for bidirectional service, in both directions.
  • The e2e RRO records the segment endpoint while omitting intermediate nodes and links inside the S-LSP.
  • S-LSP and e2e teardown are independent; segment loss should trigger recovery, but the response signalling is out of scope.
  • RSVP control authentication protects communicating neighbours, not the separate data interface or delivered payload.
  • Readiness, route abstraction, boundary readback, hidden-path health and observed traffic remain separate evidence layers.

Two labels serve two different kinds of evidence

RFC 5150 prepares a segment before an end-to-end request uses it. The S-LSP head end places LSP stitching desired in bit 5 of the LSP_ATTRIBUTES Flags TLV. A participating egress allocates a non-null label in the segment Resv and sets LSP segment stitching ready in the RRO Attributes subobject. If it recognizes the request but cannot perform the behavior, it returns PathErr with Routing Problem value 30, Stitching unsupported.

That exchange matters. It lets the head end distinguish a prepared segment from an endpoint that has not agreed to stitch. The head end must inspect the ready bit and must not use a segment when the bit is clear. Yet the evidence ends where the statement ends: the egress has declared and prepared support for the segment procedure.

The later end-to-end setup carries a different Label in Resv and, for a bidirectional e2e LSP, an Upstream Label in Path. Those objects resemble ordinary forwarding instructions. Across this hop, they are not. RFC 5150 says that because there is no forwarding adjacency between the S-LSP endpoints, any value may be chosen, the values have no significance, and recipients must not process them.

An audit that counts label objects without identifying which contract they belong to can therefore produce the opposite of proof. A mandatory field may be present precisely to preserve RSVP procedure while conveying no forwarding identifier across the abstract hop.

The forwarding action lives at each boundary

Traffic continuity is built with local operations that the logical hop label does not encode. At the S-LSP egress, traffic arriving from the segment should be switched to the downstream portion of the e2e LSP. At the S-LSP ingress, traffic arriving from the upstream e2e portion should be switched into the segment. Bidirectional service requires the reverse actions too.

These are separate state installations on separate nodes. A successful end-to-end Resv can coexist with a missing ingress swap, a stale egress swap, a one-way reverse mapping or an internal segment failure. The symbolic control exchange names the intended composition. Only boundary readback and data-plane observation can show that the composition runs.

The S-LSP selection itself has constraints: switching type must match the Generalized Label Request, and ERO, bandwidth and local TE policy also enter the decision. A matching type proves eligibility under one constraint. It does not demonstrate that every other constraint was current or that the selected segment carried traffic.

One TE hop can contain an invisible path

An S-LSP may be managed and advertised as a TE link. In the TE topology its endpoints look adjacent; in the data plane they are not adjacent. The segment can cross zero or more intermediate GMPLS nodes, and no label is directly meaningful between the two endpoint nodes.

The e2e RRO should record the S-LSP TE-link endpoint. It should not record the intermediate links or nodes traversed inside the S-LSP for that hop. This is intentional abstraction, not incomplete implementation. It also limits the conclusion: a clean e2e route record cannot prove the hidden segment's internal state, physical diversity, per-hop capacity or exact failure location.

Advertising the segment is optional. If it is advertised, it enters the TE database and may participate in path computation, while increasing link-state size and complexity. If it is allocated to one e2e LSP, unreserved bandwidth should be set to zero. These database outcomes protect admission semantics. They remain different from a forwarding-table readback and a packet result.

Dedicated capacity does not make hierarchy

LSP hierarchy allows several higher-layer LSPs to traverse one H-LSP, with meaningful labels separating them across the hierarchical hop. Stitching stays in the same switching layer. One S-LSP belongs to at most one e2e LSP, and its entire bandwidth is assigned to that association.

The distinction is operationally useful because a segment can cross a domain or shield legacy nodes. RFC 5150 even describes stitching a P2MP-capable edge across legacy LSRs, while warning that such a design may reduce the attraction of RSVP P2MP and deserves careful examination.

The exclusivity rule prevents two e2e LSPs from casually sharing one segment. It does not measure capacity, enforce isolation outside the prescribed state or prove that the exclusive customer received service. Bundling can group multiple S-LSP components into one TE link, but each component preserves its one-e2e allocation boundary.

Teardown has two clocks

The segment and the end-to-end LSP have independent RSVP sessions. Their teardown procedures are also independent. One can enter graceful administrative shutdown while the other removes state immediately. A statically provisioned segment may outlive the e2e LSP; a dynamically created segment may be removed under local policy after it is unused.

Deleting the S-LSP should be treated as a failure event for the associated end-to-end LSP and should trigger teardown or recovery. RFC 5150 leaves the actual response signalling out of scope. That gap must not be filled with an assumed recovery receipt.

For a dynamic segment, the document recommends waiting after e2e teardown—nominally 30 seconds—before deleting the unused S-LSP, reducing simultaneous RSVP errors and teardown messages. The delay is a coordination measure, not a restoration guarantee. Monitoring must preserve which session ended, how, when labels and bandwidth were released, and whether traffic found another path.

A protected control neighbour is not a protected service path

RSVP control messages need not use the data interface they describe. Security associations therefore bind the communicating control neighbours, using their IP identities rather than assuming a sending interface remains stable. IPsec can protect the message exchange under that association.

This separation is another reason to resist one green status. Authenticated Path and Resv messages show a protected control conversation. They do not read the swap state, traverse the S-LSP's hidden interior or exercise the payload application.

IANA bit 5 and Routing Problem value 30 provide stable coordination. The verified erratum repairs dropped wording in the readiness paragraph. Neither registry nor editorial correction establishes support in a named implementation. Documentary precision makes the question testable; running state answers it.

Sources

  1. RFC 5150, HTML
  2. RFC 5150, text
  3. RFC Editor record
  4. IETF Datatracker record
  5. RFC 5150 history
  6. References from RFC 5150
  7. RFC 5150 errata
  8. RFC 4206
  9. RFC 3209
  10. RFC 3473
  11. RFC 4420
  12. RFC 3477
  13. RFC 4201
  14. RFC 4203
  15. RFC 4205
  16. RFC 2747
  17. RFC 3032
  18. RFC 5151
  19. IANA RSVP parameters
  20. Minimum Initial Specification
  21. On Reality Layers
  22. Running-Code Primacy