ietf-corpus

rfc-3472

Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions

P. Ashwood-Smith (Editor), L. Berger (Editor)
date2003-02 streamIETF areartg wgccamp statusPROPOSED STANDARD pages23 canonicalhttps://www.rfc-editor.org/rfc/rfc3472 doi10.17487/RFC3472
This document describes extensions to Multi-Protocol Label Switching (MPLS) Constraint-based Routed Label Distribution Protocol (CR-LDP) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a CR-LDP specific description of the extensions. A generic functional description can be found in separate documents. [STANDARDS-TRACK]

updated by

Extracted elements (31)

design-rationale §7.2.1

The Admin Status deletion procedure recommends setting administrative status before tearing down an LSP—particularly in optical networks—to give all nodes advance notice and allow graceful resource release rather than abrupt removal. The 30-second fallback timer covers nodes that do not understand the Admin Status TLV.

routing

design-rationale §2.3.1

The waveband label swap mechanism (swapping Start and End labels when mirroring wavelengths) exists to allow egress LSRs to detect and compensate for wavelength inversion across the waveband tunnel. Without this mechanism, an odd number of mirrored switching operations would cause the egress to incorrectly map wavelengths—for example, expecting L1 when the actual output is L100.

routing

interoperability-note §2.1.2

Bandwidth encodings for GMPLS are carried in the existing CR-LDP Traffic Parameters TLV using its Peak and Committed Data Rate fields, with values defined in RFC 3471. Other bandwidth or service-related parameters in the TLV are ignored by GMPLS nodes and carried transparently.

routing

normative-requirement §7.3.1 MUST

A node sending a Notification with the Down (D) bit set MUST verify it receives a corresponding LABEL RELEASE within a configurable period. This period SHOULD default to 30 seconds. If no LABEL RELEASE is received, the node SHOULD send a Label Release downstream and a LABEL WITHDRAW upstream to handle nodes not supporting the Admin Status TLV.

routing

normative-requirement §7.2 SHOULD

An egress node receiving a REQUEST with the R bit set in the Admin Status TLV SHOULD send a MAPPING containing an Admin Status TLV with the same values (except the R bit cleared). Absence of the Admin Status TLV is equivalent to receiving one with all bits zero.

routing

normative-requirement §2.4 MUST

Errors in received Suggested Labels (type 0x904) MUST be ignored, including inconsistent or unacceptable values. If a downstream node passes a label differing from the suggested label, the upstream LSR MUST either reconfigure to use the downstream-specified label or generate a NOTIFICATION with 'Routing problem/Unacceptable label value'. An ingress SHOULD NOT transmit data traffic using a suggested label until the downstream node passes a corresponding label upstream.

routing

normative-requirement §8.1.2 MUST

For a unidirectional LSP, a downstream data channel MUST be indicated in the IF_ID TLV. A node receiving IF_ID TLVs saves their values and returns them in the subsequent MAPPING message. If IF_ID TLV content is inconsistent with a received ERO, the node MUST send a LABEL ABORT with error code 'Routing Error' and value 'Bad Explicit Routing TLV Error'.

routing

normative-requirement §2.2.1 MUST

If a Generalized Label received in a MAPPING message is unacceptable, the recipient MUST generate a NOTIFICATION with a 'Routing problem/MPLS label allocation failure' indication. The NOTIFICATION MAY include an Acceptable Label Set.

routing

normative-requirement §2.5.1 MUST

If a node cannot select a label from the Label Set or cannot parse the Label Set TLVs, the request MUST be terminated and a NOTIFICATION with 'Routing problem/Label Set' MUST be generated. When processing a MAPPING message at an intermediate node, the label propagated upstream MUST fall within the Label Set.

routing

normative-requirement §9 MUST

In optical transport networks, a mechanism MUST exist to detect a signaling communication failure in the control plane, and a recovery procedure SHALL guarantee connection integrity at both ends of the signaling channel without impacting existing optical connections.

routing, security

normative-requirement §7.3 MUST NOT

Intermediate or egress nodes triggering administrative status changes via Notification messages MUST include the Admin Status TLV with appropriate bits set; the Reflect (R) bit MUST NOT be set in such notifications. A node receiving a Notification with the Delete (D) bit set SHOULD initiate the deletion procedure.

routing

normative-requirement §2.1.1 MUST

Nodes MUST verify that the Switching Type parameter is supported on the corresponding incoming interface. If not supported, the node MUST generate a NOTIFICATION message with a 'Routing problem/Switching Type' indication.

routing

normative-requirement §2.1.1 MUST

The egress MUST generate a NOTIFICATION with 'Routing problem/Unsupported G-PID' if the G-PID cannot be supported. In PSC with penultimate hop popping (PHP), the penultimate hop also checks the G-PID and MUST generate a NOTIFICATION with 'Routing problem/Unacceptable label value' if unsupported.

routing

normative-requirement §2.1.1 MUST

Transit and egress nodes MUST verify that the node and outgoing interface can support the requested LSP Encoding Type. If encoding cannot be supported, the node MUST generate a NOTIFICATION message with a 'Routing problem/Unsupported Encoding' indication.

routing

normative-requirement §6.1 MUST

Transit nodes processing a REQUEST containing a Protection TLV MUST verify that the requested protection can be satisfied by the outgoing interface or tunnel. If not, the node MUST generate a NOTIFICATION with 'Routing problem/Unsupported Link Protection'.

routing

normative-requirement §5.1 MUST

When a Label ER-Hop has U=0, its label value MUST be copied into a new Label Set TLV included in the outgoing REQUEST. When U=1, the label MUST be copied into a new Upstream Label TLV included in the outgoing REQUEST. Label ER-Hops are removed from the ER after processing.

routing

normative-requirement §3.1 MUST

When a REQUEST containing an Upstream Label is received and the label is not acceptable, the receiver MUST issue a NOTIFICATION with 'Routing problem/Unacceptable label value'. An intermediate node that cannot allocate a label or internal resources MUST issue a NOTIFICATION with 'Routing problem/Label allocation failure'.

routing

normative-requirement §2.3.1 MUST

When a waveband is switched to another waveband with wavelength mirroring about a center frequency, the Start and End labels in the Waveband Label TLV MUST be swapped before forwarding with the new Waveband Id. This operation MUST be performed in both directions when a bidirectional waveband tunnel is being established.

routing

protocol-element §4

Acceptable Label Set TLV (type 0x082a) has the same format as the Label Set TLV and is carried in NOTIFICATION messages to convey the set of labels acceptable to the generating node following a label error. Its inclusion is optional; when included, the NOTIFICATION SHOULD carry a 'Routing problem/Unacceptable label value' indication.

routing

protocol-element §3

Bidirectional LSP setup is indicated by the presence of an Upstream Label TLV (type 0x0826) in the REQUEST message. It uses the same format as the Generalized Label and MUST indicate a label that is valid for forwarding at the time the REQUEST is sent.

routing

registry §12

This document registers 14 new TLV types in the LDP namespaces registry: Generalized Label Request (0x0824), Generalized Label (0x0825), Upstream Label (0x0826), Label Set (0x0827), Waveband Label (0x0828), ER-Hop (0x0829), Acceptable Label Set (0x082a), Admin Status (0x082b), Interface ID (0x082c), IPV4 Interface ID (0x082d), IPV6 Interface ID (0x082e), IPv4 IF_ID Status (0x082f), IPv6 IF_ID Status (0x0830), and Protection (0x0835).

registry, routing

security-consideration §11

This document introduces no new security considerations beyond those already present in RFC 3212 (Constraint-Based LSP Setup using LDP).

security, routing

wire-format §7.1

Admin Status TLV (type 0x082b) carries an R (Reflect) bit, Reserved bits, and three status flags: T (testing), A (administratively down), and D (delete). It is optionally carried in REQUEST, MAPPING, and Notification messages to convey or request changes to LSP administrative state.

routing

wire-format §2.1

Generalized Label Request TLV (type 0x0824) carries three fields: LSP Encoding Type (1 octet), Switching Type (1 octet), and G-PID (2 octets). It is set by the ingress node, passed transparently by transit nodes, and consumed by the egress node.

routing

wire-format §2.2

Generalized Label TLV (type 0x0825) carries a variable-length Label field encoding a generalized label. It travels upstream in MAPPING messages; presence of both a generalized and a normal label TLV in the same MAPPING message is a protocol error.

routing

wire-format §8.2.1

IPv4 IF_ID Status TLV (type 0x082f) carries IPv4 Next/Previous Hop Address (32 bits), Status Code (32 bits), and sub-TLVs to indicate an error associated with a specific interface. IPv6 IF_ID Status TLV (type 0x0830) uses a 128-bit IPv6 Error Node Address.

routing

wire-format §8.1.1

IPv4 Interface ID TLV (type 0x082d) carries IPv4 Next/Previous Hop Address (32 bits), Logical Interface ID (32 bits), and Interface ID sub-TLVs. IPv6 Interface ID TLV (type 0x082e) uses a 128-bit IPv6 address in place of the IPv4 address. Both are used in REQUEST and MAPPING messages to identify data channels when control and data channels are separated.

routing

wire-format §5

Label ER-Hop TLV (type 0x0829) carries L and U bits (2 bits), Reserved (14 bits), and a variable-length Label field. The U bit distinguishes downstream (U=0) from upstream (U=1) label specification in explicit label control.

routing

wire-format §2.5

Label Set TLV (type 0x0827) carries an Action field (8 bits), Reserved bits, Label Type (14 bits indicating the TLV type of the labels), and one or more Subchannel entries. Actions 0/1 add/exclude specific labels; actions 2/3 add/exclude label ranges.

routing

wire-format §6

Protection TLV (type 0x0835) carries an S bit (1 bit), Reserved bits, and Link Flags (least-significant bits) to indicate the specific protection attributes requested for an LSP.

routing, security

wire-format §2.3

Waveband Label TLV (type 0x0828) contains three 32-bit fields: Waveband Id, Start Label, and End Label, representing a contiguous group of wavelengths for waveband switching.

routing