RFC 6163
Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs)
Part 1 of 10 🎀
RFC 6163 💖 Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs)
Okay, this one is from the IETF and it's an Informational doc, so it's a guide, not a standard 🫶. It was published in April 2011 and got an ISSN of 2070-1721. The authors are Y. Lee, Ed. from Huawei, G. Bernstein, Ed. from Grotto Networking, and W. Imajuku from NTT. The title block doesn't list anything it obsoletes or updates, so it stands on its own ✨.
Abstract ✨
This doc gives a framework for using Generalized Multi-Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to control Wavelength Switched Optical Networks (WSONs). The main focus is Routing and Wavelength Assignment (RWA) of optical paths 🌈.
It sticks to the topological elements and path selection constraints that show up across different WSON setups, so it does not go deep into optical impairments. Not a flaw, just a scope choice 💅.
Status of This Memo
This document is not an Internet Standards Track specification. It's published for informational purposes 🦋.
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🤓.
For the latest status, errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6163 🔗.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved 💜.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 📜.
Table of Contents
1. Introduction ....................................................4
2. Terminology .....................................................5
3. Wavelength Switched Optical Networks ............................6
3.1. WDM and CWDM Links .........................................6
3.2. Optical Transmitters and Receivers .........................8
3.3. Optical Signals in WSONs ...................................9
3.3.1. Optical Tributary Signals ..........................10
3.3.2. WSON Signal Characteristics ........................10
3.4. ROADMs, OXCs, Splitters, Combiners, and FOADMs ............11
3.4.1. Reconfigurable Optical Add/Drop
Multiplexers and OXCs ..............................11
3.4.2. Splitters ..........................................14
3.4.3. Combiners ..........................................15
3.4.4. Fixed Optical Add/Drop Multiplexers ................15
3.5. Electro-Optical Systems ...................................16
3.5.1. Regenerators .......................................16
3.5.2. OEO Switches .......................................19
3.6. Wavelength Converters .....................................19
3.6.1. Wavelength Converter Pool Modeling .................21
3.7. Characterizing Electro-Optical Network Elements ...........24
3.7.1. Input Constraints ..................................25
3.7.2. Output Constraints .................................25
3.7.3. Processing Capabilities ............................26
4. Routing and Wavelength Assignment and the Control Plane ........26
4.1. Architectural Approaches to RWA ...........................27
4.1.1. Combined RWA (R&WA) ................................27
4.1.2. Separated R and WA (R+WA) ..........................28
4.1.3. Routing and Distributed WA (R+DWA) .................28
4.2. Conveying Information Needed by RWA .......................29
5. Modeling Examples and Control Plane Use Cases ..................30
5.1. Network Modeling for GMPLS/PCE Control ....................30
5.1.1. Describing the WSON Nodes ..........................31
5.1.2. Describing the Links ...............................34
5.2. RWA Path Computation and Establishment ....................34
5.3. Resource Optimization .....................................36
5.4. Support for Rerouting .....................................36
5.5. Electro-Optical Networking Scenarios ......................36
5.5.1. Fixed Regeneration Points ..........................37
5.5.2. Shared Regeneration Pools ..........................37
5.5.3. Reconfigurable Regenerators ........................37
5.5.4. Relation to Translucent Networks ...................38
6. GMPLS and PCE Implications .....................................38
6.1. Implications for GMPLS Signaling ..........................39
6.1.1. Identifying Wavelengths and Signals ................39
6.1.2. WSON Signals and Network Element Processing ........39
6.1.3. Combined RWA/Separate Routing WA support ...........40
6.1.4. Distributed Wavelength Assignment:
Unidirectional, No Converters ......................40
6.1.5. Distributed Wavelength Assignment:
Unidirectional, Limited Converters .................40
6.1.6. Distributed Wavelength Assignment:
Bidirectional, No Converters .......................40
6.2. Implications for GMPLS Routing ............................41
6.2.1. Electro-Optical Element Signal Compatibility .......41
6.2.2. Wavelength-Specific Availability Information .......42
6.2.3. WSON Routing Information Summary ...................43
6.3. Optical Path Computation and Implications for PCE .........44
6.3.1. Optical Path Constraints and Characteristics .......44
6.3.2. Electro-Optical Element Signal Compatibility .......45
6.3.3. Discovery of RWA-Capable PCEs ......................45
7. Security Considerations ........................................46
8. Acknowledgments ................................................46
9. References .....................................................46
9.1. Normative References ......................................46
9.2. Informative References ....................................471. Introduction 🌸
Okay so, WSONs are built from a bunch of subsystems: Wavelength Division Multiplexing (WDM) links, tunable transmitters and receivers, Reconfigurable Optical Add/Drop Multiplexers (ROADMs), wavelength converters, and electro-optical network elements. A WSON is a WDM-based optical network where switching is done selectively, based on the center wavelength of an optical signal 🌈.
WSONs are kind of their own vibe compared to other GMPLS networks 🙈. Lots of WSON nodes are super asymmetric when it comes to their switching capabilities. You might need to think about whether signal types and network elements are compatible. And label assignment can be non-local, which is a big deal. To set up an optical connection (an optical path) through a WSON, certain wavelength continuity and resource availability constraints must be met, so you can figure out which paths are viable and which are optimal. Working out those paths is called Routing and Wavelength Assignment (RWA) 💅.
Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] brings an architecture and a set of control plane protocols that can run data networks of all kinds, from packet-switch-capable networks to ones that use Time Division Multiplexing, all the way to WDM networks ✨. The Path Computation Element (PCE) architecture [RFC4655] defines functional components that compute and suggest appropriate paths in connection-oriented traffic-engineered networks 🦋.
This doc gives a framework for applying the GMPLS architecture and protocols [RFC3945] and the PCE architecture [RFC4655] to the control and operation of WSONs 💖. To help with that, it also gives an overview of the subsystems and processes that make up WSONs, and it describes RWA so the information requirements (both static and dynamic) can be identified. That shows how the information can be modeled for use by GMPLS and PCE systems. Basically, this sets the stage for protocol solution models and protocol extensions within the GMPLS and PCE protocol families 👑.
Different WSONs, like access, metro, and long haul, may use different techniques for dealing with optical impairments. So this doc doesn't go deep on impairments 🙈. It focuses on the generic properties of links, switches, and path selection constraints that show up in many types of WSONs. If you want more on optical impairments and GMPLS, check out [WSON-Imp] 🔗.
2. Terminology ✨
okay bestie, let's get into the glossary 🎀 because this section is basically the vocab list you need before anything else makes sense. I'm not gonna fake that it's exciting, but it's giving foundation, and every term here shows up later so it's worth knowing 🫶
Add/Drop Multiplexer (ADM): An optical device used in WDM networks and composed of one or more line side ports and typically many tributary ports. 🦋
CWDM: Coarse Wavelength Division Multiplexing. 🌈
DWDM: Dense Wavelength Division Multiplexing. 🌈
Degree: The degree of an optical device (e.g., ROADM) is given by a count of its line side ports. 🔥
Drop and continue: A simple multicast feature of some ADMs where a selected wavelength can be switched out of both a tributary (drop) port and a line side port. ✨ this one is lowkey iconic, one signal, two destinations, no cap 💅
FOADM: Fixed Optical Add/Drop Multiplexer. 🍓
GMPLS: Generalized Multi-Protocol Label Switching. 🧚
Line side: In a WDM system, line side ports and links can typically carry the full multiplex of wavelength signals, as compared to tributary (add or drop) ports that typically carry a few (usually one) wavelength signals. 💜 so the line side is the big highway and tributary is the little side street, bestie 🚗
OXC: Optical Cross-Connect. An optical switching element in which a signal on any input port can reach any output port. 👑
PCC: Path Computation Client. Any client application requesting a path computation to be performed by the Path Computation Element. 💖
PCE: Path Computation Element. An entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and application of computational constraints. 👑 the PCE is the brain of the operation, periodt 🧠
PCEP: PCE Communication Protocol. The communication protocol between a Path Computation Client and Path Computation Element. 🫶
ROADM: Reconfigurable Optical Add/Drop Multiplexer. A wavelength-selective switching element featuring input and output line side ports as well as add/drop tributary ports. 🌸
RWA: Routing and Wavelength Assignment. 🦋
Transparent Network: A Wavelength Switched Optical Network that does not contain regenerators or wavelength converters. 🫧
Translucent Network: A Wavelength Switched Optical Network that is predominantly transparent but may also contain limited numbers of regenerators and/or wavelength converters. 🌙
Tributary: A link or port on a WDM system that can carry significantly less than the full multiplex of wavelength signals found on the line side links/ports. Typical tributary ports are the add and drop ports on an ADM, and these support only a single wavelength channel. 🎀
Wavelength Conversion/Converters: The process of converting an information-bearing optical signal centered at a given wavelength to one with "equivalent" content centered at a different wavelength. Wavelength conversion can be implemented via an optical-electronic-optical (OEO) process or via a strictly optical process. ✨
WDM: Wavelength Division Multiplexing. 🌈
Wavelength Switched Optical Networks (WSONs): WDM-based optical networks in which switching is performed selectively based on the center wavelength of an optical signal. 🧚💜
3. Wavelength Switched Optical Networks 🦋
okay so WSONs are literally everywhere, bestie 🌍 they range from continent-spanning long-haul networks, to metropolitan networks, to residential access networks. 💅 in all these cases, the main concern is those properties that constrain the choice of wavelengths that can be used, i.e., restrict the wavelength Label Set, impact the path selection process, and limit the topological connectivity. 🔥 if electro-optical network elements are used in the WSON, additional compatibility constraints may be imposed by the network elements on various optical signal parameters. 🙈 the next sections kind of break down the major subsystems of a WSON, focusing on the parts that matter for the control plane. 🫶 specifically we're looking at WDM links, optical transmitters, ROADMs, and wavelength converters. 👑
3.1. WDM and CWDM Links 🌈
WDM and CWDM links run over optical fibers, and optical fibers come in a wide range of types that tend to be optimized for various applications. 🧵 examples include access networks, metro, long haul, and submarine links. International Telecommunication Union - Telecommunication Standardization Sector (ITU-T) standards exist for various types of fibers. Although fiber can be categorized into Single-Mode Fibers (SMFs) and Multi-Mode Fibers (MMFs), the latter are typically used for short-reach campus and premise applications. SMFs are used for longer-reach applications and are therefore the primary concern of this document. ✨ the following SMF types are typically encountered in optical networks:
ITU-T Standard | Common Name
------------------------------------------------------------
G.652 [G.652] | Standard SMF |
G.653 [G.653] | Dispersion shifted SMF |
G.654 [G.654] | Cut-off shifted SMF |
G.655 [G.655] | Non-zero dispersion shifted SMF |
G.656 [G.656] | Wideband non-zero dispersion shifted SMF |
------------------------------------------------------------Typically, WDM links operate in one or more of the approximately defined optical bands [G.Sup39]:
Band Range (nm) Common Name Raw Bandwidth (THz)
O-band 1260-1360 Original 17.5
E-band 1360-1460 Extended 15.1
S-band 1460-1530 Short 9.4
C-band 1530-1565 Conventional 4.4
L-band 1565-1625 Long 7.1
U-band 1625-1675 Ultra-long 5.5Not all of a band may be usable; for example, in many fibers that support E-band, there is significant attenuation due to a water absorption peak at 1383 nm. 💧 hence, a discontinuous acceptable wavelength range for a particular link may be needed and is modeled. Also, some systems will utilize more than one band. This is particularly true for CWDM systems. 🌸
Current technology subdivides the bandwidth capacity of fibers into distinct channels based on either wavelength or frequency. There are two standards covering wavelengths and channel spacing. ITU-T Recommendation G.694.1, "Spectral grids for WDM applications: DWDM frequency grid" [G.694.1], describes a DWDM grid defined in terms of frequency grids of 12.5 GHz, 25 GHz, 50 GHz, 100 GHz, and other multiples of 100 GHz around a 193.1 THz center frequency. At the narrowest channel spacing, this provides less than 4800 channels across the O through U bands. ITU-T Recommendation G.694.2, "Spectral grids for WDM applications: CWDM wavelength grid" [G.694.2], describes a CWDM grid defined in terms of wavelength increments of 20 nm running from 1271 nm to 1611 nm for 18 or so channels. The number of channels is significantly smaller than the 32-bit GMPLS Label space defined for GMPLS (see [RFC3471]). A label representation for these ITU-T grids is given in [RFC6205] and provides a common label format to be used in signaling optical paths. 🏷️
Further, these ITU-T grid-based labels can also be used to describe WDM links, ROADM ports, and wavelength converters for the purposes of path selection. 🗺️
Many WDM links are designed to take advantage of particular fiber characteristics or to try to avoid undesirable properties. For example, dispersion-shifted SMF [G.653] was originally designed for good long-distance performance in single-channel systems; however, putting WDM over this type of fiber requires significant system engineering and a fairly limited range of wavelengths. Hence, the following information is needed as parameters to perform basic, impairment-unaware modeling of a WDM link: 🧠
- Wavelength range(s): Given a mapping between labels and the ITU-T grids, each range could be expressed in terms of a tuple,
(lambda1, lambda2)or(freq1, freq2), where the lambdas or frequencies can be represented by 32-bit integers. - Channel spacing: Currently, there are five channel spacings used in DWDM systems and a single channel spacing defined for CWDM systems.
For a particular link, this information is relatively static, as changes to these properties generally require hardware upgrades. Such information may be used locally during wavelength assignment via signaling, similar to label restrictions in MPLS, or used by a PCE in providing combined RWA. 💅
3.2. Optical Transmitters and Receivers 📡
WDM optical systems make use of optical transmitters and receivers utilizing different wavelengths (frequencies). Some transmitters are manufactured for a specific wavelength of operation; that is, the manufactured frequency cannot be changed. First introduced to reduce inventory costs, tunable optical transmitters and receivers are deployed in some systems and allow flexibility in the wavelength used for optical transmission/reception. Such tunable optics aid in path selection. 🎛️
Fundamental modeling parameters for optical transmitters and receivers from the control plane perspective are: 🫶
- Tunable: Do the transmitters and receivers operate at variable or fixed wavelength?
- Tuning range: This is the frequency or wavelength range over which the optics can be tuned. With the fixed mapping of labels to lambdas as proposed in [RFC6205], this can be expressed as a tuple,
(lambda1, lambda2)or(freq1, freq2), where lambda1 and lambda2 or freq1 and freq2 are the labels representing the lower and upper bounds in wavelength. - Tuning time: Tuning times highly depend on the technology used. Thermal-drift-based tuning may take seconds to stabilize, whilst electronic tuning might provide sub-ms tuning times. Depending on the application, this might be critical. For example, thermal drift might not be usable for fast protection applications. ⏱️
- Spectral characteristics and stability: The spectral shape of a laser's emissions and its frequency stability put limits on various properties of the overall WDM system. One constraint that is relatively easy to characterize is the closest channel spacing with which the transmitter can be used.
Note that ITU-T recommendations specify many aspects of an optical transmitter. Many of these parameters, such as spectral characteristics and stability, are used in the design of WDM subsystems consisting of transmitters, WDM links, and receivers. However, they do not furnish additional information that will influence the Label Switched Path (LSP) provisioning in a properly designed system. 🙅♀️
Also, note that optical components can degrade and fail over time. This presents the possibility of the failure of an LSP (optical path) without either a node or link failure. Hence, additional mechanisms may be necessary to detect and differentiate this failure from the others; for example, one does not want to initiate mesh restoration if the source transmitter has failed since the optical transmitter will still be failed on the alternate optical path. 🥺💔
3.3. Optical Signals in WSONs
okay so the big idea here is that in WSONs the basic unit of switching is basically a "wavelength" 🌈. The transmitters and receivers only handle one wavelength at a time, but the switching systems can juggle a bunch of wavelengths at once 💅. That's why this doc is mainly focused on multi-channel DWDM networks with single-channel interfaces, not multi-channel interfaces ✨. Those interface types are defined in ITU-T Recommendations [G.698.1] and [G.698.2]. The key non-impairment-related parameters in those two are:
- (a) Minimum channel spacing (GHz)
- (b) Minimum and maximum central frequency
- (c) Bitrate/Line coding (modulation) of optical tributary signals
When we model the WSON in the control plane, (a) and (b) count as properties of the link and restrictions on the GMPLS Labels, while (c) is a property of the "signal" 🦋.
3.3.1. Optical Tributary Signals
the term "optical tributary signal" is the star of this section 🌟. [G.698.1], [G.698.2], and [G.959.1] all use it, and it's defined as "a single channel signal that is placed within an optical channel for transport across the optical network". The word "tributary" is the tell here: it means it's one channel, not a multi-channel optical signal 👀.
There are currently several types of these, called "optical tributary signal classes". They're characterized by a modulation format and a bitrate range [G.959.1]:
- (a) Optical tributary signal class Non-Return-to-Zero (NRZ) 1.25G
- (b) Optical tributary signal class NRZ 2.5G
- (c) Optical tributary signal class NRZ 10G
- (d) Optical tributary signal class NRZ 40G
- (e) Optical tributary signal class Return-to-Zero (RZ) 40G
more classes may get added as tech keeps advancing, and this is a super active area for development and standardization 🔥. Especially at the 40G rate, there are a bunch of non-standardized advanced modulation formats that have seen a lot of real-world deployment, like Differential Phase Shift Keying (DPSK) and Phase Shaped Binary Transmission (PSBT) 💜.
According to [G.698.2], it's important to fully specify the bitrate of the optical tributary signal. So modulation format (the optical tributary signal class) and bitrate are both key parameters for describing the optical tributary signal 🎀.
3.3.2. WSON Signal Characteristics
The optical tributary signal in [G.698.1] and [G.698.2] is called the "signal" in this document 🧚. It corresponds to the "lambda" LSP in GMPLS. For signal compatibility with electro-optical network elements, these are the characteristics we look at:
- Optical tributary signal class (modulation format)
- Forward Error Correction (FEC): whether forward error correction is used in the digital stream and what type of error correcting code is used
- Center frequency (wavelength)
- Bitrate
- General Protocol Identifier (G-PID) for the information format
the first three items on that list can change as a WSON signal travels through the network, with elements like regenerators, OEO switches, or wavelength converters 🔄. Bitrate and G-PID wouldn't change, since they describe the encoded bitstream. A set of G-PID values for lambda switching is already defined in [RFC3471] and [RFC4328] 🫶.
ngl the modulation formats and FEC codes in WSONs are all over the place. A lot of them are non-standard or proprietary, and that's just the reality 💀.
For some digital bitstreams, you can actually detect whether FEC is present. For example, in [G.707] it's shown in the signal itself through the FEC Status Indication (FSI) byte. In [G.709], you can infer it from whether the FEC field of the Optical Channel Transport Unit-k (OTUk) is all zeros 🙈.
3.4. ROADMs, OXCs, Splitters, Combiners, and FOADMs
the definitions for these optical devices, like ROADMs, Optical Cross-Connects (OXCs), splitters, combiners, and Fixed Optical Add/Drop Multiplexers (FOADMs), along with their parameters, all live in [G.671] 📚. We're only going to look at the subset that matters for the control plane, plus their non-impairment-related properties, in the sections that follow 💖.
3.4.1. Reconfigurable Optical Add/Drop Multiplexers and OXCs
ROADMs come in lots of different forms and technologies. They're a key technology for wavelength-based optical switching 🌸. Here's a classic degree-2 ROADM, shown in Figure 1:
Line side input +---------------------+ Line side output
--->| |--->
| |
| ROADM |
| |
| |
+---------------------+
| | | | o o o o
| | | | | | | |
O O O O | | | |
Tributary Side: Drop (output) Add (input)
Figure 1. Degree-2 Unidirectional ROADMThe main thing to know about every ROADM type is that the switching is super asymmetric 👑. In the Figure 1 ROADM, signals coming in through the add ports can only go out the line side output port, and not to any of the drop ports 💅. The "degree" of a ROADM is how many line side ports it has (inputs and outputs together), and it doesn't count the add or drop ports. Those add and drop ports are sometimes called tributary ports 🎀. Once the degree goes above two, the ROADM can act like both a switch (OXC) and a multiplexer, so you need to know the switched connectivity the device offers to actually use it well 🧠. An easy way to represent that is a "switched connectivity" matrix A, where Amn = 0 or 1 depending on whether a wavelength on input port m can be connected to output port n [Imajuku]. For the Figure 1 ROADM, the matrix looks like this:
Input Output Port
Port #1 #2 #3 #4 #5
--------------
#1: 1 1 1 1 1
#2 1 0 0 0 0
A = #3 1 0 0 0 0
#4 1 0 0 0 0
#5 1 0 0 0 0in this one, input ports 2-5 are add ports, output ports 2-5 are drop ports, and input port #1 and output port #1 are the line side (WDM) ports 🌈.
For ROADMs, this matrix is going to be very sparse, while for OXCs it'll be very dense 🍓. Compact encodings and examples, including high-degree ROADMs/OXCs, are in [Gen-Encode]. Here's a degree-4 ROADM, Figure 2:
+-----------------------+
Line side-1 --->| |---> Line side-2
Input (I1) | | Output (E2)
Line side-1 <---| |<--- Line side-2
Output (E1) | | Input (I2)
| ROADM |
Line side-3 --->| |---> Line side-4
Input (I3) | | Output (E4)
Line side-3 <---| |<--- Line side-4
Output (E3) | | Input (I4)
| |
+-----------------------+
| O | O | O | O
| | | | | | | |
O | O | O | O |
Tributary Side: E5 I5 E6 I6 E7 I7 E8 I8
Figure 2. Degree-4 Bidirectional ROADMthis is a degree-4 example, with one (potentially multi-channel) add/drop per line side port ✨.
Also, the connectivity constraints for typical ROADM designs are "bidirectional" 🦋. That means if input port X can connect to output port Y, then input port Y can typically connect to output port X. This assumes the numbering is set up so input X and output X match the same line side direction or the same add/drop port. That makes the connectivity matrix symmetrical, like this:
Input Output Port
Port E1 E2 E3 E4 E5 E6 E7 E8
-----------------------
I1 0 1 1 1 0 1 0 0
I2 1 0 1 1 0 0 1 0
A = I3 1 1 0 1 1 0 0 0
I4 1 1 1 0 0 0 0 1
I5 0 0 1 0 0 0 0 0
I6 1 0 0 0 0 0 0 0
I7 0 1 0 0 0 0 0 0
I8 0 0 0 1 0 0 0 0in this matrix, I5/E5 are the add/drop ports to and from line side-3, I6/E6 are the add/drop ports to and from line side-1, I7/E7 are the add/drop ports to and from line side-2, and I8/E8 are the add/drop ports to and from line side-4 💜. The diagonal elements are zero because loopback isn't supported in this example. If the ports do support loopback, the diagonal elements would be set to one 🙈.
Extra constraints can also apply to the various ports on a ROADM/OXC. These are the terms you can use:
- Colored port: an input or, more typically, an output (drop) port restricted to a single channel of fixed wavelength
- Colorless port: an input or, more typically, an output (drop) port restricted to a single channel of arbitrary wavelength
In general, a port on a ROADM could have any of these wavelength restrictions:
- Multiple wavelengths, full range port
- Single wavelength, full range port
- Single wavelength, fixed lambda port
- Multiple wavelengths, reduced range port (for example wave band switching)
To model these restrictions, you need two pieces of info for each port: (a) the number of wavelengths and (b) the wavelength range and spacing. This info is relatively static. More complicated wavelength constraints are modeled in [WSON-Info] 🎀.
3.4.2. Splitters
An optical splitter has a single input port and two or more output ports 🌸. The input optical signal is basically copied (with power loss) to all of the output ports 💅.
Using the modeling notions from Section 3.4.1, the input and output ports of a splitter would have the same wavelength restrictions. On top of that, a splitter is modeled with a connectivity matrix Amn like this:
Input Output Port
Port #1 #2 #3 ... #N
-----------------
A = #1 1 1 1 ... 1the difference from a simple ROADM is that this isn't a switched connectivity matrix. It's the fixed connectivity matrix of the device 🧚.
3.4.3. Combiners
An optical combiner is a device that takes the optical wavelengths from multiple input ports and combines them into a single multi-wavelength output port ✨. The various ports can have different wavelength restrictions 🦋. It's generally up to whoever is using the combiner to make sure wavelength collision doesn't happen on the output port 👀. The fixed connectivity matrix Amn for a combiner looks like this:
Input Output Port
Port #1
---
#1: 1
#2 1
A = #3 1
... 1
#N 13.4.4. Fixed Optical Add/Drop Multiplexers ✨
okay so a Fixed Optical Add/Drop Multiplexer (FOADM) is giving preset 💅 It can change where an input wavelength goes, but the route is locked in ahead of time. A given wavelength (or waveband) coming in on a line side input port gets dropped out of a fixed "tributary" output port. Depending on how the device is built, that same wavelength might also go out the line side output port, and that's what people call a "drop and continue" operation 🦋 Some FOADMs also have tributary input ports (the "add" ports), and those signals get combined with each other and with the line side signals too. Main character energy, but make it predictable 💖
To describe how an FOADM routes stuff, you need two things. First, you need a fixed connectivity matrix Amn, which we already talked about. Second, you need the exact wavelength restrictions for every input and output port 🎀 Here's how the detective work goes:
- The wavelength restrictions on the tributary output ports tell you which wavelengths were selected.
- The wavelength restrictions on the tributary input ports tell you which wavelengths got added to the line side output port.
- Then, using those added wavelengths plus the line side output wavelength restrictions, you can work out which wavelengths were continued.
So basically, the modeling method from Section 3.4.1 (connectivity matrix plus port wavelength restrictions) can describe a whole bunch of fixed optical gear, like combiners, splitters, and FOADMs 🧚 Hybrid devices that have both switched and fixed parts are modeled in [WSON-Info], so go check that if you're curious ✨
3.5. Electro-Optical Systems 🌈
okay now this section is about how Electro-Optical Systems (think OEO switches, wavelength converters, and regenerators) play with the WSON signal characteristics we listed in Section 3.3.2 💜 These three all have a similar vibe: they can be more or less "transparent" to an "optical signal," and that depends on what they do and/or how they're built 🫶 Regenerators are pretty well characterized in this area, so we'll start with them first 💅
3.5.1. Regenerators
bestie, the different ways to do regeneration are covered in ITU-T [G.872], Annex A 🌸 They get sorted into the so-called 1R, 2R, and 3R categories of regenerators, and here's the breakdown in Table 1 below 👑
Table 1. Regenerator Functionality Mapped to General Regenerator
Classes from [G.872]
--------------------------------------------------------------------
1R | Equal amplification of all frequencies within the amplification
| bandwidth. There is no restriction upon information formats.
+----------------------------------------------------------------
| Amplification with different gain for frequencies within the
| amplification bandwidth. This could be applied to both single-
| channel and multi-channel systems.
+----------------------------------------------------------------
| Dispersion compensation (phase distortion). This analogue
| process can be applied in either single-channel or multi-
| channel systems.
--------------------------------------------------------------------
2R | Any or all 1R functions. Noise suppression.
+----------------------------------------------------------------
| Digital reshaping (Schmitt Trigger function) with no clock
| recovery. This is applicable to individual channels and can be
| used for different bitrates but is not transparent to line
| coding (modulation).
--------------------------------------------------------------------
3R | Any or all 1R and 2R functions. Complete regeneration of the
| pulse shape including clock recovery and retiming within
| required jitter limits.
--------------------------------------------------------------------the table tells us that 1R regenerators are generally independent of the modulation format (also called line coding) but might only work over a limited range of wavelengths/frequencies 🦋 2R regenerators are generally for a single digital stream, and they depend on the modulation format (line coding). They're also limited to a range of bitrates (just not one specific bitrate) 🍓 And 3R regenerators apply to a single channel, depend on the modulation format, and are usually picky about bitrate. Either they're built for one specific bitrate, or they have to be programmed to accept and regenerate one specific bitrate 😭 Across all three types, the digital bitstream inside the optical or electrical signal does not get modified ✨
Now here's the plot twist 🙈 It's pretty common for regenerators to modify the digital bitstream anyway, for performance monitoring and fault management. SONET, SDH, and the Interfaces for the Optical Transport Network [G.709] all have digital signal "envelopes" that are meant to be used between "regenerators" (in this case, 3R regenerators) 🌈 In SONET it's called the "section" signal, in SDH it's the "regenerator section" signal, and in G.709 it's an OTUk. These signals set aside part of their frame structure (called overhead) for regenerators to use. Table 2 below sums up what that overhead looks like 💖
Table 2. SONET, SDH, and G.709 Regenerator-Related Overhead
+-----------------------------------------------------------------+
|Function | SONET/SDH | G.709 OTUk |
| | Regenerator | |
| | Section | |
|------------------+----------------------+-----------------------|
|Signal | J0 (section | Trail Trace |
|Identifier | trace) | Identifier (TTI) |
|------------------+----------------------+-----------------------|
|Performance | BIP-8 (B1) | BIP-8 (within SM) |
|Monitoring | | |
|------------------+----------------------+-----------------------|
|Management | D1-D3 bytes | GCC0 (general |
|Communications | | communications |
| | | channel) |
|------------------+----------------------+-----------------------|
|Fault Management | A1, A2 framing | FAS (frame alignment |
| | bytes | signal), BDI (backward|
| | | defect indication), |
| | | BEI (backward error |
| | | indication) |
+------------------+----------------------+-----------------------|
|Forward Error | P1,Q1 bytes | OTUk FEC |
|Correction (FEC) | | |
+-----------------------------------------------------------------+so Table 2 shows that frame alignment, signal identification, and FEC are all supported 🦋 And by what it doesn't list, you can tell that no switching or multiplexing happens at this layer 💅 That's a huge simplification for the control plane, because control plane standards need a multi-layer approach when there are multiple switching layers, but they don't require that "layering" to provide the management functions in Table 2 🫶 Lots of existing technologies covered by GMPLS have extra management-related layers that the control plane basically ignores (though the management plane does not) 👑 So the approach here is to include regenerators and other devices at the WSON layer, unless they provide higher layer switching. If they do, then a multi-layer or multi-region approach [RFC5212] is called for. The catch? Regenerators can end up depending on the client signal type 😭
Which means, depending on the regenerator technology, a regenerator device may impose the constraints listed in Table 3 🎀
Table 3. Regenerator Compatibility Constraints
+--------------------------------------------------------+
| Constraints | 1R | 2R | 3R |
+--------------------------------------------------------+
| Limited Wavelength Range | x | x | x |
+--------------------------------------------------------+
| Modulation Type Restriction | | x | x |
+--------------------------------------------------------+
| Bitrate Range Restriction | | x | x |
+--------------------------------------------------------+
| Exact Bitrate Restriction | | | x |
+--------------------------------------------------------+
| Client Signal Dependence | | | x |
+--------------------------------------------------------+quick note, bestie 🧚 The limited wavelength range constraint can be modeled for GMPLS signaling with the Label Set defined in [RFC3471]. And the modulation type restriction constraint includes FEC 🔥
3.5.2. OEO Switches
okay so a really common spot for OEO processing is inside WSON switches that use (or contain) regenerators 🌸 The switch might convert the signal to electronic form so it can switch it, then convert it back to optical before it leaves the switch. Another popular move is adding regenerators to restore signal quality either before or after the optical processing (switching) ✨ In the first case, the regeneration happens to adapt the signal to the switch fabric, even if the signal doesn't need it from a signal-quality standpoint 🙈
Either way, these optical switches have basically the same compatibility constraints as the regenerators we just looked at in Table 3 💖 Same energy, different outfit 💅
3.6. Wavelength Converters ✨
okay bestie, wavelength converters are giving main character energy 💖 they take an input optical signal at one wavelength and spit out an equivalent content optical signal at a different wavelength on the output 🦋 there's more than one way to build them 🔥
approach one is OEO conversion with fixed or tunable optics on the output. this one can depend on the signal rate and format, so it's basically an electrical regenerator with a laser/receiver attached 💅 which means it has signal-processing restrictions that are essentially the same as the ones for regenerators in Table 3 of Section 3.5.1 🫶
approach two does the conversion optically through non-linear optical effects. it's kinda like the frequency mixing you know from radio frequency systems, but way harder to actually pull off 😭 these effects can put limits on how much conversion you can get. those limits may depend on the wavelength of the input signal and the properties of the converter, not only the converter's properties like in the OEO case 🌈 different WSON system designs might use this component a lot, a little, or not at all 💀
here are the current or envisioned contexts for wavelength converters:
- Wavelength conversion associated with OEO switches and fixed or tunable optics. in this case there are typically multiple converters available, since each use of an OEO switch can be thought of as a potential wavelength converter 🍓
- Wavelength conversion associated with ROADMs/OXCs. in this case there may be a limited pool of wavelength converters available. the conversion could be all optical or via an OEO method 🧚
- Wavelength conversion associated with fixed devices such as FOADMs. in this case there may be a limited amount of conversion. also, the conversion may be used as part of optical path routing 💜
based on all that, wavelength converters are modeled like this:
- Wavelength converters can always be modeled as associated with network elements. this includes fixed wavelength routing elements 🎀
- A network element may have full wavelength conversion capability (i.e., any input port and wavelength) or a limited number of wavelengths and ports. on a box with a limited number of converters, there also may exist restrictions on which ports can reach the converters. so, no matter where the converters actually are, they can be associated with input ports 👑
- Wavelength converters have range restrictions that are either independent or dependent upon the input wavelength ⭐
in WSONs where wavelength converters are sparse, an optical path may appear to loop or "backtrack" upon itself in order to reach a wavelength converter before continuing on to its destination 🌸 the lambda used on input to the wavelength converter would be different from the lambda coming back from the wavelength converter 🦋
a model for an individual OEO wavelength converter would consist of:
- Input lambda or frequency range
- Output lambda or frequency range
3.6.1. Wavelength Converter Pool Modeling
okay this part is where it gets spicy 🌶️ a WSON node may include multiple wavelength converters. these are usually arranged into some type of pool so they can share resources 🫶 there are a bunch of different approaches for designing switches with converter pools. still, from the point of view of path computation, you need to know the following:
- The nodes that support wavelength conversion
- The accessibility and availability of a wavelength converter to convert from a given input wavelength on a particular input port to a desired output wavelength on a particular output port
- Limitations on the types of signals that can be converted and the conversions that can be performed
to model point 2 above, you can use a technique similar to the one used to model ROADMs and optical switches, i.e., matrices to indicate possible connectivity along with wavelength constraints for links/ports 💅 since wavelength converters are considered a scarce resource, it is desirable to include, at a minimum, the usage state of individual wavelength converters in the pool 😭
a three stage model is shown schematically in Figure 3 ✨ this model represents N input ports (fibers), P wavelength converters, and M output ports (fibers). since not all input ports can necessarily reach the converter pool, the model starts with a wavelength pool input matrix WI(i,p) = {0,1}, where input port i can potentially reach wavelength converter p 🦋
since not all wavelengths can necessarily reach all the converters, or the converters may have a limited input wavelength range, there is a set of input port constraints for each wavelength converter. right now, it's assumed that a wavelength converter can only take a single wavelength on input. each wavelength converter input port constraint can be modeled via a wavelength set mechanism 🌈
next up is a state vector WC(j) = {0,1}, which depends on whether wavelength converter j in the pool is in use. this is the only state kept in the converter pool model 💜 this state isn't necessary for modeling a "fixed" transponder system, i.e., a system where there is no sharing. also, this state information may be encoded in a much more compact form depending on the overall connectivity structure [Gen-Encode] 🧚
after that, a set of wavelength converter output wavelength constraints is used. these constraints indicate what wavelengths a particular wavelength converter can generate, or what it's restricted to generating due to the internal switch structure 🎀
finally, a wavelength pool output matrix WE(p,k) = {0,1} indicates whether the output from wavelength converter p can reach output port k 👑 examples of this method being used to model wavelength converter pools for several switch architectures are given in [Gen-Encode] ⭐
I1 +-------------+ +-------------+ E1
----->| | +--------+ | |----->
I2 | +------+ WC #1 +-------+ | E2
----->| | +--------+ | |----->
| Wavelength | | Wavelength |
| Converter | +--------+ | Converter |
| Pool +------+ WC #2 +-------+ Pool |
| | +--------+ | |
| Input | | Output |
| Connection | . | Connection |
| Matrix | . | Matrix |
| | . | |
| | | |
IN | | +--------+ | | EM
----->| +------+ WC #P +-------+ |----->
| | +--------+ | |
+-------------+ ^ ^ +-------------+
| |
| |
| |
| |
Input wavelength Output wavelength
constraints for constraints for
each converter each converterFigure 3. Schematic Diagram of Wavelength Converter Pool Model
Figure 4 shows a simple optical switch in a four-wavelength DWDM system sharing wavelength converters in a general shared "per-node" fashion 🌸
+-----------+ ___________ +------+
| |--------------------------->| |
| |--------------------------->| C |
/| | |--------------------------->| o | E1
I1 /D+--->| |--------------------------->| m |
+ e+--->| | | b |====>
====>| M| | Optical | +-----------+ +----+ | i |
+ u+--->| Switch | | WC Pool | |O S|-->| n |
\x+--->| | | +-----+ | |p w|-->| e |
\| | +----+->|WC #1|--+->|t i| | r |
| | | +-----+ | |i t| +------+
| | | | |c c| +------+
/| | | | +-----+ | |a h|-->| |
I2 /D+--->| +----+->|WC #2|--+->|l |-->| C | E2
+ e+--->| | | +-----+ | | | | o |
====>| M| | | +-----------+ +----+ | m |====>
+ u+--->| | | b |
\x+--->| |--------------------------->| i |
\| | |--------------------------->| n |
| |--------------------------->| e |
|___________|--------------------------->| r |
+-----------+ +------+Figure 4. An Optical Switch Featuring a Shared Per-Node Wavelength Converter Pool Architecture
in this case, the input and output pool matrices are simply:
+-----+ +-----+
| 1 1 | | 1 1 |
WI =| |, WE =| |
| 1 1 | | 1 1 |
+-----+ +-----+Figure 5 shows a different wavelength pool architecture, known as "shared per fiber" 🦋 in this case, the input and output pool matrices are simply:
+-----+ +-----+
| 1 1 | | 1 0 |
WI =| |, WE =| |
| 1 1 | | 0 1 |
+-----+ +-----+ +-----------+ +------+
| |--------------------------->| |
| |--------------------------->| C |
/| | |--------------------------->| o | E1
I1 /D+--->| |--------------------------->| m |
+ e+--->| | | b |====>
====>| M| | Optical | +-----------+ | i |
+ u+--->| Switch | | WC Pool | | n |
\x+--->| | | +-----+ | | e |
\| | +----+->|WC #1|--+---------->| r |
| | | +-----+ | +------+
| | | | +------+
/| | | | +-----+ | | |
I2 /D+--->| +----+->|WC #2|--+---------->| C | E2
+ e+--->| | | +-----+ | | o |
====>| M| | | +-----------+ | m |====>
+ u+--->| | | b |
\x+--->| |--------------------------->| i |
\| | |--------------------------->| n |
| |--------------------------->| e |
|___________|--------------------------->| r |
+-----------+ +------+Figure 5. An Optical Switch Featuring a Shared Per-Fiber Wavelength Converter Pool Architecture
3.7. Characterizing Electro-Optical Network Elements ✨
okay so in this section we break electro-optical WSON network elements down into three key pieces: input constraints, output constraints, and processing capabilities 🧩
WSON Network Element
+-----------------------+
WSON Signal | | | | WSON Signal
| | | |
---------------> | | | | ----------------->
| | | |
+-----------------------+
<-----> <-------> <----->
Input Processing OutputFigure 6. WSON Network Element 🎀
3.7.1. Input Constraints 💅
bestie, sections 3.5 and 3.6 already covered the basics of regenerators, OEO switches, and wavelength converters, and from those we can pull out these possible types of input constraints and properties:
- Acceptable modulation formats
- Client signal (G-PID) restrictions
- Bitrate restrictions
- FEC coding restrictions
- Configurability: (a) none, (b) self-configuring, (c) required
these constraints are shown as simple lists 📝 ngl the device may need to be "provisioned" through signaling or some other means so it can accept some signals and not others 🔐 but other devices are kinda transparent to some attributes, like a 2R regenerator and bitrate 🫶 and some devices can auto-detect certain attributes and configure themselves, like a 3R regenerator with bitrate detection and flexible phase locking circuitry ⚡ that's why item 5 exists, to describe how configurable the device is 💖
also, these input constraints apply to the termination of the WSON signal too 🌸
3.7.2. Output Constraints 🦋
none of the network elements we're looking at changes either the bitrate or the basic type of the client signal 🙅♀️ they can change the modulation format or the FEC code though 🔥 typically you'll see these output constraints:
- Output modulation is the same as input modulation (default)
- A limited set of output modulations is available
- Output FEC is the same as input FEC code (default)
- A limited set of output FEC codes is available
heads up: in cases 2 and 4 above, where there's more than one choice for the output modulation or FEC code, the network element has to be configured on a per-LSP basis to pick which choice to use 👀
3.7.3. Processing Capabilities 🧚
a general WSON network element (NE) can do a bunch of signal processing, including:
(A) Regeneration (possibly different types) (B) Fault and performance monitoring (C) Wavelength conversion (D) Switching
so an NE may or may not be able to regenerate (of one of the types we talked about earlier) 🤷♀️ some nodes also have limited regeneration, like a shared pool that can be applied to selected signals passing through the NE 🏊♀️ so to describe a link's or node's regeneration capability, you need at minimum:
- Regeneration capability: (a) fixed, (b) selective, (c) none
- Regeneration type: 1R, 2R, 3R
- Regeneration pool properties for the case of selective regeneration (input and output restrictions, availability)
note that the properties of shared regenerator pools would be basically the same as those of the wavelength converter pools we modeled in Section 3.6.1 🎀
item B (fault and performance monitoring) is usually outside the scope of the control plane 🙈 BUT when those operations are done on an LSP basis or on part of an LSP, the control plane can help set them up 🤝 examples include per-LSP, per-node, and fault and performance monitoring stuff like setting up a "section trace" (a regenerator overhead identifier) between two nodes, or doing intermediate optical performance monitoring at selected nodes along a path 📊
4. Routing and Wavelength Assignment and the Control Plane 🌈
from the control plane point of view, a wavelength-convertible network with full wavelength-conversion capability at each node can be controlled pretty much like a packet MPLS-labeled network, or like a circuit-switched Time Division Multiplexing (TDM) network with full-time slot interchange capability 🧠 in this case, path selection needs to figure out which Traffic Engineered (TE) links an optical path will use, and wavelength assignment can happen hop-by-hop 🦋
BUT if you've got an optical network with no wavelength converters, an optical path has to be routed from source to destination and must use a single wavelength that's free along that whole path, without "colliding" with a wavelength used by any other optical path that might share an optical fiber 😭 this is sometimes called the "wavelength continuity constraint" 🔒
in the general case of limited or no wavelength converters, computing both the links and the wavelengths is known as RWA 💫
the inputs to basic RWA are the requested optical path's source and destination, the network topology, the locations and capabilities of any wavelength converters, and the wavelengths available on each optical link 📥 the output from an RWA algorithm is an explicit route through ROADMs, a wavelength for the optical transmitter, and a set of locations (usually tied to ROADMs or switches) where wavelength conversion happens, plus the new wavelength used on each component link after that point in the route 📤
and yes, it's out of scope for this document to pick a specific RWA algorithm 🙅♀️ but there are a bunch of different approaches to RWA algorithms that can change how the work gets split between path computation/routing and signaling 🍓
4.1. Architectural Approaches to RWA 🏗️
there are two general computational approaches to RWA 🧮 some algorithms do a two-step thing: path selection first, then wavelength assignment 🪜 others do RWA all in one go ✨
in the sections below we look at three different ways of doing RWA together with the control plane 💅 which architectural approach you pick usually affects how much the various control plane protocols get stressed 😩 these approaches are just for reference, and other approaches are totally possible 🌸
4.1.1. Combined RWA (R&WA) 👑
in this case, one unique entity is in charge of both routing and wavelength assignment 🫡 this approach needs a solid understanding of network topology, available network resources, and network nodes' capabilities 🧐 it's compatible with most known RWA algorithms, especially the ones focused on network optimization 🔥 the catch is that this solution needs up-to-date and detailed network information 😬
that computational entity could live in two different places:
- In a PCE that maintains a complete and updated view of network state and provides path computation services to nodes
- In an ingress node, in which case all nodes have the R&WA functionality and network state is obtained by a periodic flooding of information provided by the other nodes
4.1.2. Separated R and WA (R+WA) ✂️
in this case, one entity does routing and a second entity does wavelength assignment 🤝 the first entity hands one or more paths to the second entity, which does wavelength assignment and final path selection 🎯
separating the entity that computes the path from the entity that does wavelength assignment limits which RWA algorithms can be implemented 🙃 it might seem like algorithms that optimize joint usage of the physical and wavelength paths are totally excluded, but a lot of practical optimization algorithms only look at a limited set of possible paths, like the ones computed with a k-shortest path algorithm 🧩 so while there's no guarantee the final route and wavelength are the optimal solution, you can still do reasonable optimization by letting multiple routes pass to the wavelength selection process 💖
the entity doing the routing needs the topology information of the network, while the entity doing wavelength assignment needs info on the network's available resources and specific network node capabilities 📚
4.1.3. Routing and Distributed WA (R+DWA) 🌊
in this case, one entity does routing, and wavelength assignment happens hop-by-hop in a distributed way along the path that was already computed 🛤️ this mechanism depends on updating a list of potential wavelengths so the wavelength continuity constraint stays satisfied 🔗
as it's currently specified, the GMPLS protocol suite signaling protocol can support this approach 🫶 GMPLS, per [RFC3471], supports communicating the set of labels (wavelengths) that may be used between nodes through a "Label Set" 🏷️ when conversion isn't performed at an intermediate node, a hop builds the Label Set it sends to the next hop from the intersection of the Label Set it received from the previous hop and the wavelengths available on the node's switch and ongoing interface 🧮 how the outgoing Label Set gets generated is up to node local policy (even though you'd expect a consistent policy configuration across a given transparency domain) 📋 when wavelength conversion is performed at an intermediate node, a new Label Set is generated ✨ the egress node picks one label from the Label Set it received, and the node can also apply local policy during label selection 🎯 GMPLS also supports signaling bidirectional optical paths 💜
depending on these policies, a wavelength assignment may not be found at all, or one may be found that uses way more conversion resources than a dedicated wavelength assignment policy would have 😵 so this approach may generate higher blocking probabilities in a heavily loaded network 📈 this solution could be helped along by signaling extensions that make it function more smoothly and maybe boost its blocking probability performance 🚀 note that this approach needs less information dissemination than the other techniques we covered 🥰
the first entity may be a PCE or the ingress node of the LSP 🧚♀️
4.2. Conveying Information Needed by RWA 🎀
okay so we've already met WSONs and optical path requests, and we looked at the high-level models of the info the RWA process uses 💅. That info comes in two flavors. There's the relatively static stuff, which only changes when hardware changes (hello, failures 😭). Then there's the relatively dynamic stuff, which can change every time an optical path gets provisioned 🦋. How fast an RWA entity needs to hear about a change is super situational. For network restoration, finding out about a hardware failure, or about new hardware coming online to provide restoration capability, can be absolutely critical 🚨
Right now there are a bunch of ways to share RWA-relevant info 🌸 These include, but aren't limited to, the following:
- Existing control plane protocols, i.e., GMPLS routing and signaling. Routing protocols can be used to convey both static and dynamic information 🫶
- Management protocols such as NetConf, SNMPv3, and CORBA 💜
- Methods to access configuration and status information, such as a command line interface (CLI) 💻
- Directory services and their accompanying protocols. These are typically used to spread relatively static information. Directory services are NOT a good fit for managing info in dynamic and fluid environments 🙈
- Other techniques for dynamic info, e.g., sending information directly from NEs to PCEs so you avoid flooding 🧚 This would be useful if the number of PCEs is significantly less than the number of WSON NEs. There may be other ways to limit flooding to "interested" NEs ✨
If you want to scale up dynamic info, here are some possible mechanisms 👑
- Tailoring message content to WSON, e.g., using wavelength ranges or wavelength occupation bit maps 🌈
- Utilizing incremental updates if feasible 🍓
5. Modeling Examples and Control Plane Use Cases ✨
this section is where we get to see the fixed and switched optical node and wavelength constraint models from Section 3 in action 🔥 We'll also walk through use cases for WSON control plane path computation, establishment, rerouting, and optimization 💖
5.1. Network Modeling for GMPLS/PCE Control 🦋
okay picture this network 🌸 It has three routers (R1 through R3), eight WSON nodes (N1 through N8), 18 links (L1 through L18), and one OEO converter (O1). Here's the topology in Figure 7 👇
+--+ +--+ +--+ +--------+
+-L3-+N2+-L5-+ +--------L12--+N6+--L15--+ N8 +
| +--+ |N4+-L8---+ +--+ ++--+---++
| | +-L9--+| | | |
+--+ +-+-+ ++-+ || | L17 L18
| ++-L1--+ | | ++++ +----L16---+ | |
|R1| | N1| L7 |R2| | | |
| ++-L2--+ | | ++-+ | ++---++
+--+ +-+-+ | | | + R3 |
| +--+ ++-+ | | +-----+
+-L4-+N3+-L6-+N5+-L10-+ ++----+
+--+ | +--------L11--+ N7 +
+--+ ++---++
| |
L13 L14
| |
++-+ |
|O1+-+
+--+ Figure 7. Routers and WSON Nodes in a GMPLS and PCE Environment5.1.1. Describing the WSON Nodes 💅
so here's the tea on the eight WSON nodes from Figure 7 ☕
- Nodes N1, N2, and N3 have FOADMs installed, so they can only access a static and pre-defined set of wavelengths 🙈
- All other nodes contain ROADMs, so they can access all wavelengths 🌈
- Nodes N4, N5, N7, and N8 are multi-degree nodes, which means any wavelength can be optically switched between any of the links ✨ Heads up though, this doesn't automatically apply to wavelengths being added or dropped at that particular node 👀
- Node N4 is the exception to that. This node can switch any wavelength from its add/drop ports to any of its output links (L5, L7, and L12 in this case) 🦋
- The links from the routers can only carry one wavelength each, except for links L8 and L9, which can add/drop any wavelength 💜
- Node N7 has an OEO transponder (O1) connected to it via links L13 and L14. That transponder operates in 3R mode and doesn't change the wavelength of the signal. Assume it can regenerate any of the client signals, but only for one specific wavelength 🔥
With all those restrictions in mind, the node info for the eight nodes can be written out like this (where ID = identifier, SCM = switched connectivity matrix, and FCM = fixed connectivity matrix) 🎀
+ID+SCM +FCM +
| | |L1 |L2 |L3 |L4 | | |L1 |L2 |L3 |L4 | |
| |L1 |0 |0 |0 |0 | |L1 |0 |0 |1 |0 | |
|N1|L2 |0 |0 |0 |0 | |L2 |0 |0 |0 |1 | |
| |L3 |0 |0 |0 |0 | |L3 |1 |0 |0 |1 | |
| |L4 |0 |0 |0 |0 | |L4 |0 |1 |1 |0 | |
+--+---+---+---+---+---+---+---+---+---+---+---+---+
| | |L3 |L5 | | | | |L3 |L5 | | | |
|N2|L3 |0 |0 | | | |L3 |0 |1 | | | |
| |L5 |0 |0 | | | |L5 |1 |0 | | | |
+--+---+---+---+---+---+---+---+---+---+---+---+---+
| | |L4 |L6 | | | | |L4 |L6 | | | |
|N3|L4 |0 |0 | | | |L4 |0 |1 | | | |
| |L6 |0 |0 | | | |L6 |1 |0 | | | |
+--+---+---+---+---+---+---+---+---+---+---+---+---+
| | |L5 |L7 |L8 |L9 |L12| |L5 |L7 |L8 |L9 |L12|
| |L5 |0 |1 |1 |1 |1 |L5 |0 |0 |0 |0 |0 |
|N4|L7 |1 |0 |1 |1 |1 |L7 |0 |0 |0 |0 |0 |
| |L8 |1 |1 |0 |1 |1 |L8 |0 |0 |0 |0 |0 |
| |L9 |1 |1 |1 |0 |1 |L9 |0 |0 |0 |0 |0 |
| |L12|1 |1 |1 |1 |0 |L12|0 |0 |0 |0 |0 |
+--+---+---+---+---+---+---+---+---+---+---+---+---+
| | |L6 |L7 |L10|L11| | |L6 |L7 |L10|L11| |
| |L6 |0 |1 |0 |1 | |L6 |0 |0 |1 |0 | |
|N5|L7 |1 |0 |0 |1 | |L7 |0 |0 |0 |0 | |
| |L10|0 |0 |0 |0 | |L10|1 |0 |0 |0 | |
| |L11|1 |1 |0 |0 | |L11|0 |0 |0 |0 | |
+--+---+---+---+---+---+---+---+---+---+---+---+---+
| | |L12|L15| | | | |L12|L15| | | |
|N6|L12|0 |1 | | | |L12|0 |0 | | | |
| |L15|1 |0 | | | |L15|0 |0 | | | |
+--+---+---+---+---+---+---+---+---+---+---+---+---+
| | |L11|L13|L14|L16| | |L11|L13|L14|L16| |
| |L11|0 |1 |0 |1 | |L11|0 |0 |0 |0 | |
|N7|L13|1 |0 |0 |0 | |L13|0 |0 |1 |0 | |
| |L14|0 |0 |0 |1 | |L14|0 |1 |0 |0 | |
| |L16|1 |0 |1 |0 | |L16|0 |0 |1 |0 | |
+--+---+---+---+---+---+---+---+---+---+---+---+---+
| | |L15|L16|L17|L18| | |L15|L16|L17|L18| |
| |L15|0 |1 |0 |0 | |L15|0 |0 |0 |1 | |
|N8|L16|1 |0 |0 |0 | |L16|0 |0 |1 |0 | |
| |L17|0 |0 |0 |0 | |L17|0 |1 |0 |0 | |
| |L18|0 |0 |0 |0 | |L18|1 |0 |1 |0 | |
+--+---+---+---+---+---+---+---+---+---+---+---+---+5.1.2. Describing the Links 🔗
for what comes next, we're going to make some simplifying assumptions 🧚
- It is assumed that the WSON node supports a total of four wavelengths, designated WL1 through WL4 🌈
- It is assumed that the impairment feasibility of a path or path segment is independent of the wavelength chosen 💖
now, for RWA operation (building LSPs between two routers), we need to nail down the wavelength constraints on the links between the routers and the WSON nodes, plus the connectivity matrix of those links 🎀
+Link+WLs supported +Possible output links+
| L1 | WL1 | L3 |
+----+-----------------+---------------------+
| L2 | WL2 | L4 |
+----+-----------------+---------------------+
| L8 | WL1 WL2 WL3 WL4 | L5 L7 L12 |
+----+-----------------+---------------------+
| L9 | WL1 WL2 WL3 WL4 | L5 L7 L12 |
+----+-----------------+---------------------+
| L10| WL2 | L6 |
+----+-----------------+---------------------+
| L13| WL1 WL2 WL3 WL4 | L11 L14 |
+----+-----------------+---------------------+
| L14| WL1 WL2 WL3 WL4 | L13 L16 |
+----+-----------------+---------------------+
| L17| WL2 | L16 |
+----+-----------------+---------------------+
| L18| WL1 | L15 |
+----+-----------------+---------------------+quick note: the possible output links for the router-facing links are inferred from the switched connectivity matrix and the fixed connectivity matrix of Nodes N1 through N8. They're shown here just for convenience, so you don't have to repeat that info 💅
5.2. RWA Path Computation and Establishment 🌸
the calculation of optical impairment feasible routes is outside the scope of this document 🙅 In general, those feasible routes are an input to an RWA algorithm ✨
for this example use case, let's assume the following feasible routes 👇
+Endpoint 1+Endpoint 2+Feasible Route +
| R1 | R2 | L1 L3 L5 L8 |
| R1 | R2 | L1 L3 L5 L9 |
| R1 | R2 | L2 L4 L6 L7 L8 |
| R1 | R2 | L2 L4 L6 L7 L9 |
| R1 | R2 | L2 L4 L6 L10 |
| R1 | R3 | L1 L3 L5 L12 L15 L18 |
| R1 | N7 | L2 L4 L6 L11 |
| N7 | R3 | L16 L17 |
| N7 | R2 | L16 L15 L12 L9 |
| R2 | R3 | L8 L12 L15 L18 |
| R2 | R3 | L8 L7 L11 L16 L17 |
| R2 | R3 | L9 L12 L15 L18 |
| R2 | R3 | L9 L7 L11 L16 L17 |say we get a request to set up an LSP between R1 and R2 🎀 Then an RWA algorithm finds these possible solutions 🧩
+WL + Path +
| WL1| L1 L3 L5 L8 |
| WL1| L1 L3 L5 L9 |
| WL2| L2 L4 L6 L7 L8|
| WL2| L2 L4 L6 L7 L9|
| WL2| L2 L4 L6 L10 |now let's say an RWA algorithm picks WL1 and the path L1 L3 L5 L8 for that requested LSP 💜
next up, another LSP gets signaled from R1 to R2 💫 With the LSP on WL1 already established, here's what paths are still available 👀
+WL + Path +
| WL2| L2 L4 L6 L7 L9|
| WL2| L2 L4 L6 L10 |so this time the RWA algorithm picks WL2 and the path L2 L4 L6 L7 L9 to establish the new LSP 🦋
and now the plot twist 😭 An LSP request from R2 to R3 CANNOT be fulfilled, because the four possible paths (starting at L8 and L9) are all already in use 🙈
5.3. Resource Optimization ✨
okay so the example we just looked at opens up another use case: optimizing network resources 💅. Optimization can happen on a number of layers (like through electrical or optical multiplexing of client signals), or by re-optimizing the solutions an RWA algorithm already found 🫶.
Using that same example again, say an RWA algorithm needs to find a path between R2 and R3. The only possible way to reach R3 from R2 is through L9, and L9 is blocked by one of the LSPs from R1 😭.
5.4. Support for Rerouting 🦋
It's also envisioned that the GMPLS and PCE extensions will support rerouting wavelengths when failures happen 🔥.
For this discussion, let's assume the only two LSPs in use in the system are:
LSP1: WL1 L1 L3 L5 L8
LSP2: WL2 L2 L4 L6 L7 L9Now imagine L5 fails. An RWA algorithm can compute and establish an alternate path like this:
R1 -> N7 -> R2Level 3 regeneration will happen at N7, so the complete path ends up looking like this:
R1 -> L2 L4 L6 L11 L13 -> O1 -> L14 L16 L15 L12 L9 -> R25.5. Electro-Optical Networking Scenarios 🌈
In the subsections that follow, we're looking at a bunch of different networking scenarios involving regenerators, OEO switches, and wavelength converters 🧚. These scenarios can be roughly grouped by type and by how many extensions to the GMPLS control plane they'd need.
5.5.1. Fixed Regeneration Points ⭐
In the simplest regenerator scenario, regeneration is tied to a WDM link or to an entire node, and it's not optional. That means every signal going through that link or node gets regenerated 💖. This includes OEO switches too, since they regenerate on every port.
There may be input constraints and output constraints on the regenerators. So the path selection process needs to know about those regenerator constraints, either from routing or some other means, so it can pick a compatible path 🎀. For impairment-aware routing and wavelength assignment (IA-RWA), the path selection process also needs to know which links and nodes provide regeneration. Even for "regular" RWA, this regeneration info is useful, because wavelength converters typically perform regeneration, and at that point the wavelength continuity constraint can be relaxed 🍓.
Signaling doesn't need to be enhanced for this scenario, since there are no reconfigurable regenerator options on input, output, or processing 💅.
5.5.2. Shared Regeneration Pools 🫧
In this scenario, some nodes in the network have shared regenerator pools, on top of the fixed regenerators from the previous scenario 🌸. These regenerators are shared within a node, and applying them to a signal is optional. There are no reconfigurable options on either input or output. The only processing choice is whether to "regenerate" a particular signal or not 🙈.
Here, the regenerator information gets used in path computation so the path picked ensures signal compatibility and meets the IA-RWA criteria 👑.
To set up an LSP that uses a regenerator from a node with a shared regenerator pool, you need to indicate that regeneration should happen at that particular node along the signal path 💜. This capability doesn't exist in GMPLS signaling yet 💀.
5.5.3. Reconfigurable Regenerators 🔧
This scenario is all about regenerators that need to be configured before they can be used on an optical signal ✨. As we talked about earlier, that could be because the regenerator has to be set up to accept signals with different characteristics, because it has a choice of output attributes, or because it has extra optional processing capabilities.
Like in the previous scenarios, we need information about the regenerator properties in order to select compatible paths and do the IA-RWA computations 🦋. On top of that, during LSP setup, it's necessary to be able to configure the regenerator options at a particular node along the path 😭. Again, GMPLS signaling doesn't have this capability right now 🥲.
5.5.4. Relation to Translucent Networks 🌙
Networks that have both transparent network elements, like Reconfigurable Optical Add/Drop Multiplexers (ROADMs), and electro-optical network elements, like regenerators or OEO switches, are often called translucent optical networks 🫶.
Three main types of translucent optical networks have been discussed:
- Transparent "islands" surrounded by regenerators. This shows up a lot when you move from a metro optical subnetwork to a long-haul one 🚇.
- Mostly transparent networks with a limited number of OEO ("opaque") nodes placed strategically. This takes advantage of the built-in regeneration abilities of OEO switches. When planning these networks, you have to figure out the best placement for the OEO switches 📍.
- Mostly transparent networks with a limited number of optical switching nodes that have "shared regenerator pools," which can optionally be applied to signals passing through those switches. These switches are sometimes called translucent nodes 💅.
All three types of translucent networks fit into the networking scenarios of Sections 5.5.1 and 5.5.2. So the GMPLS extensions envisioned in this document can accommodate them all 🎀✨.
6. GMPLS and PCE Implications 🧠
How much wavelength conversion is available at a wavelength switching interface affects what information the control plane (GMPLS) and the PCE architecture need to pass around 💖. Current GMPLS and PCE standards already cover the full wavelength conversion case, so the subsections below only look at the limited and no wavelength conversion cases 🌈.
6.1. Implications for GMPLS Signaling 📡
Basic WSON signaling already exists in GMPLS. There's the lambda (value 9) LSP encoding type from [RFC3471], and for G.709-compatible optical channels there's the LSP encoding type (value = 13) "G.709 Optical Channel" from [RFC4328] 🔥. That said, a number of practical issues come up when identifying wavelengths and signals, and in distributed wavelength assignment processes. We'll go through those below 🫶.
6.1.1. Identifying Wavelengths and Signals 🏷️
As we said before, a global-fixed mapping between wavelengths and labels makes it way easier to characterize WDM links and WSON devices 💅. On top of that, a mapping like the one described in [RFC6205] provides a fixed mapping for communication between a PCE and WSON PCCs 🧚.
6.1.2. WSON Signals and Network Element Processing ⚡
As discussed in Section 3.3.2, a WSON signal can be characterized at any point along its path by its (a) modulation format, (b) FEC, (c) wavelength, (d) bitrate, and (e) G-PID 💜.
Right now, G-PID, wavelength (via labels), and bitrate (via bandwidth encoding) are supported in [RFC3471] and [RFC3473]. These RFCs can handle the wavelength changing at any node along the LSP, so they can provide explicit control of wavelength converters 🎀.
In the fixed regeneration point scenario from Section 5.5.1, no signaling enhancements are needed, since there are no extra configuration options for the LSP at a node 🙌.
For the shared regeneration pools from Section 5.5.2, though, it's necessary to tell a node that it should regenerate a particular signal. Looking at it the other way, for an LSP it's desirable to specify that certain nodes along the path do regeneration 😭. GMPLS signaling doesn't have this capability yet 💀.
The reconfigurable regenerators from Section 5.5.3 are very similar to that last case, except now there could be a lot more items to configure on a per-node basis for an LSP 🌸.
Also, note that the techniques in [RFC5420], which allow for additional LSP attributes to be recorded in a Record Route Object (RRO), could be extended to allow for additional LSP attributes in an Explicit Route Object (ERO) 🦋. That could let you indicate where optional 3R regeneration should happen along a path, any modifications to LSP attributes like modulation format, or any enhanced processing like performance monitoring 📊✨.
6.1.3. Combined RWA/Separate Routing WA support 🧩
In either the combined RWA case or the separate routing WA case, the node that starts the signaling already has a route from source to destination, along with the wavelengths (generalized labels) to use on portions of the path 💖. Current GMPLS signaling supports an Explicit Route Object (ERO), and inside an ERO, an ERO Label subobject can indicate the wavelength to use at a particular node 🎀. If the local label map approach is used, the label subobject entry in the ERO has to be interpreted appropriately 🫧.
6.1.4. Distributed Wavelength Assignment: Unidirectional, No Converters 🌈
GMPLS signaling for a unidirectional optical path LSP lets you use a Label Set object in the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) path message 🔥. Processing the Label Set object to take the intersection of available lambdas along a path can be done, and that leaves the destination knowing the set of available lambdas. The destination can then run a wavelength selection algorithm to pick a lambda 💅.
6.1.5. Distributed Wavelength Assignment: Unidirectional, Limited Converters ⚡
When wavelength converters are involved, nodes that have them need to decide whether to actually convert 🤔. One indicator is that the set of available wavelengths, found by intersecting the incoming Label Set with the output link's available wavelengths, is either null or looks too small to complete successfully 🙈.
At that point, the node needs to remember that it'll apply wavelength conversion, and that it'll be responsible for assigning the wavelength on the previous lambda-contiguous segment when the RSVP-TE RESV message gets processed 🧚. The node then passes along an enlarged label set that only reflects the limits of the wavelength converter and the output link 🦋. The record route option in RSVP-TE signaling can show where wavelength conversion took place 🗺️.
6.1.6. Distributed Wavelength Assignment: Bidirectional, No Converters ↔️
Some bidirectional optical paths need the same lambda in both directions 💜. The procedure above can determine the available bidirectional lambda set, as long as the available Label Set is treated as available in both directions 🎀. According to Section 4.1 of [RFC3471], a bidirectional LSP is set up when an upstream label shows up in the path message 🫶.
However, until the intersection of the available Label Sets has been determined along the path and at the destination node, the upstream label information might not be correct 😬. This case can be supported with current GMPLS mechanisms, but it may not be as efficient as an optimized bidirectional single-label allocation mechanism 🥺.
6.2. Implications for GMPLS Routing 🌸
okay bestie, so GMPLS routing [RFC4202] already has an interface capability descriptor for "Lambda Switch Capable" (LSC) ✨. It can describe the interfaces on a ROADM or any other kind of wavelength selective switch 🔥. The topology info usually travels over an Interior Gateway Protocol (IGP), but to minimally characterize a WSON you'd also need to convey these subsystem properties 👑:
- WDM link properties (allowed wavelengths)
- Optical transmitters (wavelength range)
- ROADM/FOADM properties (connectivity matrix, port wavelength restrictions)
- Wavelength converter properties (per network element, may change if a common limited shared pool is used)
This info is modeled in detail in [WSON-Info], and there's a compact encoding in [WSON-Encode] 🧚.
6.2.1. Electro-Optical Element Signal Compatibility 💜
ngl this part is so important. When signal compatibility is a concern, you need to add parameters to the existing node and link models so path computations can account for electro-optical input constraints, output constraints, and the signal-processing capabilities of an NE 🫶.
Input constraints:
- Permitted optical tributary signal classes: A list of optical tributary signal classes that can be processed by this network element or carried over this link (configuration type)
- Acceptable FEC codes (configuration type)
- Acceptable bitrate set: a list of specific bitrates or bitrate ranges that the device can accommodate. Coarse bitrate info is included with the optical tributary signal-class restrictions.
- Acceptable G-PID list: a list of G-PIDs corresponding to the "client" digital streams that is compatible with this device
Note that the bitrate of the signal does not change over the LSP 🎀. This can be communicated as an LSP parameter, so this information is available for any NE that needs it for configuration. Hence, it isn't necessary to have a "configuration type" for the NE with respect to bitrate. It's giving efficiency 💅.
Output constraints:
- Output modulation: (a) same as input, (b) list of available types
- FEC options: (a) same as input, (b) list of available codes
Processing capabilities:
- Regeneration: (a) 1R, (b) 2R, (c) 3R, (d) list of selectable regeneration types
- Fault and performance monitoring: (a) G-PID particular capabilities, (b) optical performance monitoring capabilities.
Note that these parameters could be specified on (a) a network-element-wide basis, (b) a per-port basis, or (c) a per-regenerator basis. Typically, this information has been on a per-port basis. See the GMPLS interface switching capability descriptor [RFC4202] 🦋.
6.2.2. Wavelength-Specific Availability Information 🌈
For wavelength assignment, you need to know which specific wavelengths are available and which are occupied, if a combined RWA process or a separate WA process is run as discussed in Sections 4.1.1 and 4.1.2. This is currently not possible with GMPLS routing 😭.
The routing extensions for GMPLS [RFC4202] discuss requirements for layer-specific TE attributes. RWA for optical networks without wavelength converters adds one more requirement for the lambda (or optical channel) layer: knowing which specific wavelengths are in use. Current DWDM systems range from 16 channels to 128 channels, with advanced laboratory systems reaching as many as 300 channels. Given those channel limits, if you go with a global wavelength to label mapping, or hand the local mappings to the PCEs, representing wavelength use with a simple bitmap is feasible [Gen-Encode] ✨.
6.2.3. WSON Routing Information Summary 📋
The following table summarizes the WSON information that could be conveyed via GMPLS routing. It also sorts that information by whether it's static or dynamic, and whether it's tied to a link or a node.
Information Static/Dynamic Node/Link
------------------------------------------------------------------
Connectivity matrix Static Node
Per-port wavelength restrictions Static Node(1)
WDM link (fiber) lambda ranges Static Link
WDM link channel spacing Static Link
Optical transmitter range Static Link(2)
Wavelength conversion capabilities Static(3) Node
Maximum bandwidth per wavelength Static Link
Wavelength availability Dynamic(4) Link
Signal compatibility and processing Static/Dynamic NodeNotes:
- These are the per-port wavelength restrictions of an optical device such as a ROADM, and they're independent of any optical constraints imposed by a fiber link.
- This could also be viewed as a node capability.
- This could be dynamic in the case of a limited pool of converters, where the number available can change with connection establishment. Note that it may be desirable to include regeneration capabilities here, since OEO converters are also regenerators.
- This isn't necessarily needed in the case of distributed wavelength assignment via signaling.
The full set of information from the previous table is needed in the Combined RWA and the separate Routing and WA architectures. In the case of Routing + Distributed WA via Signaling, though, only the following information is needed 🧚♀️:
Information Static/Dynamic Node/Link
------------------------------------------------------------------
Connectivity matrix Static Node
Wavelength conversion capabilities Static(3) NodeInformation models and compact encodings for this information are provided in [WSON-Info], [Gen-Encode], and [WSON-Encode] 💖.
6.3. Optical Path Computation and Implications for PCE 🧠
As noted before, RWA can be computationally intensive 😤. Those heavy path computations and optimizations were part of the impetus for the PCE architecture [RFC4655].
The Path Computation Element Communication Protocol (PCEP) defines the procedures needed to support both sequential [RFC5440] and Global Concurrent Optimization (GCO) path computations [RFC5557]. With some protocol enhancement, PCEP is well positioned to support WSON-enabled RWA computation 💅.
Implications for PCE generally fall into two main categories: (a) optical path constraints and characteristics, (b) computation architectures.
6.3.1. Optical Path Constraints and Characteristics 🦋
For the varying degrees of optimization you might run into in a network, these are the models of bulk and sequential optical path requests you'll see:
- Batch optimization, multiple optical paths requested at one time (PCE-GCO)
- Optical path(s) and backup optical path(s) requested at one time (PCEP)
- Single optical path requested at a time (PCEP)
PCEP and PCE-GCO can be readily enhanced to support all of the potential models of RWA computation 🔥.
Optical path constraints include:
- Bidirectional assignment of wavelengths
- Possible simultaneous assignment of wavelength to primary and backup paths
- Tuning range constraint on optical transmitter
6.3.2. Electro-Optical Element Signal Compatibility 🎀
When requesting a path computation from a PCE, the PCC should be able to indicate the following 🫶:
- The G-PID type of an LSP
- The signal attributes at the transmitter (at the source): (i) modulation type, (ii) FEC type
- The signal attributes at the receiver (at the sink): (i) modulation type, (ii) FEC type
The PCE should be able to respond to the PCC with the following:
- The conformity of the requested optical characteristics associated with the resulting LSP with the source, sink, and NE along the LSP
- Additional LSP attributes modified along the path (e.g., modulation format change)
6.3.3. Discovery of RWA-Capable PCEs 🔍
The algorithms and network information needed for RWA are somewhat specialized and computationally intensive. So not every PCE in a domain would necessarily need or want this capability 🙈. It would be useful to indicate that a PCE can deal with RWA through the mechanisms being established for PCE discovery [RFC5088]. [RFC5088] indicates that a sub-TLV could be allocated for this purpose.
Recent progress on objective functions in PCE [RFC5541] would let operators flexibly request different objective functions based on their needs and applications. For instance, an operator could choose an objective function that minimizes the total network cost of setting up a set of paths concurrently. Operators could also choose one that results in the most evenly distributed link utilization 📊.
This implies that PCEP could easily accommodate a wavelength selection algorithm in its objective function, so the path computation can be optimized from the perspective of wavelength assignment, if operators choose it 🌸.
7. Security Considerations 🔐
This document does not require changes to the security models within GMPLS and associated protocols. That is, the OSPF-TE, RSVP-TE, and PCEP security models could be operated unchanged 💜.
Okay, but here's the plot twist 😱. Satisfying the requirements for RWA using the existing protocols may significantly affect the loading of those protocols. That may make the operation of the network more vulnerable to denial-of-service attacks. Therefore, additional care maybe required to ensure that the protocols are secure in the WSON environment 💀.
Furthermore, the additional information distributed in order to address RWA is a disclosure of network capabilities that an operator may wish to keep private. Consideration should be given to securing this information 🔒. For a general discussion on MPLS- and GMPLS-related security issues, see the MPLS/GMPLS security framework [RFC5920] ✨.
8. Acknowledgments 🫶
The authors would like to thank Adrian Farrel for many helpful comments that greatly improved the contents of this document 💖.
9. References 📚
9.1. Normative References 📚✨
These are the must-reads, the ones you need to know to get the full picture 💅
- [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
- [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
- [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
- [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
- [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, January 2006.
- [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
- [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008.
- [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, M., and D. Brungard, "Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July 2008.
- [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization", RFC 5557, July 2009.
- [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, February 2009.
- [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
- [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC 5541, June 2009.
9.2. Informative References 🧚
These are the extra-credit reads 🎀 super useful to know about, but you don't need them to get the main idea.
- [Gen-Encode] Bernstein, G., Lee, Y., Li, D., and W. Imajuku, "General Network Element Constraint Encoding for GMPLS Controlled Networks", Work in Progress, December 2010.
- [G.652] ITU-T Recommendation G.652, "Characteristics of a single-mode optical fibre and cable", November 2009.
- [G.653] ITU-T Recommendation G.653, "Characteristics of a dispersion-shifted single-mode optical fibre and cable", July 2010.
- [G.654] ITU-T Recommendation G.654, "Characteristics of a cut-off shifted single-mode optical fibre and cable", July 2010.
- [G.655] ITU-T Recommendation G.655, "Characteristics of a non-zero dispersion-shifted single-mode optical fibre and cable", November 2009.
- [G.656] ITU-T Recommendation G.656, "Characteristics of a fibre and cable with non-zero dispersion for wideband optical transport", July 2010.
- [G.671] ITU-T Recommendation G.671, "Transmission characteristics of optical components and subsystems", January 2009.
- [G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM applications: DWDM frequency grid", June 2002.
- [G.694.2] ITU-T Recommendation G.694.2, "Spectral grids for WDM applications: CWDM wavelength grid", December 2003.
- [G.698.1] ITU-T Recommendation G.698.1, "Multichannel DWDM applications with single-channel optical interfaces", November 2009.
- [G.698.2] ITU-T Recommendation G.698.2, "Amplified multichannel dense wavelength division multiplexing applications with single channel optical interfaces", November 2009.
- [G.707] ITU-T Recommendation G.707, "Network node interface for the synchronous digital hierarchy (SDH)", January 2007.
- [G.709] ITU-T Recommendation G.709, "Interfaces for the Optical Transport Network (OTN)", December 2009.
- [G.872] ITU-T Recommendation G.872, "Architecture of optical transport networks", November 2001.
- [G.959.1] ITU-T Recommendation G.959.1, "Optical transport network physical layer interfaces", November 2009.
- [G.Sup39] ITU-T Series G Supplement 39, "Optical system design and engineering considerations", December 2008.
- [Imajuku] Imajuku, W., Sone, Y., Nishioka, I., and S. Seno, "Routing Extensions to Support Network Elements with Switching Constraint", Work in Progress, July 2007.
- [RFC6205] Otani, T., Ed. and D. Li, Ed., "Generalized Labels of Lambda-Switch Capable (LSC) Label Switching Routers", RFC 6205, March 2011.
- [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
- [WSON-Encode] Bernstein, G., Lee, Y., Li, D., and W. Imajuku, "Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks", Work in Progress, March 2011.
- [WSON-Imp] Lee, Y., Bernstein, G., Li, D., and G. Martinelli, "A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments", Work in Progress, April 2011.
- [WSON-Info] Bernstein, G., Lee, Y., Li, D., and W. Imajuku, "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks", Work in Progress, July 2008.
Contributors 🫶
The amazing people who helped bring this to life 💖
Snigdho Bardalai
Fujitsu
EMail: Snigdho.Bardalai@us.fujitsu.com
Diego Caviglia
Ericsson
Via A. Negrone 1/A 16153
Genoa
Italy
Phone: +39 010 600 3736
EMail: diego.caviglia@marconi.com, diego.caviglia@ericsson.com
Daniel King
Old Dog Consulting
UK
EMail: daniel@olddog.co.uk
Itaru Nishioka
NEC Corp.
1753 Simonumabe, Nakahara-ku
Kawasaki, Kanagawa 211-8666
Japan
Phone: +81 44 396 3287
EMail: i-nishioka@cb.jp.nec.com
Lyndon Ong
Ciena
EMail: Lyong@Ciena.com
Pierre Peloso
Alcatel-Lucent
Route de Villejust, 91620 Nozay
France
EMail: pierre.peloso@alcatel-lucent.fr
Jonathan Sadler
Tellabs
EMail: Jonathan.Sadler@tellabs.com
Dirk Schroetter
Cisco
EMail: dschroet@cisco.com
Jonas Martensson
Acreo
Electrum 236
16440 Kista
Sweden
EMail: Jonas.Martensson@acreo.seAuthors' Addresses 🎀
Meet the crew behind the spec 🌸
Young Lee (editor)
Huawei Technologies
1700 Alma Drive, Suite 100
Plano, TX 75075
USA
Phone: (972) 509-5599 (x2240)
EMail: ylee@huawei.com
Greg M. Bernstein (editor)
Grotto Networking
Fremont, CA
USA
Phone: (510) 573-2237
EMail: gregb@grotto-networking.com
Wataru Imajuku
NTT Network Innovation Labs
1-1 Hikari-no-oka, Yokosuka, Kanagawa
Japan
Phone: +81-(46) 859-4315
EMail: wataru.imajuku@ieee.org📦 where this page comes from
- ietf: rfc6163 2011-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms