Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description
updated by
- rfc-4201 — Link Bundling in MPLS Traffic Engineering (TE)
- rfc-4328 — Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control
- rfc-4872 — RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery
- rfc-6002 — Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions
- rfc-6003 — Ethernet Traffic Parameters
- rfc-6205 — Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers
- rfc-7074 — Revised Definition of the GMPLS Switching Capability and Type Fields
- rfc-7699 — Generalized Labels for the Flexi-Grid in Lambda Switch Capable (LSC) Label Switching Routers
- rfc-8359 — Network-Assigned Upstream Label
Extracted elements (30)
Bandwidth is encoded as IEEE 754 32-bit floating point in bytes per second to accommodate the wide dynamic range from DS0 (64 kbps) to OC-768 (39.8 Gbps) with a single uniform encoding, while discrete standard signal rates are enumerated as guidelines for non-packet LSPs.
Bidirectional LSPs are introduced because establishing two independent unidirectional LSPs for non-PSC technologies doubles control overhead, increases setup latency to one round-trip plus one transit delay, risks resource contention, and complicates SONET/SDH protection switching that relies on bidirectional hop-by-hop paths.
Control channel separation (control plane independent of data plane) is formalized in GMPLS because certain technologies (e.g., pure optical links) cannot carry in-band control traffic. Interface identification information must therefore be explicitly conveyed in signaling to associate an LSP setup with a specific data channel.
Label Sets are needed because some optical endpoints can only generate a small set of wavelengths, some intermediate nodes cannot perform wavelength conversion (CI-incapable), and some links support different wavelength sets at each end — requiring the label selection to be constrained to a mutually acceptable subset.
The Generalized Label does not contain a type field because the sending and receiving nodes already know from context (the link type) what kind of label to expect. This keeps the label compact while relying on implicit context rather than explicit typing.
The Suggested Label is motivated by optical equipment (e.g., micro-mirror-based OXCs) that takes tens of milliseconds per hop to configure its switching fabric. Without early label suggestion, the Resv/MAPPING message must be delayed at each hop, causing significant setup latency. The suggested label also aids rapid restoration after nodal faults.
Control channel fault handling when independent of the data channel requires protocol-specific mechanisms (defined in RFC 3473 and RFC 3472) to handle both neighbor communication interruptions (with state resynchronization on restore) and node control-plane restarts (requiring label mapping preservation). These cases only apply when there are mechanisms to detect data channel failures independently.
Port and wavelength label values have significance only between two neighboring nodes. The receiver may need to convert the received label value into a value with local significance. Channel identifier mappings may be established by configuration or by a protocol such as LMP.
The Generalized Label carries only a single level of label hierarchy; it is non-hierarchical. When multiple levels of label (LSPs within LSPs) are required, each LSP must be established separately using the LSP hierarchy mechanisms defined in [MPLS-HIERARCHY].
Interface_ID TLV value fields whose length is not a multiple of four MUST be zero-padded so that the TLV is four-octet aligned.
Resources allocated for a secondary LSP MAY be used by other LSPs until the primary LSP fails over; at that point, any LSP using those resources MUST be preempted.
The Reserved field in the Administrative Status Information object MUST be set to zero on transmission and MUST be ignored on receipt; transit nodes SHOULD pass these bits through unmodified. The Reflect (R) bit MUST NOT be set in state change request (Notify) messages.
The Reserved field in the Label_Set object MUST be set to zero on transmission and MUST be ignored on receipt.
The Reserved field in the Protection Information object MUST be set to zero on transmission and MUST be ignored on receipt; transit nodes SHOULD pass these bits through unmodified.
Upon receipt of a 'Routing problem/Label allocation failure' error due to bidirectional LSP label contention, the node SHOULD try to allocate a different Upstream Label (and a different Suggested Label if used) to the bidirectional path.
When label contention occurs between two bidirectional LSP setup requests, the node with the higher node ID MUST issue a PathErr/NOTIFICATION message with a 'Routing problem/Label allocation failure' indication to win the contention.
An Upstream Label, carried in bidirectional LSP setup, has the same format as the Generalized Label. Its presence in a signaling message indicates that bidirectional LSP setup is being requested. Two labels must be allocated: one for each direction.
Explicit Label Control introduces a Label ERO subobject/ER Hop that allows an LSP initiator to specify the exact label to use on a link. It contains an L bit (MUST be 0), a U bit (0 for downstream label, 1 for upstream label on bidirectional LSPs), and a variable-length Label field identical to the Generalized Label format.
The Acceptable Label Set is used in error messages to indicate which labels would be acceptable when an 'Unacceptable label value' error occurs. Its format is identical to a Label Set (Section 3.5.1) and is carried in protocol-specific error messages as defined in RFC 3472 and RFC 3473.
The Generalized Label Request carries three fields in 32 bits: LSP Encoding Type (8 bits) indicating the encoding (e.g., Packet, Ethernet, SDH, Lambda, Fiber), Switching Type (8 bits) indicating the switching capability required on each link, and Generalized PID (G-PID, 16 bits) identifying the payload/client layer of the LSP.
The Suggested Label allows an upstream node to communicate its label preference to a downstream node before the downstream node selects and communicates a label upstream. Its format is identical to a Generalized Label. The upstream node may begin configuring its hardware with the suggested label to reduce setup latency, but MUST NOT transmit data on the suggested label until the downstream node confirms it.
Five IANA-administered namespaces are defined: LSP Encoding Type (8 bits, values 1-255, values 1-11 defined here), Switching Type (8 bits, values 1-255, values 1-4/100/150/200 defined here), G-PID (16 bits, values 0-1500, values 0-46 defined here), Action (8 bits, values 0-255, values 0-3 defined here), and Interface_ID Type (16 bits, values 1-65535, values 1-5 defined here). All future assignments require IETF Consensus or a Specification.
RFC 3471 introduces no new security considerations beyond those already present in RFC 3209 (RSVP-TE) and RFC 3212 (CR-LDP). Security considerations for the GMPLS-specific protocol forms are addressed in RFC 3473 (RSVP-TE extensions) and RFC 3472 (CR-LDP extensions) respectively.
Administrative Status Information is a 32-bit field: bit 31 (R) is the Reflect bit, bits 3-30 are reserved, bit 2 (T) indicates testing mode, bit 1 (A) indicates administratively down, and bit 0 (D) indicates deletion in progress.
Interface_ID is a TLV-structured field where each TLV has a 16-bit Type, 16-bit Length (total TLV length = 4 + value length in octets), and variable Value. Five types are defined: IPv4 (type 1, 8 bytes), IPv6 (type 2, 20 bytes), IF_INDEX (type 3, 12 bytes), COMPONENT_IF_DOWNSTREAM (type 4, 12 bytes), COMPONENT_IF_UPSTREAM (type 5, 12 bytes). Value fields not a multiple of four MUST be zero-padded.
The Generalized Label is a variable-length field whose interpretation depends on the link type. For FSC and LSC port/wavelength labels, a 32-bit Label field identifies the port/fiber or lambda from the sender's perspective. Generic MPLS and Frame Relay labels are right-justified in 32 bits; ATM labels encode VPI in bits 0-15 and VCI in bits 16-31.
The Generalized Label Request is a 32-bit field: bits 0-7 are LSP Encoding Type, bits 8-15 are Switching Type, and bits 16-31 are G-PID. LSP Encoding Type values range from 1 (Packet) to 11 (FiberChannel); Switching Type values include PSC-1 through PSC-4 (1-4), L2SC (51), TDM (100), LSC (150), and FSC (200).
The Label_Set object/TLV contains an 8-bit Action field (0=Inclusive List, 1=Exclusive List, 2=Inclusive Range, 3=Exclusive Range), a 10-bit Reserved field, a 14-bit Label Type field, and one or more variable-length Subchannel elements in the same format as a Generalized Label.
The Protection Information object is a 32-bit field: bit 31 (S) indicates secondary LSP, bits 6-30 are reserved (MUST be zero on transmission, MUST be ignored on receipt, SHOULD pass through unmodified), and bits 0-5 are Link Flags indicating desired link protection type (0x01=Extra Traffic, 0x02=Unprotected, 0x04=Shared, 0x08=Dedicated 1:1, 0x10=Dedicated 1+1, 0x20=Enhanced).
The Waveband Label reuses the Generalized Label format with three 32-bit fields: Waveband Id (selected by sender), Start Label (channel identifier of lowest wavelength in the waveband), and End Label (channel identifier of highest wavelength), totaling 96 bits.