RFC 7096
Evaluation of Existing GMPLS Encoding against G.709v3 Optical Transport Networks (OTNs)
RFC 7096: Evaluation of Existing GMPLS Encoding against G.709v3 Optical Transport Networks (OTNs) 🦋
okay bestie, let's get into it 💖 This doc is from the IETF (Internet Engineering Task Force), and it's an Informational RFC, so it's published for information, not as a standards-track spec. 🌸 The authors are S. Belotti (Ed.) and P. Grandi from Alcatel-Lucent, D. Ceccarelli (Ed.), D. Caviglia from Ericsson, and F. Zhang and D. Li from Huawei Technologies. It came out in January 2014 and its ISSN is 2070-1721. The header doesn't list anything it obsoletes or updates. 🧚
Abstract ✨
ITU-T recommendation G.709-2012 brought in new fixed and flexible Optical channel Data Unit (ODU) containers for Optical Transport Networks (OTNs). 🔥
This doc evaluates how well the existing Generalized Multiprotocol Label Switching (GMPLS) routing and signaling protocols match up against G.709 OTNs. 💅
Status of This Memo 🎀
This doc is not an Internet Standards Track spec. It's published just for information, periodt. 🧚
It's a product of the IETF and represents the community's consensus. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is a candidate for any level of Internet Standard, though. See Section 2 of RFC 5741 for the details. 🌈
Info about this doc's current status, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc7096. ⭐
Copyright Notice 💜
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. 🫶
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info as in effect on the publication date. Please read these carefully, because they spell out your rights and restrictions for this doc. 🙈 Code Components pulled out of this doc must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes. 💀
Table of Contents 🍓
1. Introduction ....................................................3
2. G.709 Mapping and Multiplexing Capabilities .....................4
3. Tributary Slot Granularity ......................................6
3.1. Data-Plane Considerations ..................................7
3.1.1. Payload Type and TS Granularity Relationship ........7
3.1.2. Fallback Procedure ..................................8
3.2. Control-Plane Considerations ...............................9
4. Tributary Port Number ..........................................13
5. Signal Type ....................................................13
6. Bit Rate and Tolerance .........................................15
7. Unreserved Resources ...........................................15
8. Maximum LSP Bandwidth ..........................................15
9. Distinction between Terminating and Switching Capabilities .....16
10. Priority Support ..............................................18
11. Multi-stage Multiplexing ......................................18
12. Generalized Label .............................................19
13. Security Considerations .......................................19
14. Contributors ..................................................20
15. Acknowledgements ..............................................20
16. References ....................................................20
16.1. Normative References .....................................20
16.2. Informative References ...................................211. Introduction 🦋
GMPLS routing ([RFC4203] [RFC5307]) and signaling ([RFC3473] [RFC4328]) give us the mechanisms for basic GMPLS control of Optical Transport Networks (OTNs), based on the 2001 revision of the G.709 spec [G.709-2001]. The 2012 revision of G.709 [G.709-2012] adds new OTN features that GMPLS doesn't support yet. 😭
This doc evaluates the existing GMPLS signaling and routing protocols against G.709 requirements. Background info and a framework for the GMPLS protocol extensions needed to support G.709 are in [RFC7062]. The routing and signaling extensions defined in [OTN-OSPF] and [OTN-RSVP] address the gaps this doc identifies. ✨
2. G.709 Mapping and Multiplexing Capabilities 🌸
The digital OTN-layered structure has two parts: the digital path layer (ODU) and the digital section layer (OTU). An OTU (Optical channel Transport Unit) section layer supports one ODU path layer as a client and gives monitoring capability for the Optical Channel (OCh), which is the optical path carrying the digital OTN structure. 💅 An ODU path layer can transport a heterogeneous assembly of ODU clients. Some ODUs (ODU1, ODU2, ODU3, and ODU4) can take on either a client or a server role inside a particular networking domain. The terms ODU1, ODU2, ODU3, ODU4, and flexible ODU (ODUflex) are explained in G.709. G.872 [G.872] gives two tables defining the mapping and multiplexing capabilities of OTNs, and they're reproduced below. 🧚
+--------------------+--------------------+
| ODU client | OTU server |
+--------------------+--------------------+
| ODU0 | - |
+--------------------+--------------------+
| ODU1 | OTU 1 |
+--------------------+--------------------+
| ODU2 | OTU 2 |
+--------------------+--------------------+
| ODU2e | - |
+--------------------+--------------------+
| ODU3 | OTU 3 |
+--------------------+--------------------+
| ODU4 | OTU 4 |
+--------------------+--------------------+
| ODUflex | - |
+--------------------+--------------------+
Figure 1: OTN Mapping Capability +=================================+=========================+
| ODU client | ODU server |
+---------------------------------+-------------------------+
| 1.25 Gbit/s client | |
+---------------------------------+ ODU0 |
| - | |
+=================================+=========================+
| 2.5 Gbit/s client | |
+---------------------------------+ ODU1 |
| ODU0 | |
+=================================+=========================+
| 10 Gbit/s client | |
+---------------------------------+ ODU2 |
| ODU0,ODU1,ODUflex | |
+=================================+=========================+
| 10.3125 Gbit/s client | |
+---------------------------------+ ODU2e |
| - | |
+=================================+=========================+
| 40 Gbit/s client | |
+---------------------------------+ ODU3 |
| ODU0,ODU1,ODU2,ODU2e,ODUflex | |
+=================================+=========================+
| 100 Gbit/s client | |
+---------------------------------+ ODU4 |
|ODU0,ODU1,ODU2,ODU2e,ODU3,ODUflex| |
+=================================+=========================+
|CBR* clients from greater than | |
|2.5 Gbit/s to 100 Gbit/s: or | |
|GFP-F** mapped packet clients | ODUflex |
|from 1.25 Gbit/s to 100 Gbit/s. | |
+---------------------------------+ |
| - | |
+=================================+=========================+
(*) - Constant Bit Rate
(**) - Generic Framing Procedure - Framed (GFP-F)
Figure 2: OTN Multiplexing CapabilityIn the next bit, the terms Optical channel Data Unit-j (ODUj) and Optical channel Data Unit-k (ODUk) are used in a multiplexing scenario to mean the lower order signal (ODUj) and the higher order signal (ODUk). 🌈 How an ODUk connection service gets carried inside an operator network is up to operator policy. For example, the ODUk connection service might ride an ODUk path over an Optical channel Transport Unit-k (OTUk) section, with the same path and section rates as the connection service (see Figure 1). In that case, a whole lambda of capacity gets eaten up by the ODUk connection service. 💀 On the other hand, the operator might use different multiplexing capabilities in the network to boost infrastructure efficiency within any given networking domain. Then ODUk multiplexing may happen before transport over various rate ODU servers (per Figure 2) over associated OTU sections. 👑
From the multiplexing point of view, a given ODUk can play different roles as it goes through various networking domains. 🫶
As detailed in [RFC7062], client ODUk connection services can be transported over:
- Case A: one or more wavelength subnetworks connected by optical links, or
- Case B: one or more ODU links (having sub-lambda and/or lambda bandwidth granularity), or
- Case C: a mix of ODU links and wavelength subnetworks.
This doc looks at the Traffic Engineering (TE) info needed for ODU path computation, and at the parameters that need to be signaled for Label Switched Path (LSP) setup. 🎀
The following sections list and analyze what GMPLS already has and what it's missing for each type of data that needs to be advertised and signaled. 🔥
3. Tributary Slot Granularity 💖
G.709 defines two types of Tributary Slot (TS) granularities. This TS granularity is defined per layer, which means both ends of a link can pick the proper TS granularity differently for each supported layer, based on these rules: 🧚
- If both ends of a link are new cards supporting both 1.25 Gbit/s TS and 2.5 Gbit/s TS, then the link will work with 1.25 Gbit/s TS. ✨
- If one end of a link is a new card supporting both the 1.25 Gbit/s and 2.5 Gbit/s TS granularities, and the other end is an old card supporting just the 2.5 Gbit/s TS granularity, the link will work with 2.5 Gbit/s TS granularity. 🙈
3.1. Data-Plane Considerations 🌷
3.1.1. Payload Type and TS Granularity Relationship ✨
Okay so, as G.709 defines it, an ODUk container is an Optical channel Payload Unit-k (OPUk) plus a specific ODUk Overhead (OH) 🎀. OPUk OH info gets added to the OPUk information payload to make an OPUk, and it carries the stuff needed to support adapting client signals. Inside the OPUk overhead sits the payload structure identifier (PSI), which includes the payload type (PT). The PT tells you what the OPUk signal is made of 💅. When an ODUj signal gets multiplexed into an ODUk, the ODUj is first extended with the frame alignment overhead and then mapped into an Optical channel Data Tributary Unit (ODTU). There are two different types of ODTUs:
ODTUjk ((j,k) = {(0,1), (1,2), (1,3), (2,3)}; ODTU01, ODTU12, ODTU13, and ODTU23), where an ODUj signal is mapped via the Asynchronous Mapping Procedure (AMP), as defined in Section 19.5 of [G.709-2012]. 🦋ODTUk.ts ((k,ts) = (2,1..8), (3,1..32), (4,1..80)), where a lower order ODU (ODU0, ODU1, ODU2, ODU2e, ODU3, and ODUflex) signal is mapped via the Generic Mapping Procedure (GMP), as defined in Section 19.6 of [G.709-2012]. 🌸
G.709 also brings in a logical entity called the Optical channel Data Tributary Unit Group (ODTUGk), which covers how the various ODTUs get multiplexed together. The ODTUGk then gets mapped into the OPUk. ODTUjk and ODTUk.ts are both directly time-division multiplexed into the tributary slots of an OH OPUk. It's giving organised chaos but make it make sense 🧚
When the PT is 0x20 or 0x21, combined with the OPUk type (k=1, 2, 3, 4), it's what tells the two different ODU multiplex structures for ODTUGx apart 👑:
0x20: supporting ODTUjk only0x21: supporting ODTUk.ts or ODTUk.ts and ODTUjk
This distinction matters for OPUk with k=2 or 3, since OPU2 and OPU3 can support both of the different ODU multiplex structures 🫶. For OPU4 and OPU1, only one type of ODTUG is supported: ODTUG4 with PT=0x21 and ODTUG1 with PT=0x20 (see Figure 6). The reason PT and TS granularity are linked is that the two different ODTUGk types, which are told apart by PT and OPUk, are characterised by two different TS granularities of the related OPUk. The former is at 2.5 Gbit/s and the latter is at 1.25 Gbit/s 🔥.
To complete the picture, the PSI OH also contains the Multiplex Structure Identifier (MSI). The MSI tells you which tributary slots of the different ODTUjk or ODTUk.ts are mapped into the related OPUk 💜. Here's how client traffic gets multiplexed all the way up to the OPUk layer 🍓:
+--------+ +------------+
+----+ | !------| ODTUjk |-----Client
| | | ODTUGk | +-----.------+
| |-----| PT=0x21| .
| | | | +-----.------+
| | | |------| ODTUk.ts |-----Client
|OPUk| +--------+ +------------+
| |
| | +--------+ +------------+
| | | |------| ODTUjk |-----Client
| |-----| | +-----.------+
+----+ | ODTUGk | .
| PT=0x20| +-----.------+
| |------| ODTUjk |-----Client
+--------+ +------------+
Figure 3: OTN Client Multiplexing3.1.2. Fallback Procedure 🦋
Okay, so [G.798] describes the so-called PT=0x21-to-PT=0x20 interworking process 🌈. It explains how two nodes whose interfaces have different payload types, and therefore different TS granularity (1.25 Gbit/s vs. 2.5 Gbit/s), can coordinate so the equipment with 1.25 Gbit/s TS granularity adapts its TS allocation to the different TS granularity (2.5 Gbit/s) of a neighbour. It's a whole coordination moment 🤝.
So, to let the Network Element (NE) change its TS granularity to match what the neighbours need, the AUTOpayloadtype [G.798] needs to be set. When both neighbours (link or trail) have been configured as structured, the payload type received in the overhead gets compared to the transmitted PT. If they're different and the transmitted one is PT=0x21, the node must fall back to PT=0x20. In this case the fallback process makes the system self-consistent, and the only reason left for signalling the TS granularity is to provide the correct label (the label for PT=0x21 has twice the TS number of PT=0x20) ✨. On the other side, if AUTOpayloadtype is not configured, the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) consequent actions need to be defined in case of a TS mismatch 💀.
3.2. Control-Plane Considerations ✨
okay so when you set up an ODUj over an ODUk, there are actually two kinds of TS granularity (TSG) to keep track of, the server one and the client one 🎀. The server TS granularity is what maps an end-to-end ODUj onto a server ODUk LSP or links. The ODUj itself has zero say in this one 💅. The ODUj LSP just gets mapped onto whatever tributary slots are free on the different links / ODUk LSPs. So when you set up an ODUj at a given rate, whether the path is made of links / Forwarding Adjacencies (FAs) running at 1.25 Gbit/s or 2.5 Gbit/s TS granularity is totally invisible to the end-to-end ODUj 🦋.
The client TS granularity is different. It's one of the parameters needed to pick the right adaptation towards the client layers at the end nodes, and that's literally the only thing the ODUj has to guarantee 🫶.
Figure 4 shows what this looks like in a mixed scenario with OTN [RFC4328] and OTN interfaces [G.709-2012] 👀:
ODU1-LSP
.........................................
TSG-C| |TSG-C
1.25| ODU2-H-LSP |1.25 Gbit/s
Gbit/s+------------X--------------------------+
| TSG-S| |TSG-S
| 2.5| |2.5 Gbit/s
| Gbit/s| ODU3-H-LSP |
| |------------X-------------|
| | |
+--+--+ +--+--+ +---+-+
| | | | +-+ +-+ | |
| A +------+ B +-----+ +***+ +-----+ Z |
| V.3 | OTU2 | V.1 |OTU3 +-+ +-+ OTU3| V.3 |
+-----+ +-----+ +-----+
... Service LSP
--- Hierarchical-LSP (H-LSP)
Figure 4: Client-Server TS Granularity ExampleSo in this setup, an ODU3 LSP gets set up from nodes B to Z 💜. Node B has an old interface that can only do 2.5 Gbit/s TS granularity, which means only a client TS granularity of 2.5 Gbit/s can be exported to ODU3 H-LSP-possible clients 🙈. Then an ODU2 LSP gets set up from nodes A to Z with a client TS granularity of 1.25 Gbit/s signaled and exported towards clients. That ODU2 LSP rides inside the ODU3 H-LSP from B to Z. But because of the limits on node B's old interface, the ODU2 LSP ends up mapped with 2.5 Gbit/s TS granularity over the ODU3 H-LSP 💀. And last but not least, an ODU1 LSP gets set up from A to Z, carried by the ODU2 H-LSP and mapped over it using 1.25 Gbit/s TS granularity 🌈.
The big takeaway is that TS granularity processing is a per-layer thing 🧚. Even if the ODU3 H-LSP is created with a TS granularity client of 2.5 Gbit/s, the ODU2 H-LSP still has to guarantee a 1.25 Gbit/s TS granularity client 😭. The ODU3 H-LSP is eligible from an ODU2 LSP's perspective because routing tells us this ODU3 interface at node Z supports an ODU2 termination that exports a TS granularity of 1.25 Gbit/s / 2.5 Gbit/s ✨.
Routing needs TS granularity info too 🍓, since the ingress node (A in the example above) has to know whether the interfaces at the last hop can support the required TS granularity. If they can't, A will compute an alternate path from itself to Z (see Figure 4) 🏃♀️.
Signaling needs it too! Take the setup of an ODU3 forwarding adjacency that's going to carry an ODU0, which means 1.25 Gbit/s TS support is needed 🔥. The TS granularity info has to ride along in the signaling so that node C (see Figure 5) can pick the right one among the different interfaces (with different TS granularities) towards D. If the full Explicit Route Object (ERO) is provided in the signaling with an explicit interface declaration, then C doesn't have to choose the interface towards D at all, because the ingress node or the Path Computation Element (PCE) already decided that 👑.
ODU3
<---------------------->
ODU0
<-------------------------------------->
| |
+--------+ +--------+ +--------+ +--------+
| | | | | | 1.25 | |
| Node | | Node | | Node +------+ Node |
| A +------+ B +------+ C | ODU3 | D |
| | ODU3 | | ODU3 | +------+ |
+--------+ 1.25 +--------+ 2.5 +--------+ 2.5 +--------+
Figure 5: TS Granularity in SignalingNow, if an ODUk FA_LSP needs to be set up as nesting another ODUj (like in Figure 5), you might need to know the hierarchy of the nested LSPs as well as the TS granularity 🧠. That's so the penultimate hop (i.e., C) can choose the correct interface towards the egress node, or so any intermediate node (i.e., B) can choose the right path while doing the ERO expansion. You don't need this if you only allow bundling of component links with homogeneous hierarchies 🫧. And if a specific implementation doesn't specify the last hop interface in the ERO, crankback can be a solution 🔄.
In a multi-stage multiplexing environment, any layer can have a different TS granularity structure 🦋. For example, in a multiplexing hierarchy like ODU0->ODU2->ODU3, the ODU3 can be structured at TS granularity = 2.5 Gbit/s in order to support an ODU2 connection. But that ODU2 connection can be a tunnel for ODU0, and so it's structured with 1.25 Gbit/s TS granularity. Which means every multiplexing level has to advertise its TS granularity capabilities so the end nodes can do correct path computation (both for the ODUk trail and the H-LSP/FA) 💅.
The table below shows the different mapping possibilities depending on TS granularity types 🌸. The client types are in the left column, and the OPUk server types with their related TS granularities are across the top row. It also shows how TS granularity relates to the payload type 💜.
+------------------------------------------------+
| 2.5 Gbit/s TS || 1.25 Gbit/s TS |
| OPU2 | OPU3 || OPU1 | OPU2 | OPU3 | OPU4 |
+-------+------------------------------------------------+
| | - | - || AMP | GMP | GMP | GMP |
| ODU0 | | ||PT=0x20|PT=0x21|PT=0x21|PT=0x21|
+-------+------------------------------------------------+
| | AMP | AMP || - | AMP | AMP | GMP |
| ODU1 |PT=0x20|PT=0x20|| |PT=0x21|PT=0x21|PT=0x21|
+-------+------------------------------------------------+
| | - | AMP || - | - | AMP | GMP |
| ODU2 | |PT=0x20|| | |PT=0x21|PT=0x21|
+-------+------------------------------------------------+
| | - | - || - | - | GMP | GMP |
| ODU2e | | || | |PT=0x21|PT=0x21|
+-------+------------------------------------------------+
| | - | - || - | - | - | GMP |
| ODU3 | | || | | |PT=0x21|
+-------+------------------------------------------------+
| | - | - || - | GMP | GMP | GMP |
| ODUfl | | || |PT=0x21|PT=0x21|PT=0x21|
+-------+------------------------------------------------+
Figure 6: ODUj into OPUk Mapping Types
(Source: [G.709-2012], Tables7-10)Specific info can be defined to carry the multiplexing hierarchy and adaptation information (i.e., TS granularity / PT and AMP / GMP) so paths can be picked super precisely 🎯. That way, when the penultimate node (or the intermediate node doing the ERO expansion) gets that object along with the Traffic Parameters Object, it can choose the correct interface towards the egress node ✨.
So, to wrap this up 🎀: both routing and signaling need to be extended to properly represent the TS granularity/PT info. Routing has to represent a link's TS granularity and PT capabilities, plus the supported multiplexing hierarchy. Signaling has to represent the TS granularity/PT and multiplexing hierarchy encoding 🫶.
4. Tributary Port Number 🦋
okay this one's a little more niche but still iconic 💅. [RFC4328] only supports the deprecated auto-MSI mode, which assumes the Tributary Port Number (TPN) gets assigned automatically in the transmit direction and isn't checked in the receive direction 🙈.
As described in [G.709-2012] and [G.798], the OPUk overhead in an OTUk frame has n MSI bytes (in multiframe form) 📦, where n is the total number of TSs of the ODUk. Each of those bytes is used to indicate the association between the TPN and a TS of the ODUk 🔢.
The association between the TPN and TS has to be configured by the control plane and checked by the data plane on each side of the link 🫶. (Please refer to [RFC7062] for further details 📚.) Which means RSVP-TE signaling needs to be extended to support the TPN assignment function 🔥.
5. Signal Type ✨
okay so bestie, let's talk about signal types 💅 From a routing point of view, GMPLS OSPF [RFC4203] and GMPLS IS-IS [RFC5307] only let you advertise interfaces [RFC4328] as a single TS type. That means they can't tell you the exact bandwidth allocation. Say you're doing link bundling. If you divide the unreserved bandwidth by the MAX LSP bandwidth, you still can't know how many LSPs at MAX LSP bandwidth size you can actually set up (see the example in Figure 3) 🙈
That missing spatial info is a huge problem for restoration 😭 When nobody knows what's free, you get tons more crankbacks, and network convergence time takes a hit. Not iconic at all.
It gets messier. [RFC4203] and [RFC5307] can only advertise signal types that are either fixed bandwidth with an implicit hierarchy (think Synchronous Digital Hierarchy (SDH) networks / Synchronous Optical Networks (SONETs)) or variable bandwidth with no hierarchy (think packet switching networks). They don't give you a way to advertise a mixed approach, like ODUflex Constant Bit Rate (CBR) and ODUflex packet together ✨
Here's a good example. Say you advertise ODU0 as MIN LSP bandwidth and ODU4 as MAX LSP bandwidth. Now you can't tell if the link supports "ODU4 and ODUflex" or "ODU4, ODU3, ODU2, ODU1, ODU0, and ODUflex." That's a whole mess 🌀 SDH doesn't have this problem because its hierarchy is implicit and it has no flexible containers like ODUflex. The fix would be to declare one Interface Switching Capability Descriptor (ISCD) for each signal type the link actually supports 🎀
For instance, say there's an equivalent ODU2 unreserved bandwidth in a TE link (with bundling capability) spread across 4 ODU1s. It would get advertised in the ISCD like this:
MAX LSP Bandwidth: ODU1
MIN LSP Bandwidth: ODU1
- Maximum Reservable Bandwidth (of the bundle) set to ODU2
- Unreserved Bandwidth (of the bundle) set to ODU2So basically, the routing extensions in [RFC4203] and [RFC5307] need a different ISCD for every signal type just to advertise each supported container. That's exactly why we need to find a more optimized solution that doesn't spam a bunch of ISCDs 🦋
Quick detour on OSPF. Per [RFC2328], OSPF messages get sent directly inside IP datagrams, and they rely on IP fragmentation when a packet is bigger than the network's MTU. [RFC2328] says "IP fragmentation should be avoided whenever possible," which further limits our options. OSPF also has no generic way to fragment OSPF Link State Advertisements (LSAs). And even in IP environments, IS-IS [RFC1195] doesn't support message sizes bigger than a link's maximum frame size 😬
Then there's link bundling [RFC4201]. Using the ISCD as it is won't let you precisely advertise spatial bandwidth allocation information, unless each TE link has only one component link 💀
On the signaling side, [RFC4328] describes GMPLS signaling extensions for controlling G.709 OTNs defined before 2011 [G.709-2001]. But [RFC4328] needs an update, because it doesn't have a way to signal all the new signal types and related mapping and multiplexing functionalities. Literally a glow-up waiting to happen ✨
6. Bit Rate and Tolerance 🌸
In the current traffic parameters signaling, bit rate and tolerance are implicitly defined by the signal type. ODUflex CBR and ODUflex packet can have variable bit rates (please refer to [RFC7062], Table 2), so traffic parameters signaling needs an upgrade 🦋
Tolerance is actually fine, though. We don't need to upgrade GMPLS protocols for it, since each signal type already has a fixed value: +/-100 parts per million (ppm) or +/-20 ppm, depending on the signal type. Main character energy for the protocols, no cap 💜
7. Unreserved Resources 🧚
Unreserved resources need to be advertised per priority and per signal type so that restoration can work properly 🔥 [RFC4203] only lets you advertise unreserved resources per priority, which leaves you guessing how many LSPs of a specific signal type can be restored. Let's look at this scenario:
+------+ component link 1 +------+
| +------------------+ |
| | component link 2 | |
| N1 +------------------+ N2 |
| | component link 3 | |
| +------------------+ |
+------+ +---+--+
Figure 7: Concurrent Path ComputationSay a TE link is made of three ODU3 component links. The first has 32 TSs available, the second has 24, and the third has 24. It supports ODU2 and ODU3 signal types. The node would advertise a TE link with unreserved bandwidth equal to 80 TSs and a MAX LSP bandwidth equal to 32 TSs. Now imagine restoration tries to bring back two ODU3s (64 TSs) on that TE link. Only a single ODU3 can actually be set up, so a crankback happens 😭 In more complicated networks, the number of crankbacks can get way higher.
8. Maximum LSP Bandwidth 💖
Right now, maximum LSP bandwidth is advertised per priority in the common part of the ISCD. Section 5 covers some of the problems with advertising OTN information using ISCDs and points out the need for a more optimized solution. It's strictly not required, but this optimization effort should also look at how the per-priority maximum LSP bandwidth gets advertised for both fixed and variable ODU types 💅
9. Distinction between Terminating and Switching Capabilities 🦋
The capability an interface advertises needs more detail, so we can separate terminating capabilities from switching capabilities. Because of internal constraints and/or limitations, the signal an interface advertises could be just switched (forwarded to the switching matrix without multiplexing/demultiplexing), just terminated (demultiplexed), or both. The figures below help make this clearer 🎀
MATRIX LINE INTERFACE
+-----------------+ +-----------------+
| +-------+ | ODU2 | |
----->| ODU2 |----|----------|--------\ |
| +-------+ | | +----+ |
| | | \__/ |
| | | \/ |
| +-------+ | ODU3 | | ODU3 |
----->| ODU3 |----|----------|------\ | |
| +-------+ | | \ | |
| | | \| |
| | | +----+ |
| | | \__/ |
| | | \/ |
| | | ---------> OTU3
+-----------------+ +-----------------+
Figure 8: Switching and Terminating CapabilitiesThe example in the figure shows a line interface that can:
- Multiplex an ODU2 coming from the switching matrix into an ODU3 and map it into an OTU3
- Map an ODU3 coming from the switching matrix into an OTU3
In this case, the interface bandwidth advertised is ODU2 with switching capability, and ODU3 with both switching and terminating capabilities 💜
This info needs to be advertised together with the related unreserved bandwidth and signal type. As a result, signaling must be able to set up an LSP, so that local resource selection stays consistent with the limits considered during path computation 🫶
Figure 9 and Figure 10 show two more examples of terminating/switching differentiation. In both examples, every node only supports single-stage capability 🌈
Figure 9 is a scenario where a failure on link B-C forces node A to calculate another ODU2 LSP carrying ODU0 service along nodes B-E-D. Because node D is single stage capable, it can only extract the ODU0 service from the ODU2 interface. Node A needs to know that there's an available OTU2 link from E to D, which node D can use to extract the ODU0 service. This is needed so the path computation doesn't consider the OTU3 link ✨
ODU0 Transparently Transported
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| ODU2 LSP Carrying ODU0 Service |
| |'''''''''''''''''''''''''''''''''''''''''''| |
| | | |
| +----++ OTU2 +-----+ OTU2 +-----+ OTU2 ++----+ |
ODU0 | | Link | | Link | | Link | | ODU0
---->| A |_________| B |_________| C |_________| D |---->
| | | | | | | |
+-----+ +--+--+ +-----+ ++--+-+
| | |
OTU3| | |
Link| +-----+__________________| |
| | | OTU3 Link |
|____| E | |
| |_____________________|
+-----+ OTU2 Link
Figure 9: Switching and Terminating Capabilities - Example 1Figure 10 covers a scenario where the ODU2 LSP (A-B-C-D) needs to be restored. The two bundled component links between B and E could be used, but the ODU2 over the OTU2 component link can only be terminated, not switched. That means it can't be used to restore the ODU2 LSP (A-B-C-D). However, that ODU2 unreserved bandwidth must be advertised, because it can be used for a different ODU2 LSP terminating on E, e.g., F-B-E. Node A needs to know that the ODU2 capability on the OTU2 link can only be terminated, and that restoring A-B-C-D can only be done using the ODU2 bandwidth available on the OTU3 link 🎀
ODU0 Transparently Transported
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| ODU2 LSP Carrying ODU0 Service |
| |'''''''''''''''''''''''''''''''''''''''''''| |
| | | |
| +----++ OTU2 +-----+ OTU2 +-----+ OTU2 ++----+ |
ODU0 | | Link | | Link | | Link | | ODU0
---->| A |_________| B |_________| C |_________| D |---->
| | | | | | | |
+-----+ ++-+-++ +-----+ +--+--+
| | | |
OTU2| | | |
+-----+ Link| | | OTU3 +-----+ |
| | | | | Link | | |
| F |_______| | |___________| E |___________|
| | |_____________| | OTU2 Link
+-----+ OTU2 Link +-----+
Figure 10: Switching and Terminating Capabilities - Example 2The issue above is analyzed in an OTN context, but it's really a general, technology-independent GMPLS limitation 🌸
10. Priority Support ✨
okay so [RFC4202] defines eight priorities for resource availability and usage 💅 but here's the tea: each one gets advertised whether or not the network actually supports it, even the priorities that aren't supported at all 🙈 same as Section 8, fixing that inefficiency is not required to support OTNs. Still, any inefficiency like this should also be considered as part of the optimization effort from Section 5 🔥
11. Multi-stage Multiplexing 🦋
With reference to [RFC7062], multi-stage multiplexing means you also have to advertise cascaded adaptation capabilities, along with the matrix access constraints 🌸 The IETF's structure for advertising adaptation capabilities is the Interface Adaptation Capability Descriptor (IACD), as defined in [RFC6001] 🫶
Routing-wise, there's a big deal here 👀 In a multi-stage multiplexing hierarchy (e.g., ODU1->ODU2->ODU3), you don't just need the ODUk/OTUk bandwidth (ODU3) and the service-layer bandwidth (ODU1). You also need the intermediate one (ODU2) ✨ It's a classic case of a spatial allocation problem, and honestly it's giving puzzle energy 🧩
Let's say you get this advertisement:
Hierarchy: ODU1->ODU2->ODU3
Number of ODU1==5So the number of ODU1s suggests you might be able to get an ODU2 FA, but it totally depends on where those ODU1s are spatially allocated 💭
Picture this: two links are bundled together, and one component link has three ODU1->ODU2->ODU3 paths while the other has two. In that case, the ODU2 FA could not be set up 😭 With an ODU1 spatial allocation of (3+2), the ODU2 available bandwidth is 0 (no ODU2 FA can be created). With (4+1), the ODU2 available bandwidth is 1 (one ODU2 FA can be created). Same five ODU1s, totally different outcomes, periodt 💀 That's why the ODU2 has to be advertised.
All of this means both the ISCD and the IACD need to be augmented 🎀
12. Generalized Label 🧚
The ODUk label format defined in [RFC4328] could be updated to support new signal types defined in [G.709-2012] 💖 But honestly? Making it support possible future signal types would be hard, and that's the problem 😩
It also has scalability issues, because signaling large LSPs can need a huge number of labels 🍓 For example, when an ODU3 is mapped into an ODU4 with 1.25 Gbit/s tributary slots, you'd need 31 labels (31*4*8=992 bits) to be allocated. An ODUflex into an ODU4 may need up to 80 labels (80*4*8=2560 bits). Wild, right? 😵
So a new flexible and scalable ODUk label format needs to be defined ✨👑
13. Security Considerations 🔐
This document checks OTN requirements against the actual routing ([RFC4202], [RFC4203], and [RFC5307]) and signaling mechanisms ([RFC3471], [RFC3473], and [RFC4328]) in GMPLS. Serious and important, bestie 🫶
It defines new types of information that describe OTN containers and hierarchies. It does not define any new protocol elements. From a security standpoint, this memo does not introduce further risks regarding the information that can already be conveyed via GMPLS protocols. For a general discussion of MPLS and GMPLS security issues, check out the MPLS/GMPLS security framework in [RFC5920] 🛡️
Yes, this section is a bit of a lowkey plot twist, but it's the most important one for keeping everything safe 🚨
14. Contributors 💜
Jonathan Sadler
Tellabs
EMail: jonathan.sadler@tellabs.com
John Drake
Juniper
EMail: jdrake@juniper.net
Francesco Fondelli
Ericsson
Via Moruzzi 1
Pisa - 56100
EMail: francesco.fondelli@ericsson.com15. Acknowledgements 🌈
The authors would like to thank Lou Berger, Eve Varma, and Sergio Lanzone for their precious collaboration and review 🥰🫶
16. References 📚
16.1. Normative References
[G.709-2001] ITU-T, "Interfaces for the Optical Transport Network
(OTN)", G.709/Y.1331 Recommendation, February 2001.
[G.709-2012] ITU-T, "Interfaces for the Optical Transport Network
(OTN)", G.709/Y.1331 Recommendation, February 2012.
[G.798] ITU-T, "Characteristics of Optical Transport Network
Hierarchy Equipment Functional Blocks", G.798
Recommendation, December 2012.
[G.872] ITU-T, "Architecture of Optical Transport Networks",
G.872 Recommendation, October 2012.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January
2003.
[RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, 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.
[RFC5307] Kompella, K. and Y. Rekhter, "IS-IS Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 5307, October 2008.
[RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K.,
Brungard, D., and JL. Le Roux, "Generalized MPLS
(GMPLS) Protocol Extensions for Multi-Layer and
Multi-Region Networks (MLN/ MRN)", RFC 6001, October
2010.16.2. Informative References
[OTN-OSPF] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R.,
and J. Drake, "Traffic Engineering Extensions to OSPF
for Generalized MPLS (GMPLS) Control of Evolving G.709
OTN Networks", Work in Progress, December 2013.
[OTN-RSVP] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D.,
and K. Pithewan, "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Extensions for the evolving
G.709 Optical Transport Networks Control", Work in
Progress, September 2013.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
1998.
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link
Bundling in MPLS Traffic Engineering (TE)", RFC 4201,
October 2005.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
[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.Authors' Addresses 🎀
Sergio Belotti (editor)
Alcatel-Lucent
Via Trento, 30
Vimercate
Italy
EMail: sergio.belotti@alcatel-lucent.com
Pietro Vittorio Grandi
Alcatel-Lucent
Via Trento, 30
Vimercate
Italy
EMail: pietro_vittorio.grandi@alcatel-lucent.com
Daniele Ceccarelli (editor)
Ericsson
Via A. Negrone 1/A
Genova - Sestri Ponente
Italy
EMail: daniele.ceccarelli@ericsson.com
Diego Caviglia
Ericsson
Via A. Negrone 1/A
Genova - Sestri Ponente
Italy
EMail: diego.caviglia@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
Dan Li
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129
P.R. China
Phone: +86-755-28973237
EMail: danli@huawei.comThat's the whole RFC, bestie! 🌈✨ You made it through all five parts 🥹👑
📦 where this page comes from
- ietf: rfc7096 2014-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms