Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control
updated by
- rfc-7139 — GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks
updates
- rfc-3471 — Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description
Extracted elements (26)
No additional Switching Type values are needed for G.709 because ODUk switching belongs to the existing TDM class and OCh switching belongs to the Lambda Switch Capable (LSC) class. Reusing existing switching types avoids proliferation of new code-points for what are logically equivalent switching capabilities.
Ordered label lists (rather than bitmaps or ranges) are used for ODUj multiplexing, virtual concatenation, and multiplication because the logical order of components in the multiplex may differ from physical tributary slot order, and explicit ordering is needed for correct signal reconstruction.
The ODUk label space is structured as a tree (root = OTUk, leaves = ODUj tributary slots) to self-consistently characterize the full G.709 multiplexing hierarchy. This allows a single label to identify the exact position of an ODUj signal within an ODUk multiplexing structure without requiring separate context.
The G.709 Optical Channel label encoding is applicable to both OTN Optical Channel layer and pre-OTN Optical Channel layer. OChr (reduced functionality optical channel) is explicitly excluded because its Connection Function between OTM-nr.m/OTM-0r.m is not defined in ITU-T G.798.
A transit or egress node receiving a Path message containing a GENERALIZED_LABEL_REQUEST object MUST generate a PathErr message with a 'Routing problem/Unsupported Encoding' indication if the requested LSP Encoding Type cannot be supported on the corresponding incoming interface.
For a particular sender in a session, the contents of the FLOWSPEC object received in a Resv message SHOULD be identical to the contents of the SENDER_TSPEC object in the corresponding Path message. If they do not match, a ResvErr message with 'Traffic Control Error/Bad Flowspec value' SHOULD be generated.
For ODUk in OTUk mapping, only one label appears in the Generalized Label as a single 32-bit value. For ODUj in ODUk multiplexing (k > j), an explicit ordered list of labels is provided; the order must reflect the logical order of ODUj in the multiplex, not the physical order of tributary slots.
Intermediate and egress nodes MUST verify that the node and its interfaces can support the requested Signal Type, NMC, and NVC values. If not supported, the node MUST generate a PathErr message with 'Traffic Control Error/Service unsupported'.
Optical Channel label encoding and distribution rules defined in RFC 3471 MUST be used for the Upstream Label, the Suggested Label, and the Generalized Label at the OCh layer.
Reserved fields in the G.709 traffic parameters SHOULD be set to zero when sent and MUST be ignored when received.
The G.709 traffic parameters defined in Section 3.2 MUST be used when the label is encoded as defined in this document, and the label MUST be encoded as defined in Section 4 when these G.709 traffic parameters are used.
The NMC field MUST be set to zero when sent and should be ignored when received if an ODUk is mapped into an OTUk (not multiplexed) or at the Optical Channel layer.
The NVC field MUST be set to zero for G.709 OCh LSPs; it is only applicable for G.709 ODUk LSPs. Virtual concatenation signals MUST be of the same ODUk type.
For ODU2 into ODU3 multiplexing, 4 labels are required to identify the 4 tributary slots used by the ODU2; these tributary time slots must be allocated in ascending order.
For ODUk virtual concatenation, the ordered list of all component labels is given in the GENERALIZED_LABEL object; the number of label values is determined by the NVC value. For multiplexed virtual concatenation, NMC additionally determines the number of labels per set.
G.709 traffic parameters are carried in RSVP-TE using two new object types: G.709 SENDER_TSPEC (Class = 12, C-Type = 5) and G.709 FLOWSPEC (Class = 9, C-Type = 5). There is no Adspec associated with the G.709 SENDER_TSPEC.
New G-PID values 47-58 are defined for G.709 payloads, including G.709 ODUj (47), G.709 OTUk(v) (48), CBR/CBRa (49), CBRb (50), BSOT (51), BSNT (52), IP/PPP GFP (53), Ethernet MAC framed GFP (54), Ethernet PHY transparent GFP (55), ESCON (56), FICON (57), and Fiber Channel (58).
The NMC field (16 bits) indicates the number of ODU tributary slots used by an ODUj when multiplexed into an ODUk (k > j). For ODU2 into ODU3, NMC = 4; for all other currently defined multiplexing cases, NMC = 1.
The ODUk label space is structured as a tree: t1 (1 bit) identifies ODU1; t2 (3 bits) identifies ODU2 directly (t2=1) or an ODU1 tributary slot in ODTUG2 (t2=2..5); t3 (6 bits) identifies ODU3 directly (t3=1), ODU1 tributary slots in ODTUG3 (t3=2..17), or ODU2 tributary slots in ODTUG3 (t3=18..33). A label field equal to zero is invalid.
The Signal Type (ST) field (8 bits) indicates the G.709 Elementary Signal type: 0 = not significant, 1 = ODU1 (2.5 Gbps), 2 = ODU2 (10 Gbps), 3 = ODU3 (40 Gbps), 6 = OCh at 2.5 Gbps, 7 = OCh at 10 Gbps, 8 = OCh at 40 Gbps.
Two new LSP Encoding Type code-points are defined: value 12 for G.709 ODUk (Digital Path) and value 13 for G.709 Optical Channel. The G.709 Digital Path code-point MUST be used for G.709-compliant Digital Path layer encoding; the existing 'Digital Wrapper' code-point is reserved for non-G.709 compliant encoding.
IANA created or updated three registries under the GMPLS signaling parameters registry: LSP Encoding Type (8-bit, values 12-13 added, values 0-239 assigned via IETF Standards Track, 240-255 experimental), Switching Type (8-bit, all values via Standards Track), and Generalized PID/G-PID (16-bit, values 47-58 added, values 0-31743 via Standards Track, 31744-32767 experimental, 32768-65535 require a covering Standards Track RFC).
Two RSVP C-Types were registered: G.709 SENDER_TSPEC (Class = 12, C-Type = 5) and G.709 FLOWSPEC (Class = 9, C-Type = 5) in the RSVP parameters registry.
This document introduces no new security considerations beyond those already present in RFC 3473 (GMPLS RSVP-TE extensions).
The G.709 traffic parameters are encoded in a 96-bit (3 x 32-bit word) structure: Signal Type (8 bits), Reserved (8 bits), NMC (16 bits) in the first word; NVC (16 bits), Multiplier/MT (16 bits) in the second word; Reserved (32 bits) in the third word.
The ODUk label (Generalized Label for Digital Path layer) is a 32-bit value with fields: Reserved (22 bits), t3 (6 bits), t2 (3 bits), t1 (1 bit). Reserved bits MUST be set to zero when sent and SHOULD be ignored when received.