Network-Assigned Upstream Label
updates
- rfc-3471 — Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description
- rfc-3473 — Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions
- rfc-6205 — Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers
Extracted elements (15)
In IP-over-optical (WDM) networks, a client router may not have visibility into the optical network and cannot pick the correct wavelength in advance. Sending a signal at the wrong wavelength may adversely impact existing optical trails, motivating the need for network-assigned upstream labels.
The upstream node continues to signal the Unassigned Upstream Label in the Path message even after receiving an appropriate symmetric label in the Resv message. This ensures the downstream node can pick a different symmetric label if it needs to change the label at a later time (e.g., during wavelength change).
This mechanism is meant to be used only for bidirectional LSPs that assign symmetric labels at each hop along the path. It allows a node to offload upstream label assignment to downstream nodes when the upstream node lacks sufficient information (e.g., wavelength visibility in optical networks).
If the downstream node does not support the Unassigned Upstream Label semantics, it will either (a) reject the special label and generate an error per RFC 3473 Section 3.1 (no compatibility concern), or (b) accept it and return an all-ones label in the Resv LABEL object, which the upstream node will reject with a ResvErr. Both paths result in a well-defined failure mode.
If the downstream node cannot pick the symmetric label, it MUST issue a PathErr message with a 'Routing Problem/Unacceptable Label Value' indication.
If the upstream node desires to make the downstream node aware of its limitations with respect to label selection, it MUST specify a list of valid labels via the LABEL_SET object as specified in RFC 3473.
If the upstream node receives an unacceptable changed label (during a label change after initial setup), it MUST issue a ResvErr message with a 'Routing Problem/Unacceptable Label Value' indication.
If the upstream node that signals an Unassigned Upstream Label receives a label with the all-ones pattern or any other unacceptable label in the LABEL object of the Resv message, it MUST issue a ResvErr message with a 'Routing Problem/Unacceptable Label Value' indication.
The presence of the all-ones (Unassigned Upstream Label) value in the UPSTREAM_LABEL object of a Path message MUST also be interpreted by the receiving node as a request to mandate symmetric labels for the LSP.
After LSP setup, if the network changes the wavelength, the ingress client retunes its laser when it receives a changed label in a modified Resv LABEL object, and the egress client retunes when it receives a changed label in the UPSTREAM_LABEL/LABEL_SET of a modified Path message.
During initial wavelength setup, the ingress router sends a Path message with an Unassigned Upstream Label (0xFFFFFFFF) and keeps the laser off. The downstream WDM node selects the wavelength and forwards it; the egress router tunes its laser accordingly and responds with a Resv. The ingress router then tunes its laser to the network-assigned symmetric label.
The Unassigned Upstream Label is defined as the special label value '0xFFFFFFFF' (all-ones pattern) for a 4-octet label, with similar all-ones patterns expected for labels of other sizes. Its presence in the UPSTREAM_LABEL object of a Path message indicates the upstream node has not assigned an upstream label and requests the downstream node to provide a symmetric label.
IANA has added a new subregistry titled 'Special Purpose Generalized Label Values' under the 'Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters' registry. The all-ones pattern is registered as 'Unassigned Upstream Label' applicable to the UPSTREAM_LABEL object, with new values assigned via Standards Action.
This document defines a special label value for the UPSTREAM_LABEL object and updates processing semantics for an existing RSVP object field. No new security implications are introduced; the security considerations of RFC 3473 and the MPLS/GMPLS security framework (RFC 5920) still apply.
The Unassigned Upstream Label is encoded as a 32-bit all-ones pattern (0xFFFFFFFF) carried in the UPSTREAM_LABEL object of an RSVP-TE Path message. For labels of other sizes, the analogous all-ones pattern is used.