RFC 7138
Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks
Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks 🎀
Part 1 of 8 💖
okay bestie, this is RFC 7138 🦋 and it's a Standards Track doc, which means it's official IETF spec and not just a vibe 💅 It's from March 2014, published as ISSN 2070-1721. The editor is D. Ceccarelli from Ericsson, and the other authors are F. Zhang (Huawei Technologies), S. Belotti (Alcatel-Lucent), R. Rao (Infinera Corporation), and J. Drake (Juniper). Its header doesn't list any Obsoletes or Updates lines, so it's not replacing or patching anything else 🌸
Abstract 📝
this doc is all about making OSPF-TE (the routing protocol that shares traffic engineering info) work for GMPLS control of Optical Transport Networks (OTNs), which are defined in ITU-T Recommendation G.709 as published in 2012 ✨ it builds on the mechanisms from RFC 4203, so it's basically a glow-up of that one 🌈
Status of This Memo 📋
ok so this is an Internet Standards Track document 🎀
it's a product of the IETF, it represents the consensus of the IETF community, got public review, and was approved for publication by the IESG (Internet Engineering Steering Group) 🫶 if you want more on Internet Standards, check Section 2 of RFC 5741. for the current status, any errata, and where to send feedback, go to http://www.rfc-editor.org/info/rfc7138 🔥
Copyright Notice 💜
© 2014 the IETF Trust and the people listed as document authors, all rights reserved 🦋
this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which are at http://trustee.ietf.org/license-info and are in effect on the date it was published. read those carefully, because they're your rights and restrictions for this doc 🙈 any Code Components pulled out of this document have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 💅
Table of Contents 🧚
1. Introduction ....................................................4
1.1. Terminology ................................................4
2. OSPF-TE Extensions ..............................................4
3. TE-Link Representation ..........................................6
4. ISCD Format Extensions ..........................................6
4.1. Switching Capability Specific Information ..................8
4.1.1. Switching Capability Specific Information
for Fixed Containers ................................9
4.1.2. Switching Capability Specific Information
for Variable Containers ............................10
4.1.3. Switching Capability Specific Information --
Field Values and Explanation .......................10
5. Examples .......................................................13
5.1. MAX LSP Bandwidth Fields in the ISCD ......................13
5.2. Example of T, S, and TS Granularity Utilization ...........17
5.2.1. Example of Different TS Granularities ..............18
5.3. Example of ODUflex Advertisement ..........................20
5.4. Example of Single-Stage Muxing ............................22
5.5. Example of Multi-Stage Muxing -- Unbundled Link ...........23
5.6. Example of Multi-Stage Muxing -- Bundled Links ............25
5.7. Example of Component Links with Non-Homogeneous
Hierarchies ...............................................27
6. OSPFv2 Scalability .............................................29
7. Compatibility ..................................................30
8. Security Considerations ........................................30
9. IANA Considerations ............................................31
9.1. Switching Types ...........................................31
9.2. New Sub-TLVs ..............................................31
10. Contributors ..................................................32
11. Acknowledgements ..............................................33
12. References ....................................................33
12.1. Normative References .....................................33
12.2. Informative References ...................................341. Introduction ✨
so G.709 (the "Interfaces for the Optical Transport Network (OTN)") [G.709-2012] brings a bunch of new stuff 🌸 there are new fixed and flexible ODU (Optical channel Data Unit) containers, two types of tributary slots (1.25 Gbps and 2.5 Gbps), a few multiplexing relationships (for example, ODUj multiplexed into ODUk, written as j<k), two different tributary slots for ODUk (K=1, 2, 3), and the ODUflex service type 😭
to get all of this into routing, this doc provides OTN-specific encoding for use in GMPLS OSPF-TE, as defined in [RFC4203] 💖
if you want a quick overview of how OTN evolved and what that means for GMPLS routing, go read [RFC7062] 🎀 the information model and an evaluation against the current solution are in [RFC7096]. the reader is supposed to be familiar with both of these, so no skipping 🙈
heads up: routing info for the Optical Channel (OCh) layer (basically, wavelengths) is out of scope for this doc. for that, check [RFC6163] and [RFC6566] 💅
1.1. Terminology 🦋
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] ✨
2. OSPF-TE Extensions 🌈
in GMPLS-based OTN networks, each Optical channel Transport Unit-k (OTUk) can be seen as a component link, and each component link can carry one or more types of ODUj, where j<k 💜
each TE-Link State Advertisement (LSA) can carry a top-level link TLV with several nested sub-TLVs that describe different attributes of a TE-Link 🫶 there are two top-level TLVs defined in [RFC3630]: (1) the Router Address TLV (also called the Node TLV) and (2) the TE-Link TLV. one or more sub-TLVs can be nested inside those two. the sub-TLV sets for both top-level TLVs are defined in [RFC3630] and [RFC4203] ✨
as discussed in [RFC7062] and [RFC7096], OSPF-TE must be extended so it can advertise the termination and Switching Capabilities of each different ODUj and ODUk/OTUk (Optical Transport Unit), plus the related multiplexing capabilities 🔥 those capabilities go in the Switching Capability specific information field of the Interface Switching Capability Descriptor (ISCD), using the formats defined in this doc. as [RFC7062] points out, using a technology-specific Switching Capability specific information field means you need a brand new Switching Capability value and an associated new Switching Capability 👑
here's the notation we'll use: ODUj is a service type that gets multiplexed into a higher-order (HO) ODU, ODUk is a higher-order ODU that includes an ODUj, and ODUk/OTUk is the layer mapped into the OTUk 💖 ODUj(S) and ODUk(S) mean the ODUj and ODUk that support Switching Capability only, and the ODUj->ODUk format means the ODUj-into-ODUk multiplexing capability 🧚
you can repeat this notation as many times as you need, depending on how many multiplexing levels there are 🍓 the term "multiplexing tree" describes a multiplexing hierarchy where the root is always a server ODUk/OTUk, and every other supported multiplexed container shows up with increasing granularity until you hit a leaf of the tree 🌸 a tree can have more than one branch if the server ODUk/OTUk supports more than one hierarchy 💅
for example, take this multiplexing hierarchy:
ODU2 ODU0 ODUflex ODU0
\ / \ /
| |
ODU3 ODU2
\ /
\ /
\ /
\ /
ODU4so ODU4 is the root of the muxing tree, and ODU3 and ODU2 are the containers directly multiplexed into the server 🦋 ODU2 and ODU0 are the leaves of the ODU3 branch, while ODUflex and ODU0 are the leaves of the ODU2 branch 😭 that means these multiplexing capabilities are possible:
ODU2->ODU3->ODU4
ODU0->ODU3->ODU4
ODUflex->ODU2->ODU4
ODU0->ODU2->ODU43. TE-Link Representation 🎀
G.709 ODUk/OTUk links get represented as TE-Links in the GMPLS Traffic Engineering Topology, so you can do ODUj layer switching ✨ these TE-Links can be modeled in multiple ways 💖
OTUk physical link(s) can be modeled as TE-Link(s) 🌈 here's one-hop OTUk TE-Links in Figure 1:
+-------+ +-------+ +-------+
| OTN | | OTN | | OTN |
|Switch |<- OTUk Link ->|Switch |<- OTUk Link ->|Switch |
| A | | B | | C |
+-------+ +-------+ +-------+
|<-- TE-Link -->| |<-- TE-Link -->|
Figure 1: OTUk TE-Linksyou can also make TE-Links that span more than one hop by creating forwarding adjacencies (FAs) between non-adjacent nodes (see Figure 2) 🫶 same as the one-hop case, multiple-hop TE-Links advertise the ODU Switching Capability 💜
+-------+ +-------+ +-------+
| OTN | | OTN | | OTN |
|Switch |<- OTUk Link ->|Switch |<- OTUk Link ->|Switch |
| A | | B | | C |
+-------+ +-------+ +-------+
ODUk Switched
|<------------- ODUk Link ------------->|
|<-------------- TE-Link--------------->|
Figure 2: Multiple-Hop TE-Link4. ISCD Format Extensions ✨
okay so the ISCD is the bit that tells everyone what an interface's Switching Capability is, and it's defined in [RFC4203] 🦋 this doc adds a brand new Switching Capability value just for OTN [G.709-2012], and it's giving main character energy:
Value Type
----- ----
110 OTN-TDM capableWhen you're supporting the extensions from this doc, for both fixed and flexible ODUs, the Switching Capability and Encoding values MUST be used as follows:
Switching Capability = OTN-TDMEncoding Type = G.709 ODUk (Digital Path), as defined in [RFC4328]
The same Switching Type and encoding values must be used for both fixed and flexible ODUs. Once Switching Capability and Encoding are set to those values, the Interface Switching Capability Descriptor MUST be interpreted as defined in [RFC4203] 💅
The MAX LSP Bandwidth field follows [RFC4203], so it's 0 <= MAX LSP Bandwidth <= ODUk/OTUk 🌸 and the in-between values are the ones on the branch of the OTN switching hierarchy that the interface supports. For example, on an OTU4 link you could have ODU4 as the MAX LSP Bandwidth for some priorities, ODU3 for others, ODU2 for some others, etc. The bandwidth unit is bytes/second and the encoding MUST be in IEEE floating point format 🤓 The discrete values for the various ODUs are in the table below (pls note that there are 1000 bits in a kilobit according to normal practices in telecommunications 🙈).
+-------------------+-----------------------------+-----------------+
| ODU Type | ODU nominal bit rate |Value in Byte/Sec|
| | |(floating p. val)|
+-------------------+-----------------------------+-----------------+
| ODU0 | 1,244,160 kbps | 0x4D1450C0 |
| ODU1 | 239/238 x 2,488,320 kbps | 0x4D94F048 |
| ODU2 | 239/237 x 9,953,280 kbps | 0x4E959129 |
| ODU3 | 239/236 x 39,813,120 kbps | 0x4F963367 |
| ODU4 | 239/227 x 99,532,800 kbps | 0x504331E3 |
| ODU2e | 239/237 x 10,312,500 kbps | 0x4E9AF70A |
| | | |
| ODUflex for CBR | 239/238 x client signal | MAX LSP |
| Client signals | bit rate | Bandwidth |
| | | |
| ODUflex for GFP-F | | MAX LSP |
| Mapped client | Configured bit rate | Bandwidth |
| signal | | |
| | | |
| ODUflex | Configured bit rate | MAX LSP |
| resizable | | Bandwidth |
+-------------------+-----------------------------+-----------------+A single ISCD MAY be used to advertise unbundled or bundled links that support homogeneous multiplexing hierarchies and the same TS (tributary slot) granularity. A different ISCD MUST be used for each different muxing hierarchy (muxing tree in the following examples) and each different TS granularity supported within the TE-Link 🧚
When a received LSA has a sub-TLV that isn't formatted exactly per the precise specs in this doc, the problem SHOULD be logged and the wrongly formatted sub-TLV MUST NOT be used for path computation. Don't let the bad sub-TLV near path computation, bestie 🚫💀
4.1. Switching Capability Specific Information
The technology-specific part of the OTN-TDM ISCD can have a variable number of sub-TLVs called Bandwidth sub-TLVs. Each sub-TLV is encoded with the sub-TLV header defined in [RFC3630], Section 2.3.2. The muxing hierarchy tree MUST be encoded as an order-independent list. There are two types of Bandwidth sub-TLVs (TBA by IANA), and the type values are defined in this doc, not in [RFC3630], so don't mix them up 🍓
- Type 1 - Unreserved Bandwidth for fixed containers
- Type 2 - Unreserved/MAX LSP Bandwidth for flexible containers
The Switching Capability specific information (SCSI) MUST include one Type 1 sub-TLV for each fixed container and one Type 2 sub-TLV for each variable container. Each container type is identified by a Signal Type, and Signal Type values are defined in [RFC7139] 🎀
For ODUflex, three different Signal Types are allowed:
20 - ODUflex(CBR) (i.e., 1.25*N Gbps)21 - ODUflex(GFP-F), resizable (i.e., 1.25*N Gbps)22 - ODUflex(GFP-F), non-resizable (i.e., 1.25*N Gbps)
where CBR stands for Constant Bit Rate and GFP-F stands for Generic Framing Procedure - Framed 🌈
Each MUST always be advertised in separate Type 2 sub-TLVs, because each one uses a different adaptation function [G.805] 🫶 In the case that both GFP-F resizable and non-resizable (i.e., 21 and 22) are supported, only Signal Type 21 SHALL be advertised, since this type also implies support for Type 22 adaptation. Type 21 carries the Type 22 energy too, periodt 👑
4.1.1. Switching Capability Specific Information for Fixed Containers
The format of the Bandwidth sub-TLV for fixed containers 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | Num of stages |T|S| TSG | Res | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1 | ... | Stage#N | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved ODUj at Prio 0 | ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved ODUj at Prio 7 | Unreserved Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Bandwidth Sub-TLV -- Type 1The values of the fields shown in Figure 3 are explained in Section 4.1.3 ✨
4.1.2. Switching Capability Specific Information for Variable Containers
The format of the Bandwidth sub-TLV for variable containers is depicted in the following figure:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 (Unres/MAX-var) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | Num of stages |T|S| TSG | Res | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1 | ... | Stage#N | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Bandwidth Sub-TLV -- Type 2The values of the fields shown in Figure 4 are explained in Section 4.1.3 🦋
4.1.3. Switching Capability Specific Information -- Field Values and Explanation ✨
Okay bestie, this is where we fill in every single field 💅 The fields in the Bandwidth sub-TLV MUST be filled as follows:
- Signal Type (8 bits): This is the ODU type being advertised 🎀 The values are defined in [RFC7139].
- Num of stages (8 bits): This tells you how many multiplexing stages are used to carry the Signal Type 🧚 It MUST be set to the number of stages represented in the sub-TLV.
- Flags (8 bits): Okay, the flags are where it gets spicy 🔥
- T Flag (bit 17): This says whether the advertised bandwidth can be terminated. If the Signal Type can be terminated, T MUST be set. If it can't be terminated, T MUST be cleared.
- S Flag (bit 18): This says whether the advertised bandwidth can be switched. If the Signal Type can be switched, S MUST be set. If it can't be switched, S MUST be cleared.
- Both the T bit and the S bit being 0 is a no-go. The value 0 in both the T bit and S bit MUST NOT be used. 💀
- TSG (3 bits): This is Tributary Slot Granularity 🦋 It's used to advertise the tributary slot granularity you support. The following values MUST be used:
0- Ignored1- 1.25 Gbps / 2.5 Gbps2- 2.5 Gbps only3- 1.25 Gbps only4-7- Reserved
Here's the tea ☕ A value of 1 MUST be used on interfaces that are configured to support the fallback procedures defined in [G.798]. A value of 2 MUST be used on interfaces that only support 2.5 Gbps tributary slots, such as [RFC4328] interfaces. A value of 3 MUST be used on interfaces that are configured to only support 1.25 Gbps tributary slots. A value of 0 MUST be used for non-multiplexed Signal Types (i.e., a non-OTN client). It's giving very strict vibes, and I'm obsessed 🫶
- Res (3 bits): These are reserved bits 🌸 They MUST be set to 0 and ignored on receipt.
- Priority (8 bits): This is a bitmap showing which priorities are being advertised 🌈 The bitmap is in ascending order. The leftmost bit represents priority level 0 (the highest), and the rightmost bit represents priority level 7 (the lowest). A bit MUST be set (1) for each priority represented in the sub-TLV, and it MUST NOT be set (0) when that priority is not represented. At least one priority level MUST be advertised that, unless overridden by local policy, SHALL be at priority level 0. Main character energy 👑
- Stage (8 bits): Each Stage field tells you a Signal Type in the multiplexing hierarchy that carries the signal named in the Signal Type field 🧚 The number of Stage fields included in a sub-TLV MUST equal the value of the Num of stages field. The Stage fields MUST be ordered to match the data plane in ascending order, going from the lowest order ODU to the highest order ODU. The values of the Stage field are the same as those defined for the Signal Type field. When the Num of stages field carries a 0, the Stage and Padding fields MUST be omitted. 🙈
- Example: For the
ODU1->ODU2->OD3hierarchy, the Signal Type field is set to ODU1 and two Stage fields are present. The first indicates ODU2 and the second indicates ODU3 (server layer). Iykyk 🍓
- Example: For the
- Padding (variable): This padding keeps the Stage fields 32-bit aligned 🎀 The Padding field length is always a multiple of 8 bits (1 byte). You can calculate its length, in bytes, like this:
4 - ( "value of Num of stages field" % 4)The Padding field MUST be set to a zero (0) value on transmission and MUST be ignored on receipt. 🫶
- Unreserved ODUj (16 bits): This field shows the Unreserved Bandwidth at a particular priority level ✨ It MUST be set to the number of ODUs at the indicated Signal Type for that priority level. One field MUST be present for each bit set in the Priority field, and the fields are ordered to match the Priority field. Fields MUST NOT be present for priority levels that aren't indicated in the Priority field. Not me reading all these MUSTs 😭
- Unreserved Padding (16 bits): This padding keeps the Unreserved ODUj fields 32-bit aligned 🦋 When it's present, the Unreserved Padding field is 16 bits (2 bytes) long. When the number of priorities is odd, the Unreserved Padding field MUST be included. When the number of priorities is even, the Unreserved Padding MUST be omitted.
- Unreserved Bandwidth (32 bits): This is the Unreserved Bandwidth at a particular priority level 💜 It MUST be set to the bandwidth, in bytes/second in IEEE floating point format, available at the indicated Signal Type for that priority level. One field MUST be present for each bit set in the Priority field, and the fields are ordered to match the Priority field. Fields MUST NOT be present for priority levels that aren't indicated in the Priority field.
- Maximum LSP Bandwidth (32 bits): This is the most bandwidth that can be allocated to a single LSP at a particular priority level 🔥 It MUST be set to the maximum bandwidth, in bytes/second in IEEE floating point format, available to a single LSP at the indicated Signal Type for that priority level. One field MUST be present for each bit set in the Priority field, and the fields are ordered to match the Priority field. Fields MUST NOT be present for priority levels that aren't indicated in the Priority field. The advertisement of the MAX LSP Bandwidth MUST take into account HO OPUk bit rate tolerance, and it gets calculated with this formula:
Max LSP BW = (# available TSs) * (ODTUk.ts nominal bit rate) * (1-HO OPUk bit rate tolerance)The math ate 🧮💖
5. Examples 🌸
The examples in the following pages are not normative and are not intended to imply or mandate any specific implementation. Just vibes, not rules 🦋
5.1. MAX LSP Bandwidth Fields in the ISCD 🦋
okay so this example is all about how the MAX LSP Bandwidth fields in the ISCD change as the TE-Link gets filled up 💅 we're looking at an OTU4 link that supports priorities 0, 2, 4, and 7, with the muxing hierarchy ODU1->ODU2->ODU3->ODU4 🌈
At time T0, the link is completely free, so the advertisement 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SwCap=OTN_TDM | Encoding = 12 | Reserved (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 0 = 100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 1 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 2 = 100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 3 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 4 = 100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 5 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 6 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 7 = 100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Capability Specific Information |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 5: MAX LSP Bandwidth Fields in the ISCD at T0
At time T1, an ODU3 at priority 2 gets set up 🎀 For priority 0, the MAX LSP Bandwidth is still equal to the ODU4 bandwidth. For priorities from 2 to 7 (excluding the non-supported ones), the MAX LSP Bandwidth is equal to ODU3, because no more ODU4s are available and the next supported ODUj in the hierarchy is ODU3. The advertisement gets updated 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SwCap=OTN_TDM | Encoding = 12 | Reserved (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 0 = 100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 1 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 2 = 40 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 3 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 4 = 40 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 5 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 6 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 7 = 40 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Capability Specific Information |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6: MAX LSP Bandwidth Fields in the ISCD at T1
At time T2, an ODU2 at priority 4 gets set up 🍓 The first ODU3 hasn't been available since T1 because the ODU3 LSP is holding it, and the second one is no longer available either, with just 3 ODU2s left in it. ODU2 is now the MAX LSP Bandwidth for priorities higher than 4. The advertisement gets updated 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SwCap=OTN_TDM | Encoding = 12 | Reserved (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 0 = 100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 1 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 2 = 40 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 3 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 4 = 10 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 5 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 6 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 7 = 10 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Capability Specific Information |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 7: MAX LSP Bandwidth Fields in the ISCD at T2
5.2. Example of T, S, and TS Granularity Utilization 🧚
this one's a whole vibe 🌈 We've got an interface with tributary slot type 1.25 Gbps and the fallback procedure enabled (TS granularity=1). It supports the simple ODU1->ODU2->ODU3 hierarchy and priorities 0 and 3. Say that on this interface, the ODU3 Signal Type can be both switched or terminated, the ODU2 can only be terminated, and the ODU1 can only be switched.
Heads up 👀 since the ODU1 isn't being advertised to support ODU0, the value of its TSG field is "ignored" (TS granularity=0).
To advertise what this interface can do, a single ISCD is used 💖 Here's its 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU1 | #stages= 2 |0|1| 0 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU2 | Stage#2=ODU3 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU1 at Prio 0 | Unres ODU1 at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU2 | #stages= 1 |1|0| 1 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU3 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU2 at Prio 0 | Unres ODU2 at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU3 | #stages= 0 |1|1| 1 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU3 at Prio 0 | Unres ODU3 at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 8: T, S, and TS Granularity Utilization
5.2.1. Example of Different TS Granularities 🎀
okay so this example is giving two interfaces with the same kind of hierarchy 💅 but different tributary slot types. The first one supports an [RFC4328] interface (TS granularity=2), and the second one supports a G.709-2012 interface with the fallback procedure disabled (TS granularity=3). Both of them do the ODU1->ODU2->ODU3 hierarchy and priorities 0 and 3 ✨. On this interface the ODU3 Signal Type can be both switched or terminated, the ODU2 can only be terminated, and the ODU1 can only be switched 🦋. To advertise all of this we use two different ISCDs, and their SCSIs look like this:
SCSI of ISCD 1 -- TS granularity=2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU1 | #stages= 2 |0|1| 0 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU2 | Stage#2=ODU3 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU1 at Prio 0 | Unres ODU1 at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU2 | #stages= 1 |1|0| 1 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU3 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU2 at Prio 0 | Unres ODU2 at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU3 | #stages= 0 |1|1| 2 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU3 at Prio 0 | Unres ODU3 at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 9: Utilization of Different TS Granularities -- ISCD 1
SCSI of ISCD 2 -- TS granularity=3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU1 | #stages= 2 |0|1| 0 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU2 | Stage#2=ODU3 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU1 at Prio 0 | Unres ODU1 at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU2 | #stages= 1 |1|0| 1 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU3 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU2 at Prio 0 | Unres ODU2 at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU3 | #stages= 0 |1|1| 3 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU3 at Prio 0 | Unres ODU3 at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 10: Utilization of Different TS Granularities -- ISCD 2
Hierarchies with the same muxing tree but with different exported TS granularity MUST be considered as non-homogenous hierarchies. 🚨 This is the case in which an H-LSP and the client LSP are terminated on the same egress node. What can happen is that a loose Explicit Route Object (ERO) is used at the hop where the signaled LSP is nested into the Hierarchical-LSP (H-LSP) (penultimate hop of the LSP).
In the following figure, node C receives a loose ERO from A; the ERO goes towards node E, and node C must choose between the ODU2 H-LSP on if1 or the one on if2. In this case, the H-LSP on if1 exports a TS=1.25 Gbps, and the H-LSP on if2 exports a TS=2.5 Gbps. Because the service LSP being signaled needs a 1.25 Gbps tributary slot, only the H-LSP on if1 can be used to reach node E 😭. For further details, please see Section 3.2 of [RFC7096].
ODU0-LSP
..........................................................+
| |
| ODU2-H-LSP |
| +-------------------------------+
| | |
+--+--+ +-----+ +-----+ if1 +-----+ +-----+
| | OTU3 | | OTU3 | |---------| |---------| |
| A +------+ B +------+ C | if2 | D | | E |
| | | | | |---------| |---------| |
+-----+ +-----+ +-----+ +-----+ +-----+
... Service LSP
--- H-LSP
Figure 11: Example of Service LSP and H-LSP Terminating
on the Same Node5.3. Example of ODUflex Advertisement 💖
okay now we're going into ODUflex land 🧚 where the advertisement of an ODUflex->ODU3 hierarchy is shown. For ODUflex advertisement, the MAX LSP Bandwidth needs to be advertised, and sometimes the Unreserved Bandwidth is useful too. Just know that the amount of Unreserved Bandwidth doesn't clearly tell you how many ODUflex LSPs you can set up, either at the MAX LSP Bandwidth or at other rates, because it says nothing about where the free TSs sit 🙈.
The Unreserved Bandwidth number could still be handy during path computation, so picture this. We've got two TE-Links (A and B), each with a MAX LSP Bandwidth of 10 Gbps. Link A has 50 Gbps of Unreserved Bandwidth available, Link B has 10 Gbps, and 3 ODUflex LSPs of 10 Gbps each need to be restored. For sure only one can be restored along Link B, and it's probable, but not certain, that two of them can be restored along Link A 👀. The T, S, and TSG fields are not relevant to this example, so they're filled with Xs.
In the case of ODUflex advertisement, the Type 2 Bandwidth sub-TLV is used.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 (Unres/MAX-var) | Length = 72 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S. type=ODUflex| #stages= 1 |X|X|X X X|0 0 0| Priority(8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU3 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 12: ODUflex Advertisement
5.4. Example of Single-Stage Muxing ✨
Okay so picture this 🦋 we've got 1 OTU4 component link doing single-stage muxing for ODU1, ODU2, ODU3, and ODUflex. The supported hierarchy looks like a little tree, which is so pretty 🌸 To keep things simple, we're only pretending priorities 0 and 3 are supported. The T, S, and TSG fields aren't relevant here, so they're just filled with Xs 💅
ODU1 ODU2 ODU3 ODUflex
\ \ / /
\ \ / /
\ \/ /
ODU4The related SCSIs look 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU4 | #stages= 0 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU4 at Prio 0 =1 | Unres ODU4 at Prio 3 =1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU1 | #stages= 1 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU1 at Prio 0 =40 | Unres ODU1 at Prio 3 =40 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU2 | #stages= 1 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU2 at Prio 0 =10 | Unres ODU2 at Prio 3 =10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU3 | #stages= 1 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU3 at Prio 0 =2 | Unres ODU3 at Prio 3 =2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 (Unres/MAX-var) | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S. type=ODUflex| #stages= 1 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 0 =100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 3 =100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 0 =100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 3 =100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 13: Single-Stage Muxing 🎀
5.5. Example of Multi-Stage Muxing -- Unbundled Link 🌈
Suppose there's 1 OTU4 component link with muxing capabilities, and it looks like this 👑
ODU2 ODU0 ODUflex ODU0
\ / \ /
| |
ODU3 ODU2
\ /
\ /
\ /
\ /
ODU4Again we're only looking at priorities 0 and 3 🧚 So the advertisement is made up of the following Bandwidth sub-TLVs. The T and S fields aren't relevant to this example, so they're filled with Xs ✨
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU4 | #stages= 0 |X|X| 1 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU4 at Prio 0 =1 | Unres ODU4 at Prio 3 =1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU3 | #stages= 1 |X|X| 1 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU3 at Prio 0 =2 | Unres ODU3 at Prio 3 =2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU2 | #stages= 1 |X|X| 1 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU2 at Prio 0 =10 | Unres ODU2 at Prio 3 =10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU2 | #stages= 2 |X|X| 0 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU3 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU2 at Prio 0 =8 | Unres ODU2 at Prio 3 =8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU0 | #stages= 2 |X|X| 0 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU3 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU0 at Prio 0 =64 | Unres ODU0 at Prio 3 =64 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU0 | #stages= 2 |X|X| 0 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU2 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU0 at Prio 0 =80 | Unres ODU0 at Prio 3 =80 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 (Unres/MAX-var) | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S.type=ODUflex | #stages= 2 |X|X| 0 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU2 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 0 =100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 3 =100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 0 =10 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 3 =10 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 14: Multi-Stage Muxing -- Unbundled Link 💖
5.6. Example of Multi-Stage Muxing -- Bundled Links 🍓
In this one we've got 2 OTU4 component links that share the same supported TS granularity and homogeneous muxing hierarchies 🫶 The muxing capabilities trees look like this:
Component Link#1 Component Link#2
ODU2 ODU0 ODU2 ODU0
\ / \ /
| |
ODU3 ODU3
| |
ODU4 ODU4Considering only supported priorities 0 and 3, the advertisement is as follows. The T, S, and TSG fields aren't relevant to this example, so they're filled with Xs 💅
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU4 | #stages= 0 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU4 at Prio 0 =2 | Unres ODU4 at Prio 3 =2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU3 | #stages= 1 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU3 at Prio 0 =4 | Unres ODU3 at Prio 3 =4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU2 | #stages= 2 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU3 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU2 at Prio 0 =16 | Unres ODU2 at Prio 3 =16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU0 | #stages= 2 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU3 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU0 at Prio 0 =128 | Unres ODU0 at Prio 3 =128 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 15: Multi-Stage Muxing -- Bundled Links 🦋
5.7. Example of Component Links with Non-Homogeneous Hierarchies
okay bestie, this one is giving mismatched besties who still make it work 🫶✨ we've got 2 OTU4 component links that both support the same TS granularity, but their muxing hierarchies are not the same at all. here are the muxing capability trees:
Component Link#1 Component Link#2
ODU2 ODU0 ODU1 ODU0
\ / \ /
| |
ODU3 ODU2
| |
ODU4 ODU4so we're only looking at supported priorities 0 and 3 💅 and the advertisement ends up with two different ISCDs, one for each hierarchy. the T, S, and TSG fields don't matter for this example, so they're just filled with Xs 🙈 here's the SCSI for each ISCD:
SCSI of ISCD 1 -- Component Link#1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU4 | #stages= 0 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU4 at Prio 0 =1 | Unres ODU4 at Prio 3 =1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU3 | #stages= 1 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU3 at Prio 0 =2 | Unres ODU3 at Prio 3 =2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU2 | #stages= 2 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU3 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU2 at Prio 0 =8 | Unres ODU2 at Prio 3 =8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU0 | #stages= 2 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU3 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU0 at Prio 0 =64 | Unres ODU0 at Prio 3 =64 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Multi-Stage Muxing -- Non-Homogeneous Hierarchies --
ISCD 1 SCSI of ISCD 2 -- Component Link#2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU4 | #stages= 0 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU4 at Prio 0 =1 | Unres ODU4 at Prio 3 =1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU2 | #stages= 1 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU2 at Prio 0 =10 | Unres ODU2 at Prio 3 =10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU1 | #stages= 2 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU2 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU1 at Prio 0 =40 | Unres ODU1 at Prio 3 =40 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU0 | #stages= 2 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU2 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU0 at Prio 0 =80 | Unres ODU0 at Prio 3 =80 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Multi-Stage Muxing -- Non-Homogeneous Hierarchies --
ISCD 26. OSPFv2 Scalability ✨
okay so the big question is whether this breaks OSPF scalability 😭 and the answer is a no-cap no! this document does not introduce OSPF scalability issues with respect to existing GMPLS encoding, and it does not require any modification to flooding frequency 💖 the encoding was also designed with bandwidth optimization in mind, specifically:
- Only unreserved and MAX LSP Bandwidth related to supported priorities are advertised.
- For fixed containers, only the number of available containers is advertised instead of the available bandwidth, so it only uses 16 bits per container instead of 32 (as per former GMPLS encoding). ✂️
if you want to shrink the data even more, it is RECOMMENDED to bundle component links with homogeneous hierarchies as described in [RFC4201] and illustrated in Section 5.6 🧚
7. Compatibility 🎀
this one is about playing nicely with the older crowd 🫶 all implementations of this document MAY also support advertisement as defined in [RFC4203]. but if a node supports both the [RFC4203] method and the one in this document, then implementations MUST support the configuration of which advertisement method is followed. which method gets picked is based on policy and is beyond the scope of this document 🌸 the whole point is that nodes using each method can find similar supporting nodes and compute paths using only the appropriate nodes, which is honestly so iconic.
8. Security Considerations 🔥
okay this section is serious, so no jokes here, but I'm still going to be dramatic about it 💀 this document extends [RFC4203]. As with [RFC4203], it specifies the contents of Opaque LSAs in OSPFv2. Opaque LSAs are not used for Shortest Path First (SPF) computation or normal routing, so the extensions specified here have no direct effect on IP routing. however, tampering with GMPLS TE LSAs may have an effect on the underlying transport (optical and/or Synchronous Optical Network - Synchronous Digital Hierarchy (SONET-SDH) network. [RFC3630] notes that the security mechanisms described in [RFC2328] apply to Opaque LSAs carried in OSPFv2. an analysis of the security of OSPF is provided in [RFC6863], and it applies to the extensions to OSPF as described in this document. any new mechanisms developed to protect the transmission of information carried in Opaque LSAs will also automatically protect the extensions defined in this document ✨
please refer to [RFC5920] for details on security threats; defensive techniques; monitoring, detection, and reporting of security attacks; and requirements. protect your network, bestie 🛡️💜
9. IANA Considerations 🌈
9.1. Switching Types
IANA has made the following assignment in the "Switching Types" section of the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" registry located at <http://www.iana.org/assignments/gmpls-sig-parameters>:
Value Name Reference
--------- -------------------------- ----------
110 OTN-TDM capable [RFC7138]the same kind of update has been applied to the IANA-GMPLS-TC-MIB at <https://www.iana.org/assignments/ianagmplstc-mib>, where this value:
OTN-TDM (110), -- Time-Division-Multiplex OTN-TDM capablehas been added to the IANAGmplsSwitchingTypeTC ::= TEXTUAL-CONVENTION syntax list 🦋
9.2. New Sub-TLVs
this document defines 2 new sub-TLVs that get carried in Interface Switching Capability Descriptors [RFC4203] with the Signal Type OTN-TDM 💅 each sub-TLV has a 16-bit type identifier (the T-field), and the same T-field values apply to the new sub-TLV.
IANA has created and will maintain a new sub-registry, the "Types for sub-TLVs of OTN-TDM SCSI (Switching Capability Specific Information)" registry under the "Open Shortest Path First (OSPF) Traffic Engineering TLVs" registry, see <http://www.iana.org/assignments/ospf-traffic-eng-tlvs>. the sub-TLV types are as follows:
Value Sub-TLV Reference
--------- -------------------------- ----------
0 Reserved [RFC7138]
1 Unreserved Bandwidth for [RFC7138]
fixed containers
2 Unreserved/MAX Bandwidth for [RFC7138]
flexible containers
3-65535 Unassignedtypes are to be assigned via Standards Action as defined in [RFC5226] 🍓
10. Contributors 🧚
big shoutout to everyone who helped build this 🫶 here are the contributors and their details:
Diego Caviglia
Ericsson
Via E. Melen, 77
Genova
Italy
EMail: diego.caviglia@ericsson.com
Dan Li
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
EMail: danli@huawei.com
Pietro Vittorio Grandi
Alcatel-Lucent
Via Trento, 30
Vimercate
Italy
EMail: pietro_vittorio.grandi@alcatel-lucent.com
Khuzema Pithewan
Infinera Corporation
140 Caspian CT.
Sunnyvale, CA
USA
EMail: kpithewan@infinera.com
Xiaobing Zi
Huawei Technologies
EMail: zixiaobing@huawei.com
Francesco Fondelli
Ericsson
EMail: francesco.fondelli@ericsson.com
Marco Corsi
EMail: corsi.marco@gmail.com
Eve Varma
Alcatel-Lucent
EMail: eve.varma@alcatel-lucent.com
Jonathan Sadler
Tellabs
EMail: jonathan.sadler@tellabs.com
Lyndon Ong
Ciena
EMail: lyong@ciena.com
Ashok Kunjidhapatham
EMail: akunjidhapatham@infinera.com
Snigdho Bardalai
EMail: sbardalai@infinera.com
Steve Balls
EMail: Steve.Balls@metaswitch.com
Jonathan Hardwick
EMail: Jonathan.Hardwick@metaswitch.com
Xihua Fu
EMail: fu.xihua@zte.com.cn
Cyril Margaria
EMail: cyril.margaria@nsn.com
Malcolm Betts
EMail: Malcolm.betts@zte.com.cn11. Acknowledgements 💖
the authors would like to thank Fred Gruman and Lou Berger for their valuable comments and suggestions 🌸
12. References ✨
12.1. Normative References ✨
okay bestie, these are the must-reads 📚 you need before this spec makes sense 💖
[G.709-2012] ITU-T, "Interface for the optical transport network",
Recommendation G.709/Y.1331, February 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic
Engineering (TE) Extensions to OSPF Version 2", RFC
3630, September 2003.
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201, October
2005.
[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4203, October 2005.
[RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Extensions for G.709 Optical
Transport Networks Control", RFC 4328, January 2006.12.2. Informative References 🌸
these ones are more like background reading 🧚 handy if you want the bigger picture, no cap
[G.798] ITU-T, "Characteristics of optical transport network
hierarchy equipment functional blocks", Recommendation
G.798, December 2012.
[G.805] ITU-T, "Generic functional architecture of transport
networks", Recommendation G.805, March 2000.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
[RFC6163] Lee, Y., Bernstein, G., and W. Imajuku, "Framework for
GMPLS and Path Computation Element (PCE) Control of
Wavelength Switched Optical Networks (WSONs)", RFC 6163,
April 2011.
[RFC6566] Lee, Y., Bernstein, G., Li, D., and G. Martinelli, "A
Framework for the Control of Wavelength Switched Optical
Networks (WSONs) with Impairments", RFC 6566, March
2012.
[RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security
According to the Keying and Authentication for Routing
Protocols (KARP) Design Guide", RFC 6863, March 2013.
[RFC7062] Zhang, F., Li, D., Li, H., Belotti, S., and D.
Ceccarelli, "Framework for GMPLS and PCE Control of
G.709 Optical Transport Networks", RFC 7062, November
2013.
[RFC7096] Belotti, S., Grandi, P., Ceccarelli, D., Ed., Caviglia,
D., and F. Zhang, "Evaluation of Existing GMPLS Encoding
against G.709v3 Optical Transport Networks (OTNs)", RFC
7096, January 2014.
[RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D.,
and K. Pithewan, "GMPLS Signaling Extensions for
Control of Evolving G.709 Optical Transport Networks",
RFC 7139, March 2014.Authors' Addresses 💖
meet the squad who wrote this 🫶 here's how to reach each of them
Daniele Ceccarelli (editor)
Ericsson
Via E.Melen 77
Genova - Erzelli
Italy
EMail: daniele.ceccarelli@ericsson.com
Fatai Zhang
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129
P.R. China
Phone: +86-755-28972912
EMail: zhangfatai@huawei.com
Sergio Belotti
Alcatel-Lucent
Via Trento, 30
Vimercate
Italy
EMail: sergio.belotti@alcatel-lucent.com
Rajan Rao
Infinera Corporation
140, Caspian CT.
Sunnyvale, CA-94089
USA
EMail: rrao@infinera.com
John E. Drake
Juniper
EMail: jdrake@juniper.net📦 where this page comes from
- ietf: rfc7138 2014-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms