Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control
obsoleted by
- rfc-4606 — Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control
Extracted elements (27)
A dedicated signal type (value 6) is assigned to STS-3c SPE rather than coding it as contiguous concatenation of three STS-1 SPEs. This simplifies interworking between SONET and SDH signaling by providing a single canonical representation shared by both hierarchies (STS-3c SPE = VC-4).
The optional 'VC-3 via AU-3 at the end' signal type (value 20, Appendix 1) was introduced to accommodate LSRs that can only demultiplex a VC-3 received via the AU-3 branch, not the TU-3/TUG-3/VC-4/AU-4 branch, due to hardware switching fabric constraints. This allows the penultimate LSR to switch the VC-3 to the required branch before delivery.
Transforms on the Elementary Signal must be applied in a strict order: (1) contiguous concatenation via RCC/NCC, (2) virtual concatenation via NVC, (3) transparency via T, (4) multiplication via MT. This ordering prevents ambiguous interpretations of combined transform parameters.
When requesting STS-Nc SPE with N divisible by 3, the specification mandates using STS-3c_SPE as the Elementary Signal with NCC=N/3, prohibiting direct expression of STS-3*X-via-STS-1 contiguous concatenation. This encoding choice facilitates SONET/SDH interworking by aligning with SDH's VC-4-Nc notation.
Within GMPLS, virtual concatenation components must travel over the same component link if they belong to the same LSP, because labels are bound to a component link. This is more restrictive than ANSI T1.105/ITU-T G.707, which allow components on diverse paths. Routing components on different paths within GMPLS requires establishing separate LSPs that are then associated together.
A SONET/SDH label is context-sensitive: it does not by itself identify which signal class is being used. The signal class is implicitly determined by the link on which the label is used, in combination with the traffic parameters. Implementations must interpret labels only in conjunction with the associated SONET/SDH traffic parameters.
For RSVP-TE, the contents of the FLOWSPEC object received in a Resv message SHOULD be identical to 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.
Intermediate and egress nodes MUST verify that the node and its interfaces can support the requested Transparency flags. If not, the node MUST generate a PathErr message with 'Traffic Control Error/Service unsupported' (RSVP-TE) or a NOTIFICATION with 'Resource Unavailable' (CR-LDP). Section/RS layer transparency implies all other transparency flags MUST be ignored.
M=1..2 indicates a VT3 SPE inside a VT Group; these values MUST NOT be used for SDH since there is no SDH equivalent of VT3. M=3..5 indicates VT2_SPE/VC-12, and M=6..9 indicates VT1.5_SPE/VC-11 within the VT_Group/TUG-2.
The Profile (P) field (32 bits) is intended for future capability signaling (e.g., monitoring). No standard profile is currently defined; this field SHOULD be set to zero when transmitted and SHOULD be ignored when received.
The SONET/SDH traffic parameters defined in Section 2.1 MUST be used when the label is encoded as SUKLM or when requesting Section/RS or Line/MS overhead transparent STS-1/STM-0 or STS-3*N/STM-N signals. The traffic parameters and label encoding from RFC 3471 Section 3.2 MUST be used for fully transparent signals (all overhead left unmodified).
The SUKLM label format MUST be used for any SONET/SDH signal request that is not transparent (i.e., 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.
When a label field is not significant or ignored in a particular context, it MUST be set to zero when transmitted and MUST be ignored when received. This applies to, for example, S and U fields for STS-1/STM-0 signals, and K for non-VC-4 signals.
For contiguous concatenation, only one label appears in the Generalized Label field, identifying the lowest time-slot (lowest integer value) occupied by the concatenated signal — the time-slot of the first component encountered descending the multiplexing tree. For virtual concatenation, an explicit ordered list of all labels is given, where order reflects payload order, not physical time-slot order.
For CR-LDP, SONET/SDH traffic parameters are carried in the SONET/SDH Traffic Parameters TLV with type field 0x0838. The TLV header uses the standard CR-LDP format with U/F bits followed by type and length fields.
For multiplication (MT > 1) of virtually concatenated signals, the Generalized Label contains ordered sets of labels: the first set describes the time-slots of the first virtually concatenated signal, the second set describes the second, and so on. All labels for both multiplication and virtual concatenation must reside within a single component link.
For RSVP-TE, SONET/SDH traffic parameters are carried in SENDER_TSPEC (Class=12, C-Type=4) and FLOWSPEC (Class=9, C-Type=4) objects using identical format. There is no Adspec associated with the SONET/SDH SENDER_TSPEC; either the Adspec is omitted or an int-serv Adspec with Default General Characterization Parameters is used per RFC 2210.
The Number of Contiguous Components (NCC) field (16 bits) specifies how many identical Elementary Signal SPEs/VCs are to be contiguously concatenated as requested by RCC. When requesting STS-Nc SPE with N=3*X, the Elementary Signal must be STS-3c_SPE and NCC must equal X; this prohibits coding contiguous concatenation of three STS-1 SPEs directly. NCC must be zero when RCC is zero.
The Number of Virtual Components (NVC) field (16 bits) indicates the number of signals to be virtually concatenated. These signals are all of the same Elementary Signal type (VT1.5_SPE/VC-11, VT2_SPE/VC-12, VT3_SPE, VT6_SPE/VC-2, STS-1_SPE/VC-3, or STS-3c_SPE/VC-4). A value of 0 means no virtual concatenation is requested.
The Requested Contiguous Concatenation (RCC) field (8 bits) is a flag vector indicating which contiguous concatenation types the upstream node supports. Flag 1 (bit 1) indicates standard SONET/SDH contiguous concatenation per T1.105/G.707. Setting the entire field to zero means no contiguous concatenation is requested. A downstream node that cannot support any indicated type MUST refuse the LSP request.
The Signal Type (ST) field (8 bits) identifies the Elementary Signal for an LSP. Twelve values are defined: VT1.5 SPE/VC-11 (1), VT2 SPE/VC-12 (2), VT3 SPE (3), VT6 SPE/VC-2 (4), STS-1 SPE/VC-3 (5), STS-3c SPE/VC-4 (6), and transparency-only signals STS-1/STM-0 through STS-768/STM-256 (7–12). Successive transforms (contiguous concatenation, virtual concatenation, transparency, multiplication) are applied to the Elementary Signal to produce the Final Signal.
The Transparency (T) field (32 bits) is a flag vector specifying which SONET/SDH frame overhead fields must be delivered unmodified end-to-end. Flag 1 (bit 1) requests Section/Regenerator Section layer transparency (entire frames pass unmodified; pointer adjustment is prohibited). Flag 2 (bit 2) requests Line/Multiplex Section transparency (LOH/MSOH unmodified; pointer adjustment prohibited). Transparency applies only to signal types STS-1/STM-0 through STS-768/STM-256.
When a hierarchy of SONET/SDH LSPs is used, a higher-order LSP acts as a virtual link carrying lower-order LSPs. Labels for lower-order LSPs on such a virtual link set the higher-order fields (S, U, K) to zero (non-significant), using only L and M to identify the signal within the higher-order container. Tunneling deeper than SUKLM can represent requires per-layer-network signaling.
IANA registered three values for this document: two RSVP C-Types (SONET/SDH SENDER_TSPEC: Class=12, C-Type=4; SONET/SDH FLOWSPEC: Class=9, C-Type=4) in the RSVP parameters registry, and one LDP TLV Type (0x0838 for the SONET/SDH Traffic Parameters TLV) in the LDP namespaces registry.
This document introduces no new security considerations beyond those in 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 SONET/SDH label (SUKLM format) is a 32-bit field: 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), and M (4 bits, index of specific VT or VC signal within VT_Group/TUG-2). Fields use 1-based indexing; zero indicates non-significant or ignored.
The SONET/SDH Traffic Parameters block is 128 bits organized as four 32-bit words: Signal Type (8 bits), RCC (8 bits), NCC (16 bits), NVC (16 bits), Multiplier/MT (16 bits), Transparency/T (32 bits), and Profile/P (32 bits). This structure is used identically in RSVP-TE SENDER_TSPEC/FLOWSPEC objects and CR-LDP TLVs.