Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control
obsoletes
- rfc-3946 — Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control
updated by
- rfc-6344 — Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS)
Extracted elements (24)
A dedicated signal type (value 6) is assigned to SONET STS-3c SPE rather than encoding it as contiguous concatenation of three STS-1 SPEs. This is done explicitly to provide easy interworking between SONET and SDH signaling, since VC-4 in SDH has a direct equivalent.
GMPLS virtual concatenation components must travel over the same component link if they are part of the same LSP, because labels are bound to a single component link. This is a restriction compared to the standard ANSI/ITU-T definition that allows each VCAT component to travel over diverse paths; in GMPLS, multi-path VCAT requires establishing separate LSPs that are then associated.
The SUKLM label scheme extends the ITU-T G.707 (K,L,M) numbering by prepending S and U fields to address higher-order multiplexing (STS-N/STM-N). The higher-order numbering scheme from G.707 Sections 7.3.1–7.3.6 is explicitly not used, as SUKLM provides a unified SONET/SDH label space.
The optional VC-3 via AU-3 at the end signal type (value 20) addresses LSR implementations that can only demultiplex a VC-3 received in the AU-3 branch, not the TU-3/TUG-3 branch. The penultimate LSR uses this signal type to switch an incoming VC-3 from any branch to the AU-3 branch on the outgoing interface toward the destination.
When a hierarchy of SONET/SDH LSPs is used, a higher-order LSP acts as a virtual link. Labels for lower-order LSPs within it have the S, U, K fields set to zero (non-significant), yielding the form '0,0,0,L,M'. In tunneling cases (e.g., VC-4 containing VC-3 containing VC-12) where SUKLM is insufficient, per-layer-network signaling (hierarchical LSPs) must be used.
When a SONET STS-Nc SPE with N=3*X is requested, the Elementary Signal MUST always be STS-3c SPE and NCC MUST equal X. This means contiguous concatenation of three STS-1 SPEs cannot be directly requested; it must instead be coded using the STS-3c SPE signal type to facilitate SONET/SDH interworking.
For fully transparent STS-1/STM-0 or STS-3*N/STM-N signals (all T bits would be set), the traffic parameters and label encoding defined in RFC 3471 Section 3.2 MUST be used instead of the SUKLM format.
For RSVP-TE, the FLOWSPEC object contents received in a Resv SHOULD be identical to the SENDER_TSPEC contents in the corresponding Path message. If they do not match, a ResvErr 'Traffic Control Error/Bad Flowspec value' SHOULD be generated.
Intermediate and egress nodes MUST verify support for the requested Signal Type, RCC, NCC, NVC, and Multiplier. If unsupported, the receiver node MUST generate a PathErr 'Traffic Control Error/Service unsupported' (RSVP-TE) or NOTIFICATION 'Resource Unavailable' (CR-LDP) message.
Intermediate and egress nodes MUST verify that themselves and the LSP interfaces can support the requested Multiplier value. If the MT field is received with a zero value, the node MUST generate a PathErr (RSVP-TE) or NOTIFICATION (CR-LDP) message.
Intermediate nodes MUST verify that the node and interfaces can support the requested Transparency flags. If the requested flags cannot be supported, the receiver node MUST generate a PathErr or NOTIFICATION message as appropriate.
M field values 1 and 2 (indicating VT3 SPE) MUST NOT be used for SDH, as there is no SDH equivalent of the VT3 signal.
The SUKLM label format MUST be used for any SONET/SDH signal request that is not transparent (i.e., when all Transparency bits are zero). Any transparent STS-1/STM-0/STS-3*N/STM-N signal request MUST use the label format defined in RFC 3471.
The traffic parameters defined in Section 2.1 MUST be used when the label is encoded as SUKLM (Section 3) and MUST also be used when requesting Section/RS or Line/MS overhead transparent STS-1/STM-0 or STS-3*N/STM-N signals.
When a SUKLM label field is not significant or ignored in a particular context, it MUST be set to zero when transmitted and ignored when received.
When Section/Regenerator Section layer transparency (Flag 1) is used, all other Transparency flags MUST be ignored. This is because full Section transparency implies the entire frame is delivered unmodified.
The Multiplier (MT) field (16 bits) indicates the number of identical Final Signals in the LSP. Default is 1; zero is an invalid value. When multiplying virtually concatenated signals, the ordered list of label sets in the Generalized Label object identifies each component group.
The Signal Type (ST) field (8 bits) identifies the Elementary Signal constituting the LSP. Twelve standard values are defined: values 1–6 cover VT1.5/VC-11 through STS-3c SPE/VC-4 SPE-based signals, and values 7–12 cover STS-1/STM-0 through STS-768/STM-256 for use only when transparency is requested. An optional value 20 (VC-3 via AU-3 at the end) is defined in Appendix 1.
The Transparency (T) field (32 bits) is a flag vector indicating overhead transparency: Flag 1 (bit 1) requests Section/Regenerator Section layer transparency (entire frames delivered unmodified, pointers cannot be adjusted), and Flag 2 (bit 2) requests Line/Multiplex Section layer transparency (LOH/MSOH delivered unmodified). Transparency applies only to STS-1/STM-0 and STS-3*N/STM-N signal types.
Two RSVP-TE C-Types in the IANA RSVP Parameters registry apply to this document: SONET/SDH SENDER_TSPEC object (Class 12, C-Type 4) and SONET/SDH FLOWSPEC object (Class 9, C-Type 4). One LDP TLV Type (0x0838) in the IANA LDP Namespaces registry is assigned for the SONET/SDH Traffic Parameters TLV.
This document introduces no new security considerations beyond those of RFC 3473 (RSVP-TE) or RFC 3472 (CR-LDP). GMPLS security is described in RFC 3471 Section 11, which refers to RFC 3209 for RSVP-TE security and RFC 3212 for CR-LDP security.
The CR-LDP SONET/SDH Traffic Parameters TLV header is a 32-bit field with U bit, F bit, Type field (0x0838), and Length field. The TLV content follows the format defined in Section 2.1.
The SONET/SDH SUKLM label is a 32-bit value: S (16 bits, index of STS-3/AUG-1 within STS-N/STM-N), U (4 bits, index of STS-1 SPE/VC-3 within STS-3/AUG-1), K (4 bits, index of TUG-3 within VC-4), L (4 bits, index of VT Group/TUG-2), M (4 bits, index of specific VT/VC within group). Zero indicates non-significant or ignored field.
The SONET/SDH traffic parameters are a 128-bit structure: Signal Type (8 bits), RCC/Requested Contiguous Concatenation (8 bits), NCC/Number of Contiguous Components (16 bits), NVC/Number of Virtual Components (16 bits), Multiplier/MT (16 bits), Transparency/T (32 bits), and Profile/P (32 bits). This format is carried in RSVP-TE SENDER_TSPEC/FLOWSPEC objects or the CR-LDP SONET/SDH Traffic Parameters TLV.