GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)
obsoletes
- rfc-5467 — GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)
Extracted elements (20)
All three new objects are assigned class numbers in the 0bbbbbbb range (120–122), which causes nodes that do not recognize them to return an 'Unknown Object Class' error rather than silently dropping or forwarding the message, enabling the ingress to detect incompatible nodes.
Asymmetric bandwidth bidirectional LSP support was originally published as Experimental (RFC 5467) because it was considered unlikely to be deployed. MPLS-TP (RFC 5654) subsequently mandated this capability, driving promotion to the Standards Track with no technical changes from RFC 5467.
The approach mirrors the original RSVP model: existing SENDER_TSPEC, ADSPEC, and FLOWSPEC objects continue to describe downstream traffic, while three new parallel objects (UPSTREAM_TSPEC, UPSTREAM_ADSPEC, UPSTREAM_FLOWSPEC) describe upstream traffic and travel in the opposite message direction. This reuse avoids defining new encoding rules.
Nodes that do not implement this extension will not recognize UPSTREAM_FLOWSPEC, UPSTREAM_TSPEC, or UPSTREAM_ADSPEC (all in the 0bbbbbbb class range) and will respond with an 'Unknown Object Class' error per RFC 2205. This error propagates to the ingress, which can then route around the incompatible node or terminate the session.
A node unable to allocate a label or internal resources based on the UPSTREAM_FLOWSPEC object MUST issue a PathErr message with a 'Routing problem/MPLS label allocation failure' indication.
Nodes processing a Path message containing an UPSTREAM_FLOWSPEC object MUST use the contents of that object in the upstream label and resource allocation procedure defined in RFC 3473 Section 3.1.
The C-Type of the UPSTREAM_FLOWSPEC object MUST match the C-Type of the SENDER_TSPEC object used in the same Path message.
The Path message of an asymmetric bandwidth bidirectional LSP MUST contain an UPSTREAM_FLOWSPEC object and MUST use the bidirectional LSP formats and procedures defined in RFC 3473.
The UPSTREAM_ADSPEC object MAY be included in any Resv message corresponding to a Path containing an UPSTREAM_FLOWSPEC; the C-Type of the UPSTREAM_TSPEC MUST be consistent with the C-Type of the corresponding UPSTREAM_FLOWSPEC.
The UPSTREAM_TSPEC object MUST be included in any Resv message that corresponds to a Path message containing an UPSTREAM_FLOWSPEC object, and its C-Type MUST match the C-Type of the corresponding UPSTREAM_FLOWSPEC object.
When an ingress receives an UPSTREAM_TSPEC indicating the original reservation is insufficient, it MAY tear down the LSP with a PathTear, or MAY issue a Path message with an updated UPSTREAM_FLOWSPEC to request more resources; the update might require re-routing or result in teardown if resources are unavailable.
UPSTREAM_ADSPEC object (class number 122, form 0bbbbbbb) is optionally carried in Resv messages and conveys available resource information for upstream traffic. Its format mirrors the ADSPEC object (C-Num 13) and MAY be updated or added at transit nodes.
UPSTREAM_FLOWSPEC object (class number 120, form 0bbbbbbb) is carried in Path messages and conveys the bandwidth resources to be reserved in the upstream direction for an asymmetric bandwidth bidirectional LSP. Its format and C-Types are identical to those of the FLOWSPEC object (C-Num 9).
UPSTREAM_TSPEC object (class number 121, form 0bbbbbbb) is carried in Resv messages and describes the traffic flow originating at the egress (upstream sender). Its format and C-Types mirror those of the SENDER_TSPEC object (C-Num 12).
IANA assigned class number 120 (0bbbbbbb range) to UPSTREAM_FLOWSPEC in the 'RSVP PARAMETERS' Class Names, Class Numbers, and Class Types registry, with C-Types identical to those of the FLOWSPEC object (C-Num 9).
IANA assigned class number 121 (0bbbbbbb range) to UPSTREAM_TSPEC in the 'RSVP PARAMETERS' registry, with C-Types identical to those of the SENDER_TSPEC object (C-Num 12).
IANA assigned class number 122 (0bbbbbbb range) to UPSTREAM_ADSPEC in the 'RSVP PARAMETERS' registry, with C-Types identical to those of the ADSPEC object (C-Num 13).
The new UPSTREAM_TSPEC, UPSTREAM_ADSPEC, and UPSTREAM_FLOWSPEC objects parallel the existing downstream objects and share their vulnerability surface; any security weakness exploitable via those objects now also applies to messages flowing in the reverse (upstream) direction. No new signaling messages or control-plane adjacencies are introduced, so no additional message- or neighbor-level threats arise beyond those in RFC 3473 and RFC 5920.
The flow descriptor list for bidirectional asymmetric LSPs extends FF and SE descriptors to include UPSTREAM_TSPEC (mandatory) and optionally UPSTREAM_ADSPEC immediately after the FLOWSPEC object. The SE filter spec list is unmodified.
The sender descriptor for bidirectional asymmetric LSPs extends the standard format by appending UPSTREAM_LABEL and UPSTREAM_FLOWSPEC after the optional RECOVERY_LABEL. The UPSTREAM_FLOWSPEC is mandatory in this descriptor.