rfc-4606

Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control

E. Mannie, D. Papadimitriou
date2006-08 streamIETF areartg wgccamp statusPROPOSED STANDARD pages25 canonicalhttps://www.rfc-editor.org/rfc/rfc4606 doi10.17487/RFC4606 errataview
This document provides minor clarification to RFC 3946. This document is a companion to the Generalized Multi-protocol Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology-specific information needed when GMPLS signaling is used. [STANDARDS-TRACK]

obsoletes

updated by

Extracted elements (24)

design-rationale §2.1

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.

design-rationale §3

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.

design-rationale §3

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.

interoperability-note §Appendix 1

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.

interoperability-note §3

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.

interoperability-note §2.1

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.

normative-requirement §2 MUST

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.

normative-requirement §2.2 SHOULD

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.

normative-requirement §2.2 MUST

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.

normative-requirement §2.1 MUST

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.

normative-requirement §2.2 MUST

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.

normative-requirement §3 MUST NOT

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.

normative-requirement §3 MUST

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.

normative-requirement §2 MUST

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.

normative-requirement §3 MUST

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.

normative-requirement §2.1 MUST

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.

protocol-element §2.1

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.

protocol-element §2.1

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.

protocol-element §2.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.

registry §6

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.

registry

security-consideration §5

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.

security

wire-format §2.3

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.

wire-format §3

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.

wire-format §2.1

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.