RFC 3946
Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control
RFC 3946: Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control 🌈
Okay bestie, this is RFC 3946 💖 It came out of the Network Working Group and it's a Standards Track doc, dated October 2004. The authors are E. Mannie (Consultant) and D. Papadimitriou (Alcatel) 🎀 Its header doesn't list any Obsoletes or Updates, so it's standing on its own, main character energy 👑
Status of this Memo ✨
This doc specifies 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 on the standardization side, check the current edition of the "Internet Official Protocol Standards" (STD 1). And yes, distribution of this memo is unlimited 💅
Copyright Notice 🌸
Copyright (C) The Internet Society (2004).
Abstract 🦋
This doc is a companion to Generalized Multi-Protocol Label Switching (GMPLS) signaling. It spells out the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology specific info you need when you're using GMPLS signaling 🧚
Table of Contents 🍓
1. Introduction ................................................. 2
2. SONET and SDH Traffic Parameters ............................. 2
2.1. SONET/SDH Traffic Parameters ........................... 3
2.2. RSVP-TE Details ........................................ 9
2.3. CR-LDP Details ......................................... 9
3. SONET and SDH Labels ......................................... 10
4. Acknowledgments .............................................. 15
5. Security Considerations ...................................... 16
6. IANA Considerations .......................................... 16
7. References ................................................... 16
7.1. Normative References ................................... 16
Appendix 1 - Signal Type Values Extension for VC-3 ............... 18
Annex 1 - Examples ............................................... 18
Contributors ..................................................... 21
Authors' Addresses ............................................... 25
Full Copyright Statement ......................................... 261. Introduction ✨
Okay so, as [RFC3945] explains, Generalized MPLS (GMPLS) takes MPLS, which only handled packet interfaces (Packet Switching Capable - PSC), and extends it to four new classes of interfaces and switching: Layer-2 Switch Capable (L2SC), Time-Division Multiplex (TDM), Lambda Switch Capable (LSC) and Fiber-Switch Capable (FSC) 🌈 The functional description of the MPLS signaling extensions for those new classes is in [RFC3471]. [RFC3473] covers the RSVP-TE specific formats and mechanisms for all five classes of interfaces, and the CR-LDP extensions live in [RFC3472]. This doc gets into the details that are specific to Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH). As [RFC3471] says, the SONET/SDH specific parameters are 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 ANSI [T1.105], ITU-T [G.707], and [RFC3471], [RFC3472], and [RFC3473] 🧚 Here are the abbreviations used in this doc:
- 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 the CR-LDP TLVs are described in sections 2.2 and 2.3 respectively.
These traffic parameters give you a base set of capabilities for SONET ANSI [T1.105] and SDH ITU-T [G.707], like concatenation and transparency 🦋 Other documents may build on this set in the future. For example, signaling for SDH over PDH ITU-T G.832 or sub-STM-0 ITU-T G.708 interfaces could be 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. Put another way, all the defined Transparency (T) bits would be set if you used the traffic parameters from section 2.1 🫶
2.1. SONET/SDH Traffic Parameters 🎀
The traffic parameters for SONET/SDH are laid out 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 🍓
Signal Type (ST): 8 bits
This field tells you the type of Elementary Signal that makes up the requested LSP. You can apply several transforms 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 the Multiplier (MT) that cannot be zero and is ignored if equal to one 🌸
Transforms must be applied strictly in the following 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 requesting a frame as signal rather than an SPE or VC based signal.
- Fourth, a multiplication (by using the Multiplier field) can be optionally applied either directly on the Elementary Signal, or on the contiguously concatenated signal obtained from the first phase, or 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 requesting transparency)
8 STS-3 / STM-1 (only when requesting transparency)
9 STS-12 / STM-4 (only when requesting transparency)
10 STS-48 / STM-16 (only when requesting transparency)
11 STS-192 / STM-64 (only when requesting transparency)
12 STS-768 / STM-256 (only when requesting transparency)A dedicated signal type is assigned to a SONET STS-3c SPE, instead of coding it as a contiguous concatenation of three STS-1 SPEs 🫶 The reason is to make interworking between SONET and SDH signaling easy 🌈
Appendix 1 adds one signal type (optional) to the values above 🦋
Requested Contiguous Concatenation (RCC): 8 bits
This field is used to request the optional SONET/SDH contiguous concatenation of the Elementary Signal 💖
It's a vector of flags. Each flag shows support for a particular type of contiguous concatenation, and you can set several flags 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 still makes the final call, using its own rules 👑
If a downstream node gets more than one flag at once, it picks one type of contiguous concatenation (if it supports any of them), based on criteria that are outside the scope of this document 💅 A downstream node that doesn't support any of the concatenation types in the field must refuse the LSP request. In particular, 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 one type of contiguous concatenation the downstream node chose by looking at the position indicated by the first label and the number of label(s) that the downstream node returns (see also Section 3) 🧚
The whole field is set to zero to mean no contiguous concatenation is requested at all, which is the default. 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're not used, they must be set to zero when sent, and should be ignored when received 💜
Check out note 1 below, in the NCC section, about SONET contiguous concatenation of STS-1 SPEs when the number of components is a multiple of three 🔥
Number of Contiguous Components (NCC): 16 bits
This field shows the number of identical SONET SPEs/SDH VCs (aka the Elementary Signal) that are requested to be concatenated, as specified in the RCC field 🍓
Note 1: When requesting a SONET STS-Nc SPE with N=3*X, the Elementary Signal to use must always be an STS-3c_SPE signal type, and the value of NCC must always be equal to X. This also makes SONET and SDH interworking easier. Specifically, it means the contiguous concatenation of three STS-1 SPEs can not be requested, because under this specification that kind of signal has to be coded with the STS-3c SPE signal type 🦋
Okay so Note 2 is the one for when you want a transparent STS-N/STM-N signal that's squeezed into a single contiguously concatenated STS-Nc_SPE/VC-4-Nc 🧚. In that case the signal type must be STS-N/STM-N, with RCC set to flag 1 and NCC set to 1 💅.
The NCC value has to match the kind of contiguous concatenation you asked for in the RCC field 🫶. If you don't request any contiguous concatenation at all (RCC = 0), NCC is irrelevant. You set it to zero when you send it, and you should ignore it when you receive it 🙈. And an RCC value that isn't 0 must mean you're asking for more than 1 contiguous component, no cap 🔥.
Number of Virtual Components (NVC): 16 bits ✨
This field tells you how many signals are being requested for virtual concatenation. They're all the same type, by definition 💜. We're talking Elementary Signal SPEs/VCs here, and the types this document defines are 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.
If the field is set to 0 (the default), that just means no virtual concatenation is requested. Iykyk 🦋.
Multiplier (MT): 16 bits 🎀
This field says how many identical signals the LSP needs, which together make up the Final Signal. Those signals can be identical Elementary Signals, identical contiguously concatenated signals, or identical virtually concatenated signals. All of them belong to the same LSP, so no drama 👑.
When you have multiple virtually concatenated signals, you tell the components apart by the order of the labels in the signaling. The first set of labels describes the first component (the set of individual signals that belong to the first virtual concatenated signal), the second set describes the second component, and so on and so forth 🌈.
The default value is one, which means 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 they can't, the receiver node MUST generate a PathErr/NOTIFICATION message (see Section 2.2/2.3, respectively) 😭.
Zero is an invalid value, periodt 💀. If a node receives it, the node MUST generate a PathErr/NOTIFICATION message (see Section 2.2/2.3, respectively).
Note 1: when requesting a transparent STS-N/STM-N signal limited to a single contiguously concatenated STS-Nc-SPE/VC-4-Nc, the multiplier field MUST be equal to 1 (only valid value).
Transparency (T): 32 bits 🦋
This field is a vector of flags that says what kind of transparency you're asking for. You can combine several flags to get different types of transparency, but not every combination is necessarily valid 💅. The default is zero, which means no transparency requested.
Transparency, from the point of view of this signaling spec, only applies to the fields in the SONET/SDH frame overheads. For SONET, that's the Section Overhead (SOH) and the Line Overhead (LOH). For SDH, it's 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 is only a thing for these Signal Types: 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. If you're requesting one of these, you must specify at least one transparency type 🫶.
Transparency tells you exactly which overhead fields have to arrive at the other end of the LSP unmodified. An ingress LSR that asks for transparency passes those overhead fields along to the egress LSR without changing any of them. From both the ingress and egress LSRs' points of view, those fields have to look unmodified ✨.
Transparency doesn't apply at the interfaces with the initiating and terminating LSRs. It only gets applied between intermediate LSRs 🌸.
The transparency field is used to request an LSP that supports the transparency type you want. It can also be used to set up the transparency process that gets applied at each intermediate LSR 💜.
The transparency flags are:
Flag 1 (bit 1): Section/Regenerator Section layer.Flag 2 (bit 2): Line/Multiplex Section layer.
Bit 1 is the low order bit. The other flags are reserved, so they should be set to zero when sent and should be ignored when received. You set a flag to one to say that the matching transparency is requested 🍓.
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 Section 2.2/2.3, respectively) 😭.
Section/Regenerator Section layer transparency means the entire frames must be delivered unmodified. That also means the pointers can't be adjusted 🙈. When you use Section/Regenerator Section layer transparency, all other flags MUST be ignored, hard stop 🛑.
Line/Multiplex Section layer transparency means the LOH/MSOH must be delivered unmodified. Again, that implies the pointers can't be adjusted 🌈.
Profile (P): 32 bits 🎀
This field is meant to indicate particular capabilities that must be supported for the LSP, like monitoring capabilities 👀.
No standard profile is defined right now. This field SHOULD be set to zero when transmitted and SHOULD be ignored when received 🫶. TLV based extensions might show up in the future ✨.
2.2. RSVP-TE Details 🧚
For RSVP-TE, the SONET/SDH traffic parameters ride along in the SONET/SDH SENDER_TSPEC and FLOWSPEC objects. Both objects use the same format, and the content is defined above in Section 2.1. The objects have this 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 = 4
There's no Adspec associated with the SONET/SDH SENDER_TSPEC. You can either leave the Adspec out, or use an int-serv Adspec with the Default General Characterization Parameters and Guaranteed Service fragment, see [RFC2210] 💅.
For a particular sender in a session, the FLOWSPEC object you get in a Resv message SHOULD be identical to the SENDER_TSPEC object you got 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 comes in 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 header of the TLV 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 comes in 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 ✨
okay bestie, SONET and SDH each come with their own multiplexing structure 🌸 and honestly it's giving tree. The roots are an STS-N or an STM-N, and the leaves are the signals that ride the time-slots and get switched between time-slots, going from an ingress port to an egress port. Those leaves are a VTx SPE, an STS-x SPE or a VC-x. A SONET/SDH label pinpoints the exact spot (the first time-slot) where your VTx SPE, STS-x SPE or VC-x signal lives in that structure 💖 Labels get carried in the Generalized Label, per [RFC3473] and [RFC3472].
Quick heads up: when we say time-slots, we mean the ones as they show up logically and in order inside the multiplex 🧚, not however they look after any interleaving happens.
These multiplexing structures double as naming trees, so every multiplex entry gets a unique name or label 🎀 SONET and SDH use the exact same label format. As [RFC3471] explains, a label doesn't say what "class" it belongs to. That's implied by whichever link the label is used on, so no extra tag needed ✨
If you're concatenating or multiplying signals, a whole list of labels can show up in the Label field of a Generalized Label 🦋
For contiguous concatenation, only one label goes in the Label field. That label names the lowest time-slot the contiguously concatenated signal occupies 💅 "Lowest" here means the lowest label value when you compare them as integers. Basically it's the time-slot of the first component signal you hit when you go down the tree.
For virtual concatenation, you get the explicit, ordered list of every label in the concatenation. Each label marks the first time-slot taken by one component of the virtually concatenated signal 🫶 The order of the labels has to match the order of the payloads you're concatenating, not the physical order of the time-slots. This way of writing it keeps virtual concatenation inside a single (component) link. That's a restriction compared to what the ANSI [T1.105] and ITU-T [G.707] recommendations allow 😭
Here's the tea: the standard virtual concatenation definition lets each component travel over diverse paths. Inside GMPLS, though, the components have to travel over the same (component) link if they belong to the same LSP. That's because of how labels get bound to a (component) link 🔥 Still, routing components over different paths is basically the same as setting up different LSPs, each with its own route. Several LSPs can start and end between the same nodes, and their components can then be linked together (aka virtually concatenated) 👑
For multiplication (using the multiplier transform), you get the explicit ordered list of every label that's part of the Final Signal 🌈 When you multiply virtually concatenated signals, the first set of labels marks the time-slots of the first virtually concatenated signal, the second set marks the second one, and so on. Same deal as before: this representation keeps multiplication inside a single (component) link 🍓
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 to 7.3.13, which is the (K, L, M) numbering 🌸 Heads up: the higher order numbering scheme in [G.707] sections 7.3.1 to 7.3.6 isn't used here.
Each letter stands for a possible branch number, counted from the parent node in the multiplex structure. Branches get numbered in increasing order, starting from the top of the multiplexing structure 🦋 Numbering starts at 1. Zero is reserved for a field that's 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 MUST be ignored when received. No exceptions, bestie 💀
When you've got a hierarchy of SONET/SDH LSPs, a higher order LSP with a given bandwidth can carry lower order LSPs 💖 Keep in mind that a higher order LSP runs through a SONET/SDH higher order path layer network, and a lower order LSP runs through a SONET/SDH lower order path layer network (see also ITU-T G.803, Section 3 for the official definitions). In this setup, the higher order SONET/SDH LSP acts like a "virtual link" with a set bandwidth (for example, 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. Since a label is local to a (virtual) link, the highest part of that label (the S, U and K fields) is non-significant and gets set to zero, so the label is "0,0,0,L,M" 🧚 Similarly, if the structure of the lower order LSP is unknown or doesn't matter, the lowest part of that label (the L and M fields) is non-significant and gets 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 which signal is allocated inside that VC-3.
Tunneling, like VC-4 containing VC-3 containing VC-12/VC-11, is a case where the SUKLM structure can't fully represent the whole signal structure 😭 So you need a hierarchical approach instead, meaning per layer network signaling.
Okay, here's what each of S, U, K, L and M can be 💅
- S=1->N is the index of a particular STS-3/AUG-1 inside an STS-N/STM-N multiplex. S only matters for SONET STS-N (N>1) and SDH STM-N (N>0). S must be 0 and ignored for STS-1 and STM-0.
- U=1->3 is the index of a particular STS-1_SPE/VC-3 within an STS-3/AUG-1. U only matters for SONET STS-N (N>1) and SDH STM-N (N>0). U must be 0 and ignored for STS-1 and STM-0.
- K=1->3 is the index of a particular TUG-3 within a VC-4. K only matters for an SDH VC-4 structured in TUG-3s. K must be 0 and ignored in all other cases.
- L=1->7 is the index of a particular VT_Group/TUG-2 within an STS-1_SPE/TUG-3 or VC-3. L must be 0 and ignored in all other cases.
- M is 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->2 indicates a specific VT3 SPE inside the corresponding VT Group, and these values MUST NOT be used for SDH since there's no equivalent of VT3 with SDH 🙈 M=3->5 indicates a specific VT2_SPE/VC-12 inside the corresponding VT_Group/TUG-2. M=6->9 indicates a specific VT1.5_SPE/VC-11 inside the corresponding VT_Group/TUG-2.
Note that a label always has to be read according to the SONET/SDH traffic parameters. A label by itself doesn't tell you which signal is being requested, because a label is context sensitive 🌈
The label format in this section, called SUKLM, MUST be used for any SONET/SDH signal requests that are not transparent. That means when 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 as defined in [RFC3471] 💖
The S encoding is summarized in this table:
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 is summarized in this table:
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 is summarized in this table:
K SDH VC-4
---------------
0 other
1 1st TUG-3
2 2nd TUG-3
3 3rd TUG-3The L encoding is summarized in this table:
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 is summarized in this table:
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 SPETime for some examples 🧚
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/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.
With contiguous concatenation, the label used is the lowest label value of the contiguously concatenated signal, as covered above 💅 The higher part of the label shows where the signal starts, and the lowest part isn't significant.
For STM-0/STS-1, the values of S, U and K must be equal to zero according to the field coding rules. For example, when requesting a VC-3 in an STM-0, the label is S=0, U=0, K=0, L=0, M=0. When requesting a VC-11 in a VC-3 in an STM-0, 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 is not applicable, and the label encoding MUST follow the rules defined in [RFC3471] Section 3.2 🦋
4. Acknowledgments 🫶
Valuable comments and input were received from the CCAMP mailing list, where outstanding discussions took place 💜
5. Security Considerations 🔒
okay bestie, this one is short and sweet 🫶 this document adds no new security considerations to either [RFC3473] or [RFC3472]. 🎀 GMPLS security lives in section 11 of [RFC3471], which points to [RFC3209] for RSVP-TE and to [RFC3212] for CR-LDP. go read those if you want the full security tea ☕
6. IANA Considerations 📋
three values got defined by IANA for this doc ✨ (yes, the count is three, we checked 💅)
two RSVP C-Types live in this registry: 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).
and one LDP TLV Type lives in this one: http://www.iana.org/assignments/ldp-namespaces 🦋
- a type field for the SONET/SDH Traffic Parameters TLV (see section 2.3).
7. References 📚
7.1. Normative References 💜
these are the must-read sources, 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.[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.[RFC3471]Berger, L., "Generalized Multi-Protocol Label Switching (MPLS) Signaling Functional Description", RFC 3471, January 2003.[RFC3472]Ashwood-Smith, P. and L. Berger, "Generalized Multi-Protocol Label Switching (MPLS) Signaling - Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003.[RFC3473]Berger, L., "Generalized Multi-Protocol Label Switching (MPLS) Signaling - Resource ReserVation Protocol Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.[RFC3945]Mannie, E., Ed., "Generalized Multiprotocol 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.
Appendix 1 - Signal Type Values Extension for VC-3 🎀
this appendix adds one optional extra Signal Type value for the Signal Type field from section 2.1 ✨
Value Type
----- ---------------------
20 "VC-3 via AU-3 at the end"okay so, per 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. and a VC-3 could be switched between the two branches if needed 🔀
a VC-3 circuit could be terminated on an ingress interface of an LSR (for example, forming a VC-3 forwarding adjacency) 🦋 that LSR might then want to demultiplex this VC-3 and switch internal low order LSPs. for implementation reasons, this could only be possible if the LSR receives the VC-3 in the AU-3 branch. for example, that's the case for an LSR that isn't 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's 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 toward 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 other places in the network. the VC-3 signal type just says that a VC-3 in any branch is suitable 💖
Annex 1 - Examples 🌸
this annex has examples of SONET and SDH signal coding 🫶 the goal is to help the reader understand how the traffic parameter coding works, not to show typical SONET or SDH signals 🙈
as mentioned above, signal types are Elementary Signals that successive concatenation, multiplication and transparency transforms can be applied to, to get Final Signals 🔥
- a VC-4 signal is formed by applying 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 applying 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 applying RCC with flag 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 applying 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 applying RCC with flag 0, NCC with value 0, NVC with value 0, MT with value 1 and T with flag 2 to an STM-4 Elementary Signal.
- an STM-256 signal with Multiplex Section layer transparency is formed by applying RCC with flag 0, NCC with value 0, NVC with value 0, MT with value 1 and T with flag 2 to an STM-256 Elementary Signal.
- an STS-1 SPE signal is formed by applying 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 applying 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 applying RCC with flag 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 applying 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 applying 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 applying RCC 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 applying RCC with flag 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 applying 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 all these examples is summed up in this 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 0Contributors 💖
okay bestie, these are the amazing people who helped build this spec 🫶 they're listed alphabetically (by surname, ngl, so the order is a little bit of a vibe). Every name comes with their company, address, and email so you can reach out if you ever need to 💌
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.comAuthors' Addresses 🦋
these are the two main authors who wrote the document, so if you have questions about the actual spec, these are your people 🧚 Here's where you can find them, with phone numbers too 📞
Eric Mannie (Consultant)
Avenue de la Folle Chanson, 2
B-1050 Brussels, Belgium
Phone: +32 2 648-5023
Mobile: +32 (0)495-221775
EMail: eric_mannie@hotmail.com
Dimitri Papadimitriou (Alcatel)
Francis Wellesplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel.beFull Copyright Statement 🎀
okay this part is the legal bit, but it still matters 💅 The copyright is held by The Internet Society, and it's dated 2004 🌸
Copyright (C) The Internet Society (2004).
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.
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.
the all-caps part is serious 🙈 the document comes "AS IS", and nobody involved gives any warranties, not even implied ones, so don't assume it's guaranteed to do anything just because it's a spec
Intellectual Property 🔥
the IETF doesn't take a side on whether any patents or other IP rights apply to the tech in here, or whether you can get a license for them 🤷♀️ It also doesn't claim it did any independent digging to find out 🫠 If you want the full details on how IETF handles rights, look in BCP 78 and BCP 79 📚
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses that will be made available, and the results of any attempt to get a general license or permission to use those proprietary rights for implementers or users of this specification can all be found in the IETF on-line IPR repository at http://www.ietf.org/ipr 🌈
The IETF invites anyone who's interested to point out any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💌
Acknowledgement 🌷
last but not least, a big thank you to whoever's keeping the lights on for the RFC Editor function 🫶 Right now, that's being funded by the Internet Society 💜
📦 where this page comes from
- ietf: rfc3946 2004-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms