RFC 4606
Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control
RFC 4606 🎀 Title Block Tea
Okay bestie, this one is a Standards Track doc from the Network Working Group ✨ It was written by E. Mannie (Perceval) and D. Papadimitriou (Alcatel), and it's dated August 2006. It obsoletes RFC 3946 💅, and its whole job is to clarify GMPLS signaling for SONET and SDH 🦋
Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control
Status of This Memo 📜
This doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💖 If you want to know where this protocol stands, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈
Copyright Notice ©️
Copyright (C) The Internet Society (2006).
Abstract 🦋
This document provides minor clarification to RFC 3946.
It's 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 you need when GMPLS signaling is used ✨
Table of Contents 🗂️
1. Introduction ....................................................2
2. SONET and SDH Traffic Parameters ................................3
2.1. SONET/SDH Traffic Parameters ...............................3
2.2. RSVP-TE Details ............................................9
2.3. CR-LDP Details ............................................10
3. SONET and SDH Labels ...........................................11
4. Acknowledgements ...............................................16
5. Security Considerations ........................................16
6. IANA Considerations ............................................16
Contributors ......................................................17
Appendix 1. Signal Type Values Extension for VC-3 .................20
Annex 1. Examples .................................................20
Normative References ..............................................231. Introduction 🌸
Okay so, as described in [RFC3945], Generalized MPLS (GMPLS) takes MPLS, which was only about packet interfaces (Packet Switching Capable, or PSC), and expands it to cover four brand new classes of interfaces and switching 🤯 Those are Layer-2 Switch Capable (L2SC), Time-Division Multiplex (TDM), Lambda Switch Capable (LSC) and Fiber-Switch Capable (FSC) 🔥 A functional description of the MPLS signaling extensions needed for those new classes is in [RFC3471]. [RFC3473] covers the RSVP-TE-specific formats and mechanisms needed to support all five classes of interfaces, and the CR-LDP extensions live in [RFC3472] 🧚
This document gets into the details that are specific to Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) 💅 As [RFC3471] says, SONET/SDH-specific parameters get carried in the signaling protocol inside traffic parameter specific objects ✨
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🫶
Also, the reader is assumed to already know the terminology in American National Standards Institute (ANSI) [T1.105] and ITU-T [G.707], plus the terms in [RFC3471], [RFC3472], and [RFC3473] 📚 Here are the abbreviations used in this document:
- DCC: Data Communications Channel.
- LOVC: Lower-Order Virtual Container
- HOVC: Higher-Order Virtual Container
- MS: Multiplex Section.
- MSOH: Multiplex Section overhead.
- POH: Path overhead.
- RS: Regenerator Section.
- RSOH: Regenerator Section overhead.
- SDH: Synchronous digital hierarchy.
- SOH: Section overhead.
- SONET: Synchronous Optical Network.
- SPE: Synchronous Payload Envelope.
- STM(-N): Synchronous Transport Module (-N) (SDH).
- STS(-N): Synchronous Transport Signal-Level N (SONET).
- VC-n: Virtual Container-n (SDH).
- VTn: Virtual Tributary-n (SONET).
2. SONET and SDH Traffic Parameters 💖
This section defines the GMPLS traffic parameters for SONET/SDH 🎀 The protocol-specific formats for the SONET/SDH-specific RSVP-TE objects and CR-LDP TLVs are described in Sections 2.2 and 2.3, respectively 🦋
These traffic parameters set up a base set of capabilities for SONET ANSI [T1.105] and SDH ITU-T [G.707], like concatenation and transparency 🌈 Other documents might level this set up in the future. For example, signaling for SDH over PDH ITU-T G.832 or sub-STM-0 ITU-T G.708 interfaces could get defined 👑
The traffic parameters defined hereafter (see Section 2.1) MUST be used when the label is encoded as SUKLM as defined in this memo (see Section 3). They MUST also be used when requesting one of Section/RS or Line/MS overhead transparent STS-1/STM-0, STS-3*N/STM-N (N=1, 4, 16, 64, 256) signals 💅
The traffic parameters and label encoding defined in [RFC3471], Section 3.2, MUST be used for fully transparent STS-1/STM-0, STS-3*N/STM-N (N=1, 4, 16, 64, 256) signal requests. A fully transparent signal is one where all overhead is left unmodified by intermediate nodes 🫧 In other words, all the defined Transparency (T) bits would be set if the traffic parameters from Section 2.1 were used 🔥
2.1. SONET/SDH Traffic Parameters ✨
The traffic parameters for SONET/SDH are organized like this 🍓
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | RCC | NCC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NVC | Multiplier (MT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transparency (T) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Profile (P) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Annex 1 has examples of SONET and SDH signal coding 📖
o) Signal Type (ST): 8 bits
This field tells you the type of Elementary Signal that makes up the requested Label Switched Path (LSP) 🎀 Several transforms can be applied one after another to the Elementary Signal to build the Final Signal that's actually requested for the LSP 🧩
Each transform application is optional and must be ignored if zero, except for the Multiplier (MT), which cannot be zero and is ignored if equal to one 💀
Transforms must be applied strictly in this order:
- First, contiguous concatenation (by using the RCC and NCC fields) can be optionally applied on the Elementary Signal, resulting in a contiguously concatenated signal.
- Second, virtual concatenation (by using the NVC field) can be optionally applied on the Elementary Signal, resulting in a virtually concatenated signal.
- Third, some transparency (by using the Transparency field) can be optionally specified when a frame is requested as signal rather than an SPE- or VC-based signal.
- Fourth, a multiplication (by using the Multiplier field) can be optionally applied directly on the Elementary Signal, on the contiguously concatenated signal obtained from the first phase, on the virtually concatenated signal obtained from the second phase, or on these signals combined with some transparency.
Permitted Signal Type values for SONET/SDH are 🌸
Value Type (Elementary Signal)
----- ------------------------
1 VT1.5 SPE / VC-11
2 VT2 SPE / VC-12
3 VT3 SPE
4 VT6 SPE / VC-2
5 STS-1 SPE / VC-3
6 STS-3c SPE / VC-4
7 STS-1 / STM-0 (only when transparency is requested)
8 STS-3 / STM-1 (only when transparency is requested)
9 STS-12 / STM-4 (only when transparency is requested)
10 STS-48 / STM-16 (only when transparency is requested)
11 STS-192 / STM-64 (only when transparency is requested)
12 STS-768 / STM-256 (only when transparency is requested)A dedicated signal type is given to a SONET STS-3c SPE, instead of being coded as a contiguous concatenation of three STS-1 SPEs 🧚 This is done to make interworking between SONET and SDH signaling easy 🫶
Appendix 1 adds one signal type (optional) to the values above 🌈
o) Requested Contiguous Concatenation (RCC): 8 bits
This field is used to request the optional SONET/SDH contiguous concatenation of the Elementary Signal 💖
This field is a vector of flags. Each flag shows support for one particular type of contiguous concatenation. Several flags can be set at once to offer a choice 🦋
These flags let an upstream node tell a downstream node which types of contiguous concatenation it supports. The downstream node decides which one to use, though, according to its own rules 👑
A downstream node that gets more than one flag at once picks one particular type of contiguous concatenation, if it supports any, using criteria that are out of this document's scope 🔥 A downstream node that doesn't support any of the concatenation types the field indicates must refuse the LSP request. Specifically, it must refuse the LSP request if it doesn't support contiguous concatenation at all 💀
When several flags are set, the upstream node finds the single type of contiguous concatenation the downstream node picked by looking at the position given by the first label and the number of labels the downstream node returned (see also Section 3) 🔍
The entire field is set to zero to show that no contiguous concatenation is requested at all (the default value). A non-zero field means some contiguous concatenation is requested ✨
The following flag is defined:
- Flag 1 (bit 1): Standard contiguous concatenation.
Flag 1 means the standard SONET/SDH contiguous concatenation, as defined in [T1.105]/[G.707], is supported. Heads up: bit 1 is the low-order bit 🙈 Other flags are reserved for extensions. If they aren't used, they must be set to zero when sent, and should be ignored when received 🫧
See note 1 in the NCC section about the SONET contiguous concatenation of STS-1 SPEs when the number of components is a multiple of three 💅
o) Number of Contiguous Components (NCC): 16 bits
This field shows how many identical SONET SPEs/SDH VCs (i.e., Elementary Signal) are requested to be concatenated, as specified in the RCC field 🌸
Note 1: When a SONET STS-Nc SPE with N=3*X is requested, the Elementary Signal to be used must always be an STS-3c_SPE signal type, and the value of NCC must always be equal to X. This makes interworking between SONET and SDH easier. In particular, it means the contiguous concatenation of three STS-1 SPEs can't be requested, because under this spec that signal must be coded using the STS-3c SPE signal type 🙅♀️
Note 2: When a transparent STS-N/STM-N signal is requested that's limited to a single contiguously concatenated STS-Nc_SPE/VC-4-Nc, the signal type must be STS-N/STM-N, with RCC flag 1 set and NCC set to 1 🦋
The NCC value must be consistent with the type of contiguous concatenation you request in the RCC field. ✨ This field is irrelevant if you don't request contiguous concatenation (RCC = 0). In that case, set it to zero when sending and ignore it when receiving. 🫶 An RCC value other than 0 means at least 1 contiguous component.
Note 3: following these rules, when you request a VC-4 signal, the RCC and the NCC values SHOULD be set to 0 💅, whereas for an STS-3c SPE signal, they SHOULD be set to 1. 🎀 But if local conditions allow, the requesting upstream node MAY set the RCC and NCC values to either SDH or SONET settings, and it won't change how things work, because the setting is locally driven. 🦋 The downstream node SHOULD also accept the requested values if local conditions allow. 💖 If those values can't be supported, the receiver downstream node SHOULD generate a PathErr/NOTIFICATION message (see Sections 2.2 and 2.3, respectively). 😭
o) Number of Virtual Components (NVC): 16 bits 🌸
This field tells you how many signals are requested to be virtually concatenated. ✨ They're all the same type by definition. They're Elementary Signal SPEs/VCs with signal types defined in this document, i.e., 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. 🧚
This field is set to 0 (default value) to mean no virtual concatenation is requested. 🍓
o) Multiplier (MT): 16 bits 👑
This field tells you how many identical signals are requested for the LSP, i.e., the ones that form the Final Signal. 🔥 They can be identical Elementary Signals, identical contiguously concatenated signals, or identical virtually concatenated signals. Note that all of them belong to the same LSP. 💜
The components of multiple virtually concatenated signals are told apart by the order of the labels in the signaling. 🌈 The first set of labels must describe the first component (the set of individual signals belonging to the first virtually concatenated signal), the second set must describe the second component, and so on. 🦋
This field is set to one (default value) to mean exactly one instance of a signal is being requested. Intermediate and egress nodes MUST verify that the node itself and the interfaces where the LSP will be established can support the requested multiplier value. 🫶 If those values can't be supported, the receiver node MUST generate a PathErr/NOTIFICATION message (see Sections 2.2 and 2.3, respectively). 💀
Zero is an invalid value. If a zero is received, the node MUST generate a PathErr/NOTIFICATION message (see Sections 2.2 and 2.3, respectively). 🙈
Note 1: when a transparent STS-N/STM-N signal is requested that's limited to a single contiguously concatenated STS-Nc-SPE/VC-4-Nc, the multiplier field MUST be equal to 1 (the only valid value). ✨
o) Transparency (T): 32 bits 🌸
This field is a vector of flags that says what kind of transparency is requested. 💅 You can combine several flags to get different types of transparency, but not every combination is necessarily valid. The default is zero, meaning no transparency is requested. 🎀
From the point of view of this signaling spec, transparency only applies to the fields in the SONET/SDH frame overheads. 🦋 In SONET, those are the fields in the Section Overhead (SOH) and the Line Overhead (LOH). In SDH, they're the fields in the Regenerator Section Overhead (RSOH), the Multiplex Section overhead (MSOH), and the pointer fields between the two. 🧚 With SONET, the pointer fields are part of the LOH. 💖
Transparency only applies when these signal types are used: STS-1/STM-0, STS-3/STM-1, STS-12/STM-4, STS-48/STM-16, STS-192/STM-64, and STS-768/STM-256. At least one transparency type must be specified when one of those signal types is requested. 🔥
Transparency says exactly which fields in those overheads must be delivered unmodified at the other end of the LSP. 👑 An ingress Label Switching Router (LSR) that requests transparency passes those overhead fields through to the egress LSR without any change. 🫶 From the point of view of the ingress and egress LSRs, those fields must look unmodified. 🌈
Transparency is not applied at the interfaces with the initiating and terminating LSRs. It's only applied between intermediate LSRs. 🦋 The transparency field is used to request an LSP that supports the requested transparency type, and it can also be used to set up the transparency process applied at each intermediate LSR. 💜
The different transparency flags are:
Flag 1 (bit 1): Section/Regenerator Section layerFlag 2 (bit 2): Line/Multiplex Section layer
Bit 1 is the low-order bit. 🍓 Other flags are reserved. They should be set to zero when sent and ignored when received. ✨ A flag is set to one to request the matching transparency. 🎀
Intermediate and egress nodes MUST verify that the node itself and the interfaces where the LSP will be established can support the requested transparency. 💅 If the requested flags can't be supported, the receiver node MUST generate a PathErr/NOTIFICATION message (see Sections 2.2 and 2.3, respectively). 😭
Section/Regenerator Section layer transparency means the entire frames must be delivered unmodified. 🧚 That means pointers can't be adjusted. When Section/Regenerator Section layer transparency is used, all other flags MUST be ignored. 🙈
Line/Multiplex Section layer transparency means the LOH/MSOH must be delivered unmodified. 🌸 That means pointers can't be adjusted either. 🔥
o) Profile (P): 32 bits 💜
This field is meant to indicate particular capabilities that must be supported for the LSP, for example, monitoring capabilities. 🦋
No standard profile is defined yet, so this field SHOULD be set to zero when transmitted and ignored when received. 🫶
In the future, TLV-based extensions may be created. 👑
2.2. RSVP-TE Details ✨
For RSVP-TE, the SONET/SDH traffic parameters are carried in the SONET/SDH SENDER_TSPEC and FLOWSPEC objects. 💖 Both objects use the same format. The content is defined above, in Section 2.1. 🌈 These objects have the following class and type for SONET ANSI T1.105 and SDH ITU-T G.707:
SONET/SDH SENDER_TSPEC object: Class = 12, C-Type = 4
SONET/SDH FLOWSPEC object: Class = 9, C-Type = 4There's no Adspec tied to the SONET/SDH SENDER_TSPEC. 🎀 Either the Adspec is omitted, or an int-serv Adspec with the Default General Characterization Parameters and Guaranteed Service fragment is used; see [RFC2210]. 🧚
For a particular sender in a session, the FLOWSPEC object received in a Resv message SHOULD be identical to the SENDER_TSPEC object received in the matching Path message. 🔥 If they don't match, a ResvErr message with a "Traffic Control Error/Bad Flowspec value" error SHOULD be generated. 💀
Intermediate and egress nodes MUST verify that the node itself and the interfaces where the LSP will be established can support the requested Signal Type, RCC, NCC, NVC and Multiplier (as defined in Section 2.1). ✨ If the requested values can't be supported, the receiver node MUST generate a PathErr message with a "Traffic Control Error/ Service unsupported" indication (see [RFC2205]). 😭
Also, if the MT field is received with a zero value, the node MUST generate a PathErr message with a "Traffic Control Error/Bad Tspec value" indication (see [RFC2205]). 🙈
Intermediate nodes MUST also verify that the node itself and the interfaces where the LSP will be established can support the requested Transparency (as defined in Section 2.1). 🌸 If the requested values can't be supported, the receiver node MUST generate a PathErr message with a "Traffic Control Error/Service unsupported" indication (see [RFC2205]). 💅
2.3. CR-LDP Details 🦋
For CR-LDP, the SONET/SDH traffic parameters are carried in the SONET/SDH Traffic Parameters TLV. 🫶 The content of the TLV is defined above, in Section 2.1. 👑 The TLV header has this format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The type field for the SONET/SDH Traffic Parameters TLV is 0x0838. 🌈
Intermediate and egress nodes MUST verify that the node itself and the interfaces where the LSP will be established can support the requested Signal Type, RCC, NCC, NVC, and Multiplier (as defined in Section 2.1). 🔥 If the requested values can't be supported, the receiver node MUST generate a NOTIFICATION message with a "Resource Unavailable" status code (see [RFC3212]). 💖
Also, if the MT field is received with a zero value, the node MUST generate a NOTIFICATION message with a "Resource Unavailable" status code (see [RFC3212]). 🧚
Intermediate nodes MUST also verify that the node itself and the interfaces where the LSP will be established can support the requested Transparency (as defined in Section 2.1). 🦋 If the requested values can't be supported, the receiver node MUST generate a NOTIFICATION message with a "Resource Unavailable" status code (see [RFC3212]). 💜
3. SONET and SDH Labels 🎀
SONET and SDH each define a multiplexing structure. 🌸 Both are trees. Their roots are an STS-N or an STM-N, and their leaves are the signals that can be carried in the time-slots and switched between time-slots within an ingress port and time-slots within an egress port, i.e., a VTx SPE, an STS-x SPE, or a VC-x. ✨ A SONET/SDH label identifies the exact position (i.e., first time-slot) of a particular VTx SPE, STS-x SPE, or VC-x signal in a multiplexing structure. 👑 SONET and SDH labels are carried in the Generalized Label per [RFC3473] and [RFC3472]. 🫶
Time-slots here means the time-slots as they logically and sequentially appear in the multiplex, not as they look after any possible interleaving. 💅
These multiplexing structures act as naming trees to create unique multiplex entry names or labels. 🦋 SONET and SDH use the same label format. As explained in [RFC3471], a label doesn't identify the "class" it belongs to. That's implicitly decided by the link where the label is used. 🌈
When there's signal concatenation or multiplication, a list of labels can appear in the Label field of a Generalized Label. 🧚 💖
In case of contiguous concatenation, only one label shows up in the Label field. ✨ That one label gets packed into a single 32-bit value inside the Generalized Label object (Class-Num = 16, C-Type = 2)/TLV (0x0825). It points at the lowest time-slot the contiguously concatenated signal takes up. "Lowest" means lowest label as an integer value, so it's the slot of the first component signal you hit going down the tree. 🌳💖
In case of virtual concatenation, you list out every label in the concatenation, in order. 🎀 Each 32-bit label goes in the same Generalized Label object (Class-Num = 16, C-Type = 2)/TLV (0x0825), and each one marks the first time-slot of one component of the virtually concatenated signal. The order has to match the order of the payloads you're concatenating, NOT the physical order of the time-slots. Okay, real talk, this is a limitation: virtual concatenation has to stay inside a single (component) link. That's different from the ANSI [T1.105]/ ITU-T [G.707] recommendations, where each virtual concatenation component can take a diverse path. In GMPLS, the components must travel over the same (component) link if they belong to the same LSP, because of how labels get bound to a (component) link. 🫶 BUT, if you route components along different paths, that's just establishing different LSPs that each have their own route. Several LSPs can start and end between the same nodes, and their components can then be associated together (aka virtually concatenated). Lowkey clever! 🧚
In case of multiplication (using the multiplier transform), you give the explicit ordered list of all labels that take part in the Final Signal. ✨ That list is encoded as a sequence of 32-bit label values in the same Generalized Label object (Class-Num = 16, C-Type = 2)/TLV (0x0825). When you multiply virtually concatenated signals, it gets a little more layered: the first set of labels is the time-slots for the first virtually concatenated signal, the second set is for the second one, and so on. 🌈 Multiplication is also limited to a single (component) link. Periodt. 💅
The format of the label for a SONET and/or SDH TDM-LSR link looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S | U | K | L | M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+This is an extension of the numbering scheme from [G.707], Sections 7.3.7 through 7.3.13, which is the (K, L, M) numbering. 💜 The higher order numbering scheme in [G.707], Sections 7.3.1 through 7.3.6, is NOT used here. (Ignore my caps, that's just me being dramatic. The original text says "is not used here," so that's all I'm saying!) 🙈
Each letter is a possible branch number, counted from the parent node in the multiplex structure. Branches are numbered in increasing order, starting from the top of the multiplexing structure. Numbering starts at 1, and 0 means the field is non-significant or ignored. 🍓
When a field is not significant or ignored in a particular context, it MUST be set to zero when transmitted and ignored when received. This one's a hard rule, bestie. 🔥
When you have a hierarchy of SONET/SDH LSPs, a higher-order LSP with a given bandwidth can carry lower-order LSPs. 🦋 A higher-order LSP gets established through a SONET/SDH higher-order path layer network, and a lower-order LSP through a SONET/SDH lower-order path layer network (see also ITU-T G.803, Section 3, for the matching definitions). In this setup, the higher-order SONET/SDH LSP acts like a "virtual link" with a given bandwidth (e.g., VC-3). It can also be used as a Forwarding Adjacency. A lower-order SONET/SDH LSP can be set up through that higher-order LSP. ✨ A label is local to a (virtual) link, so the highest part of the label (the S, U, and K fields) is non-significant and set to zero. That makes the label "0,0,0,L,M". Same vibe the other way: if the structure of the lower-order LSP is unknown or doesn't matter, the lowest part of the label (the L and M fields) is non-significant and set to zero, so the label is "S,U,K,0,0". 🌸
For example, a VC-3 LSP can carry lower-order LSPs. In that case, the labels allocated between the two ends of the VC-3 LSP for those lower-order LSPs have S, U, and K set to zero (non-significant), while L and M are used to show the signal allocated inside that VC-3. 🧁
Tunneling, like VC-4 containing VC-3 containing VC-12/VC-11, is a different story. The SUKLM structure isn't enough to represent the full signal structure there, so you have to use a hierarchical approach, meaning per layer network signaling. 🌀
The possible values of S, U, K, L, and M are defined like this:
S=1->Nis the index of a particular STS-3/AUG-1 inside an STS-N/STM-N multiplex.Sonly matters for SONET STS-N (N>1) and SDH STM-N (N>0).Smust be 0 and ignored for STS-1 and STM-0. 💅U=1->3is the index of a particular STS-1_SPE/VC-3 within an STS-3/AUG-1.Uonly matters for SONET STS-N (N>1) and SDH STM-N (N>0).Umust be 0 and ignored for STS-1 and STM-0. 🎀K=1->3is the index of a particular TUG-3 within a VC-4.Konly matters for an SDH VC-4 structured in TUG-3s.Kmust be 0 and ignored in all other cases. 🌟L=1->7is the index of a particular VT_Group/TUG-2 within an STS-1_SPE/TUG-3 or VC-3.Lmust be 0 and ignored in all other cases. 🍒Mis the index of a particular VT1.5_SPE/VC-11, VT2_SPE/VC-12, or VT3_SPE within a VT_Group/TUG-2.M=1->2indicates a specific VT3 SPE inside the matching VT Group. These values MUST NOT be used for SDH, since SDH has no equivalent of VT3.M=3->5indicates a specific VT2_SPE/VC-12 inside the matching VT_Group/TUG-2.M=6->9indicates a specific VT1.5_SPE/VC-11 inside the matching VT_Group/TUG-2. 🧚♀️
One thing to keep in mind: a label always has to be read according to the SONET/SDH traffic parameters. A label on its own won't tell you which signal is being requested, because labels are context sensitive. 🤔
The label format from this section, called SUKLM, MUST be used for any SONET/SDH signal request that is NOT transparent. (Sorry, I keep yelling. The original says MUST, so MUST it is!) Non-transparent means all Transparency (T) bits defined in Section 2.1 are set to zero. Any transparent STS-1/STM-0/STS-3*N/STM-N (N=1, 4, 16, 64, 256) signal request MUST use a label format defined in [RFC3471]. 🔥
The S encoding looks like this:
S SDH SONET
------------------------------------------------
0 other other
1 1st AUG-1 1st STS-3
2 2nd AUG-1 2nd STS-3
3 3rd AUG-1 3rd STS-3
4 4rd AUG-1 4rd STS-3
: : :
N Nth AUG-1 Nth STS-3The U encoding looks like this:
U SDH AUG-1 SONET STS-3
-------------------------------------------------
0 other other
1 1st VC-3 1st STS-1 SPE
2 2nd VC-3 2nd STS-1 SPE
3 3rd VC-3 3rd STS-1 SPEThe K encoding looks like this:
K SDH VC-4
---------------
0 other
1 1st TUG-3
2 2nd TUG-3
3 3rd TUG-3The L encoding looks like this:
L SDH TUG-3 SDH VC-3 SONET STS-1 SPE
-------------------------------------------------
0 other other other
1 1st TUG-2 1st TUG-2 1st VTG
2 2nd TUG-2 2nd TUG-2 2nd VTG
3 3rd TUG-2 3rd TUG-2 3rd VTG
4 4th TUG-2 4th TUG-2 4th VTG
5 5th TUG-2 5th TUG-2 5th VTG
6 6th TUG-2 6th TUG-2 6th VTG
7 7th TUG-2 7th TUG-2 7th VTGThe M encoding looks like this:
M SDH TUG-2 SONET VTG
-------------------------------------------------
0 other other
1 - 1st VT3 SPE
2 - 2nd VT3 SPE
3 1st VC-12 1st VT2 SPE
4 2nd VC-12 2nd VT2 SPE
5 3rd VC-12 3rd VT2 SPE
6 1st VC-11 1st VT1.5 SPE
7 2nd VC-11 2nd VT1.5 SPE
8 3rd VC-11 3rd VT1.5 SPE
9 4th VC-11 4th VT1.5 SPEExamples of Labels 🎀
Here are some examples, so you can see how it all clicks:
Example 1: the label for the STS-3c_SPE/VC-4 in the Sth
STS-3/AUG-1 is: S>0, U=0, K=0, L=0, M=0.
Example 2: the label for the VC-3 within the Kth-1 TUG-3 within
the VC-4 in the Sth AUG-1 is: S>0, U=0, K>0, L=0, M=0.
Example 3: the label for the Uth-1 STS-1_SPE/VC-3 within the Sth
STS-3/AUG-1 is: S>0, U>0, K=0, L=0, M=0.
Example 4: the label for the VT6/VC-2 in the Lth-1 VT Group/TUG-2
in the Uth-1 STS-1_SPE/VC-3 within the Sth STS-3/AUG-1
is: S>0, U>0, K=0, L>0, M=0.
Example 5: the label for the 3rd VT1.5_SPE/VC-11 in the Lth-1 VT
Group/TUG-2 within the Uth-1 STS-1_SPE/VC-3 within the
Sth STS-3/AUG-1 is: S>0, U>0, K=0, L>0, M=8.
Example 6: the label for the STS-12c SPE/VC-4-4c which uses the
9th STS-3/AUG-1 as its first timeslot is: S=9, U=0,
K=0, L=0, M=0.For contiguous concatenation, the label used is the lowest label (value) of the contiguously concatenated signal, as explained earlier. The higher part of the label shows where the signal starts, and the lowest part is not significant. 🌅
For STM-0/STS-1, the values of S, U, and K must be equal to zero, following the field coding rules. For example, when a VC-3 in an STM-0 is requested, the label is S=0, U=0, K=0, L=0, M=0. When a VC-11 in a VC-3 in an STM-0 is requested, the label is S=0, U=0, K=0, L>0, M=6..9. ✨
Note: when a Section/RS or Line/MS transparent STS-1/STM-0/STS-3*N/STM-N (N=1, 4, 16, 64, 256) signal is requested, the SUKLM label format and encoding does not apply, and the label encoding MUST follow the rules defined in [RFC3471], Section 3.2. 🚨
4. Acknowledgements ✨
Valuable comments and input came from the CCAMP mailing list, where some outstanding discussions happened. 💖
The authors would like to thank Richard Rabbat for his valuable input, which lead to this revision. 🫶
5. Security Considerations 🔐
This document introduces no new security considerations to either [RFC3473] or [RFC3472]. GMPLS security is described in Section 11 of [RFC3471], and it refers to [RFC3209] for RSVP-TE and to [RFC3212] for CR-LDP. Lowkey the most important part, so keep it in mind! 💀
6. IANA Considerations ✨
Okay bestie, IANA has three values for RFC 3946 that now apply to this doc 🎀 Two of them go in the RSVP C-Types registry at http://www.iana.org/assignments/rsvp-parameters 📋
- A SONET/SDH SENDER_TSPEC object: Class = 12, C-Type = 4 (see Section 2.2). 💜
- A SONET/SDH FLOWSPEC object: Class = 9, C-Type = 4 (see Section 2.2). 💜
The third one goes in the LDP TLV Type registry at http://www.iana.org/assignments/ldp-namespaces 🧚
- A type field for the SONET/SDH Traffic Parameters TLV (see Section 2.3). ⭐
Contributors
Contributors are listed in alphabetical order. 🌸 Here's the whole squad, addresses and all 💅
Stefan Ansorge (Alcatel)
Lorenzstrasse 10
70435 Stuttgart, Germany
EMail: stefan.ansorge@alcatel.de
Peter Ashwood-Smith (Nortel)
PO. Box 3511 Station C,
Ottawa, ON K1Y 4H7, Canada
EMail:petera@nortelnetworks.com
Ayan Banerjee (Calient)
5853 Rue Ferrari
San Jose, CA 95138, USA
EMail: abanerjee@calient.net
Lou Berger (Movaz)
7926 Jones Branch Drive
McLean, VA 22102, USA
EMail: lberger@movaz.com
Greg Bernstein (Ciena)
10480 Ridgeview Court
Cupertino, CA 94014, USA
EMail: greg@ciena.com
Angela Chiu (Celion)
One Sheila Drive, Suite 2
Tinton Falls, NJ 07724-2658
EMail: angela.chiu@celion.com
John Drake (Calient)
5853 Rue Ferrari
San Jose, CA 95138, USA
EMail: jdrake@calient.net
Yanhe Fan (Axiowave)
100 Nickerson Road
Marlborough, MA 01752, USA
EMail: yfan@axiowave.com
Michele Fontana (Alcatel)
Via Trento 30,
I-20059 Vimercate, Italy
EMail: michele.fontana@alcatel.it
Gert Grammel (Alcatel)
Lorenzstrasse, 10
70435 Stuttgart, Germany
EMail: gert.grammel@alcatel.de
Juergen Heiles (Siemens)
Hofmannstr. 51
D-81379 Munich, Germany
EMail: juergen.heiles@siemens.com
Suresh Katukam (Cisco)
1450 N. McDowell Blvd,
Petaluma, CA 94954-6515, USA
EMail: suresh.katukam@cisco.com
Kireeti Kompella (Juniper)
1194 N. Mathilda Ave.
Sunnyvale, CA 94089, USA
EMail: kireeti@juniper.net
Jonathan P. Lang (Calient)
25 Castilian
Goleta, CA 93117, USA
EMail: jplang@calient.net
Fong Liaw (Solas Research)
EMail: fongliaw@yahoo.com
Zhi-Wei Lin (Lucent)
101 Crawfords Corner Rd
Holmdel, NJ 07733-3030, USA
EMail: zwlin@lucent.com
Ben Mack-Crane (Tellabs)
EMail: ben.mack-crane@tellabs.com
Dimitrios Pendarakis (Tellium)
2 Crescent Place, P.O. Box 901
Oceanport, NJ 07757-0901, USA
EMail: dpendarakis@tellium.com
Mike Raftelis (White Rock)
18111 Preston Road
Dallas, TX 75252, USA
Bala Rajagopalan (Tellium)
2 Crescent Place, P.O. Box 901
Oceanport, NJ 07757-0901, USA
EMail: braja@tellium.com
Yakov Rekhter (Juniper)
1194 N. Mathilda Ave.
Sunnyvale, CA 94089, USA
EMail: yakov@juniper.net
Debanjan Saha (Tellium)
2 Crescent Place, P.O. Box 901
Oceanport, NJ 07757-0901, USA
EMail: dsaha@tellium.com
Vishal Sharma (Metanoia)
335 Elan Village Lane
San Jose, CA 95134, USA
EMail: vsharma87@yahoo.com
George Swallow (Cisco)
250 Apollo Drive
Chelmsford, MA 01824, USA
EMail: swallow@cisco.com
Z. Bo Tang (Tellium)
2 Crescent Place, P.O. Box 901
Oceanport, NJ 07757-0901, USA
EMail: btang@tellium.com
Eve Varma (Lucent)
101 Crawfords Corner Rd
Holmdel, NJ 07733-3030, USA
EMail: evarma@lucent.com
Yangguang Xu (Lucent)
21-2A41, 1600 Osgood Street
North Andover, MA 01845, USA
EMail: xuyg@lucent.comAppendix 1. Signal Type Values Extension for VC-3 🦋
This appendix defines the following optional additional Signal Type value for the Signal Type field of Section 2.1. Here's the new value 👇
Value Type
----- ---------------------
20 "VC-3 via AU-3 at the end"According to the ITU-T [G.707] recommendation, a VC-3 in the TU-3/TUG-3/VC-4/AU-4 branch of the SDH multiplex cannot be structured in TUG-2s, but a VC-3 in the AU-3 branch can be. 🫶 Plus, a VC-3 could be switched between the two branches, if required. 🔀
A VC-3 circuit could be terminated on an ingress interface of an LSR (e.g., forming a VC-3 forwarding adjacency). Then that LSR could want to demultiplex this VC-3 and switch internal low-order LSPs. For implementation reasons, this could be only possible if the LSR receives the VC-3 in the AU-3 branch. For example, that's the case for an LSR not able to switch internally from a TU-3 branch to an AU-3 branch on its incoming interface before demultiplexing and then switching the content with its switch fabric. 🙈
In that case, it is useful to indicate that the VC-3 LSP must be terminated at the end in the AU-3 branch instead of the TU-3 branch. 💀
This is achieved by using the "VC-3 via AU-3 at the end" signal type. 🎀 This info can be used, for instance, by the penultimate LSR to switch an incoming VC-3 received in any branch to the AU-3 branch on the outgoing interface to the destination LSR. ✨
The "VC-3 via AU-3 at the end" signal type does not imply that the VC-3 must be switched via the AU-3 branch at some other places in the network. The VC-3 signal type just indicates that a VC-3 in any branch is suitable. 💅
Annex 1. Examples 🌈
This annex defines examples of SONET and SDH signal coding. The objective is to help the reader understand how the traffic parameter coding works, and it is NOT meant to give examples of typical SONET or SDH signals. 🧚
As stated above, signal types are Elementary Signals to which successive concatenation, multiplication, and transparency transforms can be applied to obtain Final Signals. 🔥
- A VC-4 signal is formed by the application of RCC with value 0, NCC with value 0, NVC with value 0, MT with value 1, and T with value 0 to a VC-4 Elementary Signal. 🌸
- A VC-4-7v signal is formed by the application of RCC with value 0, NCC with value 0, NVC with value 7 (virtual concatenation of 7 components), MT with value 1, and T with value 0 to a VC-4 Elementary Signal. 🌸
- A VC-4-16c signal is formed by the application of RCC with value 1 (standard contiguous concatenation), NCC with value 16, NVC with value 0, MT with value 1, and T with value 0 to a VC-4 Elementary Signal. 🌸
- An STM-16 signal with Multiplex Section layer transparency is formed by the application of RCC with value 0, NCC with value 0, NVC with value 0, MT with value 1, and T with flag 2 to an STM-16 Elementary Signal. 🌸
- An STM-4 signal with Multiplex Section layer transparency is formed by the application of RCC with value 0, NCC with value 0, NVC with value 0, MT with value 1, and T with flag 2 applied to an STM-4 Elementary Signal. 🌸
- An STM-256 signal with Multiplex Section layer transparency is formed by the application of RCC with value 0, NCC with value 0, NVC with value 0, MT with value 1, and T with flag 2 applied to an STM-256 Elementary Signal. 🌸
- An STS-1 SPE signal is formed by the application of RCC with value 0, NCC with value 0, NVC with value 0, MT with value 1, and T with value 0 to an STS-1 SPE Elementary Signal. 🌸
- An STS-3c SPE signal is formed by the application of RCC with value 1 (standard contiguous concatenation), NCC with value 1, NVC with value 0, MT with value 1, and T with value 0 to an STS-3c SPE Elementary Signal. 🌸
- An STS-48c SPE signal is formed by the application of RCC with value 1 (standard contiguous concatenation), NCC with value 16, NVC with value 0, MT with value 1, and T with value 0 to an STS-3c SPE Elementary Signal. 🌸
- An STS-1-3v SPE signal is formed by the application of RCC with value 0, NVC with value 3 (virtual concatenation of 3 components), MT with value 1, and T with value 0 to an STS-1 SPE Elementary Signal. 🌸
- An STS-3c-9v SPE signal is formed by the application of RCC with value 1, NCC with value 1, NVC with value 9 (virtual concatenation of 9 STS-3c), MT with value 1, and T with value 0 to an STS-3c SPE Elementary Signal. 🌸
- An STS-12 signal with Section layer (full) transparency is formed by the application of RCC with value 0, NCC with value 0, NVC with value 0, MT with value 1, and T with flag 1 to an STS-12 Elementary Signal. 🌸
- A 3 x STS-768c SPE signal is formed by the application of RCC with value 1, NCC with value 256, NVC with value 0, MT with value 3, and T with value 0 to an STS-3c SPE Elementary Signal. 🌸
- A 5 x VC-4-13v composed signal is formed by the application of RCC with value 0, NVC with value 13, MT with value 5, and T with value 0 to a VC-4 Elementary Signal. 🌸
The encoding of these examples is summarized in the following table: 📊
Signal ST RCC NCC NVC MT T
--------------------------------------------------------
VC-4 6 0 0 0 1 0
VC-4-7v 6 0 0 7 1 0
VC-4-16c 6 1 16 0 1 0
STM-16 MS transparent 10 0 0 0 1 2
STM-4 MS transparent 9 0 0 0 1 2
STM-256 MS transparent 12 0 0 0 1 2
STS-1 SPE 5 0 0 0 1 0
STS-3c SPE 6 1 1 0 1 0
STS-48c SPE 6 1 16 0 1 0
STS-1-3v SPE 5 0 0 3 1 0
STS-3c-9v SPE 6 1 1 9 1 0
STS-12 Section transparent 9 0 0 0 1 1
3 x STS-768c SPE 6 1 256 0 3 0
5 x VC-4-13v 6 0 0 13 5 0Normative References
okay bestie, these are the reading list you need open before anything else makes sense 📚✨ The normative ones are the non-negotiables, no cap.
- [G.707] ITU-T Recommendation G.707, "Network Node Interface for the Synchronous Digital Hierarchy", October 2000. 🌸
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 💅 the OG key words guide, obviously
- [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. 🦋
- [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. ✨
- [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. 💖
- [RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002. 🧚 this one has SO many authors, the group project of the century
- [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. 🎀
- [RFC3472] Ashwood-Smith, P. and L. Berger, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003. 🌈
- [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 👑
- [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. 🫶
- [T1.105] "Synchronous Optical Network (SONET): Basic Description Including Multiplex Structure, Rates, and Formats", ANSI T1.105, October 2000. ⭐
Authors' Addresses
these are the two queens who wrote the thing 👑🫶 here's where to find them:
Eric Mannie
Perceval
Rue Tenbosch, 9
1000 Brussels
Belgium
Phone: +32-2-6409194
EMail: eric.mannie@perceval.net
Dimitri Papadimitriou
Alcatel
Copernicuslaan 50
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel.beFull Copyright Statement
Copyright (C) The Internet Society (2006). 🎀
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. So the authors still own their stuff, just like you own your Stan-worthy playlists 💜
The legal disclaimer is serious, so here it is word for word, no cap:
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀
Intellectual Property
so the IETF is basically saying "we're not picking a side on who owns what" 🙈 It takes no position on whether any Intellectual Property Rights or other rights might be claimed over the technology in this document, or whether any license under those rights might or might not be available, and it doesn't claim to have searched for any such rights. If you want the procedures for rights in RFC documents, look in BCP 78 and BCP 79. 📚
Copies of IPR disclosures made to the IETF Secretariat, along with any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users of this specification to use such proprietary rights, can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr. 🌐
The IETF also invites anyone to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to implement this standard. Send that info to ietf-ipr@ietf.org. 🦋 this is the "say something if you know something" part of the group chat
Acknowledgement
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). ✨ the unsung heroes keeping the lights on, periodt 💖
📦 where this page comes from
- ietf: rfc4606 2006-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms