RFC 6566
A Framework for the Control of Wavelength Switched Optical Networks (WSONs) with Impairments
RFC 6566: A Framework for the Control of Wavelength Switched Optical Networks (WSONs) with Impairments 🌈
okay bestie, this is RFC 6566 💖 It came out in March 2012 and is marked Informational 🎀, so it's a guide, not a strict rulebook. The IETF is the publisher. Y. Lee (Huawei) and G. Bernstein (Grotto Networking) are the editors, and D. Li (Huawei) and G. Martinelli (Cisco) are also authors. The ISSN is 2070-1721 ✨. Its header doesn't list anything it obsoletes or updates, so it doesn't replace any older RFC and doesn't change any older RFC either 🧚.
Abstract 🦋
Okay so picture a signal zooming down a fiber 🌸 Along the way it gets messed with by all kinds of physics happening in the fibers and devices it passes through. When that messing-around actually makes the signal worse, people call it "impairments" 😭 Those effects can be a big deal when you're using a GMPLS control plane to set up and keep up paths in wavelength switched optical networks, so they need to be part of the plan 💅
This document gives a framework for using GMPLS protocols and the Path Computation Element (PCE) architecture to handle Impairment-Aware Routing and Wavelength Assignment (IA-RWA) in those networks 🔥 It talks about the key computing constraints, the scenarios, and the architectural processes: routing, wavelength assignment, and impairment validation. What it does NOT do is define the optical data plane stuff, the impairment parameters, or how you measure or qualify a route 🙈 Instead it describes the architecture and the information pieces that protocol solutions will need 👑
Status of This Memo ⭐
Not gonna lie, this part is kinda formal, but it matters 🙈 This document is not an Internet Standards Track spec. It's published just for information 💜
It's a product of the Internet Engineering Task Force (IETF) and reflects consensus from the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is up for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 🎀
For the latest status, errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6566 🌸
Copyright Notice 💅
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved ✨
This document is covered by 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 of the publication date) 📜 Read those carefully, because they spell out your rights and restrictions for this doc 🙈 Any Code Components you pull out of this document have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License says 🧚
Table of Contents 🗺️
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Applicability ...................................................6
4. Impairment-Aware Optical Path Computation .......................7
4.1. Optical Network Requirements and Constraints ...............8
4.1.1. Impairment-Aware Computation Scenarios ..............9
4.1.2. Impairment Computation and
Information-Sharing Constraints ....................10
4.1.3. Impairment Estimation Process ......................11
4.2. IA-RWA Computation and Control Plane Architectures ........13
4.2.1. Combined Routing, WA, and IV .......................15
4.2.2. Separate Routing, WA, or IV ........................15
4.2.3. Distributed WA and/or IV ...........................16
4.3. Mapping Network Requirements to Architectures .............16
5. Protocol Implications ..........................................19
5.1. Information Model for Impairments .........................19
5.2. Routing ...................................................20
5.3. Signaling .................................................21
5.4. PCE .......................................................21
5.4.1. Combined IV & RWA ..................................21
5.4.2. IV-Candidates + RWA ................................22
5.4.3. Approximate IA-RWA + Separate Detailed-IV ..........24
6. Manageability and Operations ...................................25
7. Security Considerations ........................................26
8. References .....................................................27
8.1. Normative References ......................................27
8.2. Informative References ....................................27
9. Contributors ...................................................291. Introduction 🌈
Okay, so WSONs are built out of a bunch of subsystems 💖 That can include WDM-style links, tunable transmitters and receivers, Reconfigurable Optical Add/Drop Multiplexers (ROADMs), wavelength converters, and electro-optical network elements 🦋 A WSON is a Wavelength Division Multiplexing (WDM)-based optical network that switches traffic based on the center wavelength of each optical signal 🎀
Same vibe as the abstract: as a signal moves along its path, the fibers and devices it runs into can mess with it 😭 When that makes the signal worse, people call it "impairments" 💅 These impairments pile up along the path, and that's true unless 3R regeneration is in play [G.680] ✨ What causes them depends on the fiber type, which optical devices are used and where, and whether other optical signals share a fiber segment on the same path 🌸 All that degradation can lead to unacceptable bit error rates, or even a total failure to demodulate and/or detect the received signal 💀
To set up an optical connection (an optical path) through a WSON, you need path continuity, resource availability, and impairment constraints all met at once 🔥 Finding the paths that are actually viable and optimal is called Impairment-Aware Routing and Wavelength Assignment (IA-RWA) 👑
GMPLS [RFC3945] is a set of control plane protocols that can run networks anywhere from packet switch capable ones to networks using time division multiplexing and WDM 🧚 The Path Computation Element (PCE) architecture [RFC4655] defines computation components that can team up with the GMPLS control plane to compute and suggest good paths 💜 [RFC4054] gives an overview of optical impairments and what they mean for routing (path selection) in GMPLS 🎀 This document uses [G.680] and other ITU-T Recommendations as its references for the optical data plane stuff 🫶
So this document gives a framework for using GMPLS protocols and the PCE architecture to control and run IA-RWA for WSONs ✨ To make that easier to evaluate, it walks through the subsystems and processes that make up WSONs, and it describes IA-RWA models based on the matching ITU-T Recommendations 🌸 That way we can figure out what information GMPLS and PCE systems need 🙌 And this work will help grow protocol extensions for IA-RWA inside the GMPLS and PCE protocol families 🔥
2. Terminology 💅
Here's the glossary, bestie 📖 Every term keeps its meaning from the original 🌸
- ADM: Add/Drop Multiplexer. An optical device used in WDM networks, made of one or more line side ports and, usually, lots of tributary ports 🦋
- Black Links: Tributary interfaces where only the link characteristics are defined 💜 This lets you get transverse compatibility at the single-channel point with a direct wavelength-multiplexing setup 🧚
- CWDM: Coarse Wavelength Division Multiplexing 🌈
- DGD: Differential Group Delay ✨
- DWDM: Dense Wavelength Division Multiplexing 💖
- FOADM: Fixed Optical Add/Drop Multiplexer 🎀
- GMPLS: Generalized Multi-Protocol Label Switching 🌸
- IA-RWA: Impairment-Aware Routing and Wavelength Assignment 👑
- Line Side: In a WDM system, line side ports and links can usually carry the full multiplex of wavelength signals 🔥 Tributary (add or drop) ports, on the other hand, usually carry only a few wavelength signals, often just one 💅
- NEs: Network Elements 🫶
- OADMs: Optical Add/Drop Multiplexers ✨
- OSNR: Optical Signal-to-Noise Ratio 🌸
- OXC: Optical Cross-Connect. An optical switching element where a signal on any input port can get to any output port 🦋
- PCC: Path Computation Client. Any client app that asks the Path Computation Element to do a path computation 💜
- PCE: Path Computation Element. An entity (a component, an application, or a network node) that can compute a network path or route, based on a network graph and computational constraints 🧚
- PCEP: PCE Communication Protocol. The communication protocol between a Path Computation Client and a Path Computation Element 🌈
- PXC: Photonic Cross-Connect 💖
- Q-Factor: Gives a qualitative picture of receiver performance, and it depends on the optical signal-to-noise ratio 🎀 It hints at the minimum SNR (Signal-to-Noise Ratio) needed to hit a certain bit error rate (BER) for a given signal 😭
- ROADM: Reconfigurable Optical Add/Drop Multiplexer. A wavelength-selective switching element with input and output line side ports, plus add/drop tributary ports 👑
- RWA: Routing and Wavelength Assignment 🔥
- Transparent Network: A WSON with no regenerators or wavelength converters 🌸
- Translucent Network: A WSON that's mostly transparent but may also have a limited number of regenerators and/or wavelength converters 🫶
- Tributary: A link or port on a WDM system that can carry way less than the full multiplex of wavelength signals the line side links/ports carry 💅 Typical tributary ports are the add and drop ports on an ADM, and they support only a single wavelength channel 🦋
- Wavelength Conversion/Converters: Turning an information-bearing optical signal centered at one wavelength into information with "equivalent" content centered at a different wavelength 🌈 This can happen through an optical-electronic-optical (OEO) process or a strictly optical process ✨
- WDM: Wavelength Division Multiplexing 💜
- Wavelength Switched Optical Networks (WSONs): WDM-based optical networks that switch traffic selectively based on the center wavelength of an optical signal 🧚
To be continued in part 2, bestie 🌈💖
3. Applicability ✨
Okay so, not every path in a WSON is gonna have good enough signal quality, and that's just the reality of optical networks 💅 Here are some of the reasons (not all of them, just the non-exhaustive highlights 🦋):
- Okay, WSONs are glowing up 🌈 with multi-degree optical cross-connects, and their topologies are shifting from rings (and interconnected rings) into general mesh. Adding amplifiers or regenerators just to make every path work leads to an over-provisioned network 😩. And even with all that over-provisioning, the network could still have some infeasible paths 💀.
- The optical physical interface can change over the network's life, like when the interfaces get upgraded to higher bitrates 🚀. That can make some paths unsuitable for the optical signal 🙈. Also, optical physical interfaces usually get provisioned at different stages of the network's life, whenever traffic demands call for them 🧚.
- Sometimes a network gets upgraded by adding new optical cross-connects for extra flexibility ✨. Then existing paths have their feasibility changed, and brand-new paths need their feasibility checked 🎀.
- Bitrates jumped from 10G to 40G and 100G over a single wavelength, so WSONs will probably run a mix of wavelengths at different bitrates 🌸. That brings impairment constraints, because different bitrates and modulation formats physically behave differently 👑.
Without an impairment-aware control plane, these networks need a way more complicated design phase that has to account for how the equipment and traffic are changing from the very beginning 😭. On top of that, things like path establishment need a lot of pre-design through non-control-plane processes, so provisioning ends up significantly slower 🐢.
It's worth highlighting that how impairments affect whether a path is viable isn't well established enough for general applicability [G.680] 🤷♀️. It depends on how each network is implemented 💖. So whether to use an impairment-aware control plane, and which information gets distributed, has to be evaluated on a case-by-case basis 🫶.
4. Impairment-Aware Optical Path Computation 🔥
The basic criterion for path selection is whether the signal can be successfully sent from a transmitter to a receiver within a prescribed error tolerance, usually given as a maximum permissible BER 🎯. That depends on the kind of signal being sent and on the communications channel between sender and receiver. The optical path used (along with the wavelength) is what determines that channel 🌈.
The optical impairments that the signal picks up along the fiber, and at each optical network element on the path, decide whether the BER performance (or any other measure of signal quality) can be met for a signal on a particular end-to-end path 💅.
Impairment-aware path calculation also has to consider when regeneration is used along the path. [RFC6163] gives background on the idea of optical translucent networks, which contain transparent elements and electro-optical elements like OEO regenerations 🦋. In these networks, a generic light path can go through a number of regeneration points ✨.
Regeneration points can happen for two reasons:
(i) Wavelength conversion is performed to help RWA avoid wavelength blocking. This is the impairment-free case covered by [RFC6163] 🌸.
(ii) The optical signal would be too degraded to meet end-to-end BER requirements without regeneration. This is the case when RWA takes impairment estimation (covered by this document) into consideration 😩.
In the latter case, an optical path can be seen as a set of transparent segments 🧚. The impairment calculations need to be reset at each regeneration point, so each transparent segment gets its own impairment evaluation 💜.
+---+ +----+ +----+ +-----+ +----+ +---+
| I |----| N1 |---| N2 |-----| REG |-----| N3 |----| E |
+---+ +----+ +----+ +-----+ +----+ +---+
|<----------------------------->|<-------------------->|
Segment 1 Segment 2Figure 1. Optical Path as a Set of Transparent Segments
Take Figure 1 as an example: it shows an optical path from node I to node E, with a regeneration point, REG, in between 👑. This is feasible from an impairment validation perspective if both segments (I, N1, N2, REG) and (REG, N3, E) are feasible 🎀.
4.1. Optical Network Requirements and Constraints 🌈
This section looks at the different optical network requirements and constraints an impairment-aware optical control plane may have to work under 🔍. These requirements and constraints are what motivate the IA-RWA architectural alternatives presented in Section 4.2 ✨. Different optical network contexts can be broken into two main criteria: (a) the accuracy required in the estimation of impairment effects, and (b) the constraints on the impairment estimation computation and/or on sharing impairment information 💅.
4.1.1. Impairment-Aware Computation Scenarios 💖
A. No Concern for Impairments or Wavelength Continuity Constraints
This situation is covered by existing GMPLS with local wavelength (label) assignment 🦋.
B. No Concern for Impairments, but Wavelength Continuity Constraints
This situation applies to networks designed so that every possible path is valid for the signal types permitted on the network 🌸. In this case, impairments are only taken into account during network design. After that (for example, during optical path computation), they can be ignored 🙈. This is the case discussed in [RFC6163], where impairments may be ignored by the control plane and only the optical parameters related to signal compatibility are considered 🫶.
C. Approximated Impairment Estimation
This situation applies to networks where impairment effects need to be considered, but there's a sufficient margin that they can be estimated with approximation techniques such as link budgets and dispersion [G.680] [G.Sup39] 🧚. The viability of optical paths for a particular class of signals can be estimated using well-defined approximation techniques [G.680] [G.Sup39]. This is generally known as the linear case, where only linear effects are taken into account 📐. Note that adding or removing an optical signal on the path should not render any of the existing signals in the network non-viable 😭. For example, one form of non-viability is when existing links get transients big enough to impact the BER of existing signals 💀.
Much work at ITU-T has gone into developing impairment models at this level and at more detailed levels 👑. Impairment characterization of network elements may be used to calculate which paths conform to a specified BER for a particular signal type 🎯. In that case, the impairment-aware (IA) path computation can be combined with the RWA process to allow more optimal IA-RWA computations ✨. The IA path computation may also take place in a separate entity, i.e., a PCE 💜.
D. Accurate Impairment Computation
This situation applies to networks where impairment effects must be computed more accurately 🔥. For these networks, a full computation and evaluation of the impact on any existing paths needs to happen before a new path is added 😤. Right now, no impairment models are available from ITU-T, so this scenario is outside the scope of this document 🥲.
4.1.2. Impairment Computation and Information-Sharing Constraints 🎀
In GMPLS, the information used for path computation is standardized for distribution among the elements participating in the control plane, and any appropriately equipped PCE can perform path computation 💅. For optical systems, this may not be possible 😬. That's typically because only portions of an optical system are subject to standardization 🌸. In ITU-T Recommendations [G.698.1] and [G.698.2], which specify single-channel interfaces to multi-channel DWDM systems, only the single-channel interfaces (transmit and receive) are specified, while the multi-channel links are not standardized 🧚. These DWDM links are referred to as "black links," since their details are not generally available 🖤. However, the overall impact of a black link at the single-channel interface points is limited by [G.698.1] and [G.698.2] ✨.
Typically, a vendor might use proprietary impairment models for DWDM spans to estimate the validity of optical paths 🔒. For example, models of optical nonlinearities are not currently standardized 🌀. Vendors may also choose not to publish impairment details for links or a set of network elements, so they don't divulge their optical system designs 🤐.
In general, the impairment estimation (optical path validation) for optical networks with black links in the path could not be performed by a general-purpose IA computation entity 🙅♀️. That's because it would not have access to, or understand, the black-link impairment parameters 💀. However, impairment estimation (optical path validation) could be performed by a vendor-specific IA computation entity 👑. Such a vendor-specific IA computation entity could use standardized impairment information imported from other network elements in these proprietary computations 💖.
From here on, the term "black links" is used to describe these computation and information-sharing constraints in optical networks 🦋. From the control plane perspective, the following options are considered:
- The authority in control of the black links can furnish a list of all viable paths between all viable node pairs to a computation entity. This information would be particularly useful as an input to RWA optimization performed by another computation entity 🧠. The difficulty is that such a list of paths, along with any wavelength constraints, could get unmanageably large as the size of the network increases 😵💫.
- The authority in control of the black links could provide a PCE-like entity with a list of viable paths/wavelengths between two requested nodes 🎯. This is useful as an input to RWA optimizations and can reduce the scaling issue mentioned above ✨. Such a PCE-like entity would not need to perform a full RWA computation; i.e., it would not need to take into account current wavelength availability on links 🌸. This approach may require PCEP extensions for both the request and response information 🛠️.
- The authority in control of the black links provides a PCE that performs full IA-RWA services 👑. The difficulty here is that this option requires that one authority also become the sole source of all RWA optimization algorithms 😬.
In all of the above cases, it is the responsibility of the authority in control of the black links to import the shared impairment information from the other NEs via the control plane or other means as necessary 🫶💜
4.1.3. Impairment Estimation Process ✨
okay so the impairment estimation process can be modeled as a chain of functional blocks 🧠 and the best part is these blocks don't care what control plane architecture you're running. the same control plane function can implement all of them, or different ones can split the work, and we get into that in the following sections 🫶
+-----------------+
+------------+ +-----------+ | +------------+ |
| | | | | | | |
| Optical | | Optical | | | Optical | |
| Interface |------->| Impairment|--->| | Channel | |
| (Transmit/ | | Path | | | Estimation | |
| Receive) | | | | | | |
+------------+ +-----------+ | +------------+ |
| || |
| || |
| Estimation |
| || |
| \/ |
| +------------+ |
| | BER/ | |
| | Q Factor | |
| +------------+ |
+-----------------+Starting from the block on the left 👈 the optical interface is where the optical signal gets transmitted or received, and it defines the properties at the path endpoints. Even the impairment-free case, like scenario B in Section 4.1.1, needs a minimum set of interface characteristics 💅 In that case only a few parameters get used to assess signal compatibility (see [RFC6163]). For the impairment-aware case, those parameters might or might not be enough, depending on how much approximation you're okay with (scenarios C and D). So this block is basically the reason you need to consider a set of interface parameters during the impairment validation process 🎀
The "Optical Impairment Path" block covers the types of impairments that hit a wavelength as it travels through links and nodes 🌊 If the network has no impairments at all (scenario A), this block will not be present. Otherwise, this function must be implemented in some way via the control plane. Architectural alternatives for doing that are in Section 4.2. How this block gets implemented (for example, through routing, signaling, or a PCE) may influence the way the control plane distributes impairment information within the network 🧚
The last block is the decision function for path feasibility ⭐ How complicated it gets depends on the IA level of approximation. With no IA approximation, only the signal class compatibility gets verified. Besides a feasible or not-feasible answer, it can be worth having decision functions consider cases where a path would likely be feasible within some degree of confidence 🦋 Optical impairments usually aren't fixed numbers either. They can vary within ranges, depending on the approach taken in the physical modeling (worst-case, statistical, or based on typical values). For example, using the worst-case value for every parameter during impairment validation may mark some paths as not feasible, even though in reality they're very likely to be feasible 😭
4.2. IA-RWA Computation and Control Plane Architectures 🌈
Looking at it from the control plane point of view, optical impairments are extra constraints on top of the impairment-free RWA process described in [RFC6163] 💜 In IA-RWA there are conceptually three general classes of processes: Routing (R), Wavelength Assignment (WA), and Impairment Validation (IV), which is the same thing as estimation.
Impairment validation can show up in many forms and can be invoked at different levels of detail in the IA-RWA process. Every variation of impairment validation discussed in this section is based on scenario C ("Approximated Impairment Estimation") from Section 4.1.1. From a process point of view, there are three forms of impairment validation to look at:
- IV-Candidates
Here an IV process hands back a set of paths between two nodes, along with any wavelength restrictions, so that the paths are valid with respect to optical impairments. Those paths and wavelengths might not actually be free in the network right now, because of its current usage state. This set could be returned in response to a request for a set of at most K valid paths between two specified nodes. Note that this kind of process never directly discloses optical impairment information. Also, this case includes any paths between the source and destination that may have been "pre-validated" ✅
In this case the control plane just uses the candidate paths and doesn't have any optical impairment information. The other option is that path validity gets assessed within the control plane itself, and the next cases cover that situation 👀
- IV-Approximate Verification
Here, approximation methods estimate the impairments a signal experiences. Impairments are typically approximated using the linear and/or statistical characteristics of individual or combined components and fibers along the signal path 🧮
- IV-Detailed Verification
In this case an IV process gets a particular path and wavelength through an optical network and is asked whether the overall quality objectives for the signal over that path can be met 🎯 Note that this kind of process never directly discloses optical impairment information either.
The next two cases are about how an impairment validation computation gets performed from a decision-making point of view 🧠
- IV-Centralized
In this case, impairments for a path are computed at a single entity. The impairment information can still be gathered from network elements, though 📡 Depending on how that information is gathered, this may put extra requirements on routing protocols. We'll go deeper on this topic in later sections.
- IV-Distributed
In the distributed IV process, approximate degradation measures such as OSNR, dispersion, DGD, etc., may be accumulated along the path via signaling 🪄 Each node on the path may already do some part of the impairment computation (that's the distributed bit). When the accumulated measures reach the destination node, a decision on the impairment validity of the path can be made. Note that this kind of process would mean revealing an individual network element's impairment information, but it doesn't generally require distributing optical parameters to the entire network 🫣
The control plane must not preclude the possibility of concurrently performing one or all of the above cases in the same network 💅 For example, a certain number of paths might already be pre-validated (IV-Candidates), so the control plane can set up one of those paths without asking for any impairment validation procedure. On that same network, though, the control plane may compute a path outside the set of IV-Candidates, and for that path an impairment evaluation can be necessary.
The following three subsections present major classes of IA-RWA path computation architectures and go over some of their advantages and disadvantages 🌸
4.2.1. Combined Routing, WA, and IV 💖
From the point of view of optimality, reasonably good IA-RWA solutions can be achieved if the PCE can conceptually/algorithmically combine the processes of routing, wavelength assignment, and impairment validation 🔥
That combination can happen if the PCE is given (a) the impairment-free WSON information discussed in [RFC6163] and (b) impairment information to validate potential paths 🎀
4.2.2. Separate Routing, WA, or IV 🦋
Separating the processes of routing, WA, and/or IV can reduce how much information has to be shared for path computation. This was discussed for routing, separate from WA, in [RFC6163] 📚 On top of that, as discussed in Section 4.1.2, some impairment information may not be shared, and that may mean IV has to be separated from RWA. Also, if IV needs to be done at a high level of precision, it may be advantageous to offload that computation to a specialized server 🧚
The following conceptual architectures belong in this general category:
- R + WA + IV
separate routing, wavelength assignment, and impairment validation.
- R + (WA & IV)
routing separate from a combined wavelength assignment and impairment validation process. Note that impairment validation is typically wavelength dependent. Hence, combining WA with IV can lead to improved efficiency 📈
- (RWA) + IV
combined routing and wavelength assignment with a separate impairment validation process.
Note that the IV process may come before or after the RWA processes. If RWA comes first, then IV is just giving a yes/no decision on the selected path and wavelength. If IV comes first, it would need to hand a list of possible (valid with respect to impairments) routes and wavelengths over to the RWA processes 🫶
4.2.3. Distributed WA and/or IV 🌈
In the non-impairment RWA situation [RFC6163], it was shown that a distributed WA process carried out via signaling can get rid of the need to distribute wavelength availability information via an interior gateway protocol (IGP) 🙌 A similar approach can allow the distributed computation of impairment effects, which avoids the need to distribute impairment characteristics of network elements and links by routing protocols or by other means ✨ So the following conceptual options belong to this category:
- RWA + D(IV)
combined routing and wavelength assignment and distributed impairment validation.
- R + D(WA & IV)
routing separate from a distributed wavelength assignment and impairment validation process.
Distributed impairment validation for a prescribed network path requires that the effects of impairments be calculated by approximate models with cumulative quality measures such as those given in [G.680]. The protocol encoding of the impairment-related information from [G.680] would need to be agreed upon 🤓
If distributed WA is happening at the same time as distributed IV, then it's necessary to accumulate impairment-related information for all wavelengths that could be used. The amount of information shrinks a bit as potential wavelengths are discovered to be in use, but it could still be a significant burden for lightly loaded networks with high channel counts 😭💜
4.3. Mapping Network Requirements to Architectures ✨
okay so bestie, when approximate impairment validation is good enough 🫶 there are three main IA-RWA architectures you can pick from. Figure 2 shows their process flows. when you actually need detailed impairment verification 🔍 there are two main options, and Figure 3 shows how those flow. 💅
+-----------------------------------+
| +--+ +-------+ +--+ |
| |IV| |Routing| |WA| |
| +--+ +-------+ +--+ |
| |
| Combined Processes |
+-----------------------------------+
(a)
+--------------+ +----------------------+
| +----------+ | | +-------+ +--+ |
| | IV | | | |Routing| |WA| |
| |Candidates| |----->| +-------+ +--+ |
| +----------+ | | Combined Processes |
+--------------+ +----------------------+
(b)
+-----------+ +----------------------+
| +-------+ | | +--+ +--+ |
| |Routing| |------->| |WA| |IV| |
| +-------+ | | +--+ +--+ |
+-----------+ | Distributed Processes|
+----------------------+
(c)
Figure 2. Process Flows for the Three Main Approximate Impairment
Architectural Alternativeshere's the lowdown on what each one brings, what it needs, and when it's a vibe 💖
- Combined IV & RWA process 👑 this one smooshes RWA and IV together inside a single computation entity, which gives you the highest potential optimality and efficiency in IA-RWA ✨ the catch is that this entity needs impairment info and non-impairment RWA info. it can work with black links too, but then the authority that controls those black links has to be the one providing it 🖤
- IV-Candidates + RWA process 🦋 this one splits the impairment info across two computation entities and still keeps a high degree of potential optimality and efficiency in IA-RWA 🌸 the IV-Candidates process needs impairment info from all optical network elements, while the RWA process needs non-impairment RWA info from the network elements. black links work here too, but the authority in control of them would need to provide the functionality of the IV-Candidates process. and honestly this is still super useful, because the algorithmic areas of IV and RWA are very different and love being specialized 🧚
- Routing + Distributed WA and IV 🌈 in this one, a signaling protocol may be extended and leveraged in the wavelength assignment and impairment validation processes. it doesn't hit as high a potential degree of optimality as (a) or (b), but it doesn't need distribution of either link wavelength usage or link/node impairment information, which is a major plus 💜 just note that this is most likely not suitable for black links 🙈
+-----------------------------------+ +------------+
| +-----------+ +-------+ +--+ | | +--------+ |
| | IV | |Routing| |WA| | | | IV | |
| |Approximate| +-------+ +--+ |---->| |Detailed| |
| +-----------+ | | +--------+ |
| Combined Processes | | |
+-----------------------------------+ +------------+
(a)
+--------------+ +----------------------+ +------------+
| +----------+ | | +-------+ +--+ | | +--------+ |
| | IV | | | |Routing| |WA| |---->| | IV | |
| |Candidates| |----->| +-------+ +--+ | | |Detailed| |
| +----------+ | | Combined Processes | | +--------+ |
+--------------+ +----------------------+ | |
(b) +------------+
Figure 3. Process Flows for the Two Main Detailed Impairment
Validation Architectural Optionsand for the detailed validation options, here's the tea ☕
- Combined Approximate IV & RWA + Detailed-IV 💅 this combines RWA and approximate IV inside a single computation entity, which gives the highest potential optimality and efficiency in IA-RWA, while a separate entity handles the detailed impairment validation 🎀 with black links, the authority controlling them would need to provide all of the functionality.
- IV-Candidates + RWA + Detailed-IV 🫧 this one separates approximate impairment information into its own computation entity and still keeps a high degree of potential optimality and efficiency in IA-RWA. then a separate computation entity does the detailed impairment validation 💜 quick heads up that detailed impairment estimation is not standardized yet 👀
5. Protocol Implications 🔌
okay the previous IA-RWA architectures and process flows put different demands on a GMPLS/PCE-based control plane 🧠 this section talks through (a) an impairment information model, (b) the PCE as a computation entity taking on the various process roles and what that means for PCEP, (c) possible extensions to signaling, and (d) possible extensions to routing. this document is giving you this evaluation to help out with protocol solutions work 🌷 the protocol specifications may deviate from this assessment. the impacts on the control plane for IA-RWA are summed up in Figure 4 💖
+--------------------+-----+-----+------------+---------+
| IA-RWA Option | PCE | Sig | Info Model | Routing |
+--------------------+-----+-----+------------+---------+
| Combined | Yes | No | Yes | Yes |
| IV & RWA | | | | |
+--------------------+-----+-----+------------+---------+
| IV-Candidates | Yes | No | Yes | Yes |
| + RWA | | | | |
+--------------------+-----+-----+------------+---------+
| Routing + | No | Yes | Yes | No |
|Distributed IV, RWA | | | | |
+--------------------+-----+-----+------------+---------+
Figure 4. IA-RWA Architectural Options and Control Plane Impacts5.1. Information Model for Impairments 🧩
okay so most IA-RWA scenarios lean on a common impairment information model, to a greater or lesser extent 🫶 a bunch of ITU-T Recommendations cover both detailed and approximate impairment characteristics of fibers, a variety of devices, and a variety of subsystems 📚 an impairment model you can use as a guideline for optical network elements and for checking path viability is given in [G.680] 🦋
ngl, there's a limitation here 🙈 the current version of [G.680] is limited to networks made of a single WDM line system vendor combined with OADMs and/or PXCs from potentially multiple other vendors. this is known as "situation 1" and is shown in Figure 1-1 of [G.680]. it's planned that [G.680] will eventually include networks with line systems from multiple vendors, as well as OADMs and/or PXCs from potentially multiple other vendors. this is known as "situation 2" and is shown in Figure 1-2 of [G.680] ✨
for distributed IV, an impairment information model alone is not enough 🚨 you'd also need a common impairment "computation" model. in the distributed IV case, the accumulated impairment measures that get conveyed and updated at each node need to be standardized. Section 9 of [G.680] gives guidance here, with specific formulas for OSNR, residual dispersion, polarization mode dispersion/polarization-dependent loss, and effects of channel uniformity. however, the specifics of which intermediate results are kept and in what form would still need to be standardized for interoperability. as noted in [G.680], this information may possibly not be sufficient, and in that case, the applicability would be network dependent 💀
5.2. Routing 🛣️
different approaches to path/wavelength impairment validation create different demands on GMPLS routing protocols 💅 in the case where approximate impairment information is used to validate paths, GMPLS routing may be used to distribute the impairment characteristics of the network elements and links, based on the impairment information model we just talked about 🌸
depending on the computational alternative, the routing protocol may need to advertise the information that the impairment validation process needs. this can potentially cause scalability issues, because of the high volume of data that needs to be advertised 😭 these issues can be handled by separating data that only needs to be advertised rarely from data that needs to be advertised more frequently, or by adopting other forms of awareness solutions as described in previous sections (e.g., a centralized and/or external IV entity) 🧚
in terms of scenario C in Section 4.1.1, the model defined by [G.680] will apply, and the routing protocol will need to gather the information required for those computations 🔥
and in the case of distributed IV, no new demands would be placed on the routing protocol 🎀
5.3. Signaling 📡
the biggest impacts on signaling happen when distributed impairment validation is performed 💖 in this case, impairment information needs to be accumulated, as we covered before. plus, since the characteristics of the signal itself, like modulation type, can play a major role in how well it tolerates impairments, this type of information will need to be signaled, either implicitly or explicitly, so an impairment validation decision can be made at the destination node 👑
it remains for further study whether it might be beneficial to include additional information in a connection request, such as desired egress signal quality (defined in some appropriate sense), in non-distributed IV scenarios 🔍
5.4. PCE 🧠
in Section 4.2, we went through a bunch of computational architectural alternatives that could meet the various requirements and constraints of Section 4.1 🌈 this part is all about how those alternatives could be implemented via either a single PCE or a set of two or more cooperating PCEs, and what the impacts on PCEP would be 🫶 this document provides this evaluation to help solutions work, and the protocol specifications may deviate from this assessment 💜
5.4.1. Combined IV & RWA ✨
Okay so in this setup (Figure 2(a)), one single PCE does all the computations for IA-RWA. Main character energy 👑
- Traffic Engineering (TE) Database requirements: WSON topology and switching capabilities, WSON WDM link wavelength utilization, and WSON impairment information.
- PCC to PCE Request Information: Signal characteristics/type, required quality, source node, and destination node.
- PCE to PCC Reply Information: If the computations finish successfully, the PCE sends back the path and its assigned wavelength 🌈. If they can't finish successfully, it would be potentially useful to know why. At a minimum, it's of interest to know if that was because of lack of wavelength availability, impairment considerations, or both. The info to be conveyed is for further study 🧐.
5.4.2. IV-Candidates + RWA 💅
In this situation (Figure 2(b)), there are two separate processes in the IA-RWA computation, which is giving teamwork 🫶. That means two cooperating path computation entities: one for the IV-Candidates process and another for the RWA process. On top of that, the overall process needs to be coordinated. This could be done with yet another PCE, or the functionality could be added to one of a number of previously defined entities. The later option requires that the RWA entity also act as the overall process coordinator. Here are the roles, responsibilities, and information requirements for these two entities, when they're instantiated as PCEs ✨.
RWA and Coordinator PCE (RWA-Coord PCE):
The RWA-Coord PCE is responsible for talking to the PCC and for using the IV-Candidates PCE as needed during RWA computations. Specifically, it needs to know that it's supposed to use the IV-Candidates PCE to get a potential set of routes and wavelengths 🦋.
- TE Database requirements: WSON topology and switching capabilities, and WSON WDM link wavelength utilization (no impairment information).
- PCC to RWA PCE request: Same as in the combined case.
- RWA PCE to PCC reply: Same as in the combined case.
- RWA PCE to IV-Candidates PCE request: The RWA PCE asks for a set of at most K routes, along with acceptable wavelengths between the nodes specified in the original PCC request.
- IV-Candidates PCE reply to RWA PCE: The IV-Candidates PCE returns a set of at most K routes, along with acceptable wavelengths between the nodes specified in the RWA PCE request.
IV-Candidates PCE:
The IV-Candidates PCE is responsible for impairment-aware path computation. It doesn't need to take current link wavelength utilization into account, but that's not prohibited 🙈. The IV-Candidates PCE is only required to interact with the RWA PCE as described above, not with the initiating PCC. Note: The RWA-Coord PCE is also a PCC with respect to the IV-Candidate 🔥.
- TE Database requirements: WSON topology and switching capabilities, and WSON impairment information (no link wavelength utilization information required).
Figure 5 shows a sequence diagram for the possible interactions between the PCC, RWA-Coord PCE, and IV-Candidates PCE 🍓.
+---+ +-------------+ +-----------------+
|PCC| |RWA-Coord PCE| |IV-Candidates PCE|
+-+-+ +------+------+ +---------+-------+
...___ (a) | |
| ````---...____ | |
| ```-->| |
| | |
| |--..___ (b) |
| | ```---...___ |
| | ```---->|
| | |
| | |
| | (c) ___...|
| | ___....---'''' |
| |<--'''' |
| | |
| | |
| (d) ___...| |
| ___....---''' | |
|<--''' | |
| | |
| | |
Figure 5. Sequence Diagram for the Interactions between the PCC,
RWA-Coord PCE, and IV-Candidates PCEIn step (a), the PCC asks for a path that meets specified quality constraints between two nodes (A and Z) for a given signal, which is represented either by a specific type or a general class with associated parameters 💖. In step (b), the RWA-Coord PCE requests up to K candidate paths between nodes A and Z, plus associated acceptable wavelengths. The term "K candidate paths" is tied to the k shortest path algorithm. That's an algorithm that finds multiple k short paths connecting the source and the destination in a graph that allows repeated vertices and edges in the paths. See details in [Eppstein].
In step (c), the IV-Candidates PCE sends this list back to the RWA-Coord PCE, which then uses this set of paths and wavelengths as input (e.g., a constraint) to its RWA computation. In step (d), the RWA-Coord PCE returns the overall IA-RWA computation results to the PCC 🎀.
5.4.3. Approximate IA-RWA + Separate Detailed-IV 🧚
Earlier, Figure 3 showed two cases where a separate detailed impairment validation process could be used. It's possible to place the detailed validation process into a separate PCE 💜. Assuming a different PCE takes on the coordinating role and interacts with the PCC, the interactions with this separate IV-Detailed PCE can stay super simple. Heads up though: from a message flow perspective, there's some inefficiency because the IV-Candidates PCE is separated from the IV-Detailed PCE, all in the name of reaching a high degree of potential optimality 😭.
IV-Detailed PCE:
- TE Database requirements: The IV-Detailed PCE will need optical impairment information, WSON topology, and possibly WDM link wavelength usage information. This document puts no restrictions on the type of information that may be used in these computations ✨.
- RWA-Coord PCE to IV-Detailed PCE request: The RWA-Coord PCE will furnish signal characteristics, quality requirements, path, and wavelength to the IV-Detailed PCE.
- IV-Detailed PCE to RWA-Coord PCE reply: The reply is essentially a yes/no decision as to whether the requirements could actually be met. If the impairment validation fails, it would be helpful to convey information about the cause or to quantify the failure, e.g., so a judgment can be made about whether to try a different signal or adjust signal parameters 🤔.
Figure 6 shows a sequence diagram for the interactions corresponding to the process shown in Figure 3(b). This involves interactions between the PCC, RWA PCE (acting as coordinator), IV-Candidates PCE, and IV-Detailed PCE 🌸.
In step (a), the PCC asks for a path that meets specified quality constraints between two nodes (A and Z) for a given signal, represented either by a specific type or a general class with associated parameters. In step (b), the RWA-Coord PCE requests up to K candidate paths between nodes A and Z, plus associated acceptable wavelengths. In step (c), the IV-Candidates PCE sends this list back to the RWA-Coord PCE, which then uses this set of paths and wavelengths as input (e.g., a constraint) to its RWA computation. In step (d), the RWA-Coord PCE requests a detailed verification of the path and wavelength it has computed. In step (e), the IV-Detailed PCE returns the results of the validation to the RWA-Coord PCE. Finally, in step (f), the RWA-Coord PCE returns the final results (either a path and wavelength, or a cause for the failure to compute a path and wavelength) to the PCC 🦋.
+----------+ +--------------+ +------------+
+---+ |RWA-Coord | |IV-Candidates | |IV-Detailed |
|PCC| | PCE | | PCE | | PCE |
+-+-+ +----+-----+ +------+-------+ +-----+------+
|.._ (a) | | |
| ``--.__ | | |
| `-->| | |
| | (b) | |
| |--....____ | |
| | ````---.>| |
| | | |
| | (c) __..-| |
| | __..---'' | |
| |<--'' | |
| | |
| |...._____ (d) |
| | `````-----....._____ |
| | `````----->|
| | |
| | (e) _____.....+
| | _____.....-----''''' |
| |<----''''' |
| (f) __.| |
| __.--'' |
|<-'' |
| |Figure 6. Sequence Diagram for the Interactions between the PCC, RWA-Coord PCE, IV-Candidates PCE, and IV-Detailed PCE
6. Manageability and Operations ✨
okay so bestie, this section is literally the "we'll deal with it later" section 💅 The management and operations stuff is out of scope for this doc. Those details get pushed to future protocol implementations 🧚
Still, there are some vibes worth noting. 🦋
On a high level, the GMPLS-routing-based architecture from Section 5.2 might have to figure out how to handle potential scaling issues, because it has to spread around a LOT of impairment characteristics for the network elements and links 📡
From a scaling point of view, the GMPLS-signaling-based architecture from Section 5.3 would be more scalable than the other options 🔥 It avoids flooding the network with a huge amount of data. The tradeoff is that it may lead to inefficient use of network resources 🥲
The PCE-based architectures from Section 5.4 need to think about operational complexity when they use multiple PCE servers 🎀 The most serious case is the option in Section 5.4.3 ("Approximate IA-RWA + Separate Detailed-IV") 😭
The combined IV & RWA option (from Section 5.4.1) is actually the simplest to operate, since one PCE server handles everything 💖 The catch is that it may have a heavy computation and processing burden compared to the other options 💀
Interoperability could be a hurdle when everyone tries to agree on some impairment parameters, especially the ones tied to the black links 🌈 ITU-T has been working on this and it needs more time to mature ⭐
7. Security Considerations 🔐
okay this part is SERIOUS bestie, so pay attention 🫶
This doc talks about a bunch of control plane architectures that use knowledge of impairments in optical networks. If one of these gets put into use inside a network, it will, by its nature, contain details about the physical characteristics of that optical network 👀 That info needs protecting from intentional or unintentional disclosure, kind of like other network info used within intra-domain protocols 🔒
This document does NOT require changes to the security models in GMPLS and the related protocols 🙌 The OSPF-TE, RSVP-TE, and PCEP security models could all keep running unchanged. BUT (and this is a big but 😤) meeting the requirements for impairment information dissemination with the existing protocols may seriously load those protocols. It may also make the network more vulnerable to active attacks like injections, impersonation, and man-in-the-middle attacks 🚨 So extra care may be needed to make sure the protocols stay secure in the impairment-aware WSON environment 🛡️
Also, the extra info distributed to handle impairments is basically a disclosure of network capabilities that an operator might want to keep private 🙈 It's worth thinking about how to secure it 💜
For a general discussion of MPLS and GMPLS security issues, check out the MPLS/GMPLS security framework [RFC5920] 📚 Especially the part about what happens when the control plane is physically separated from the data plane 🧠
8. References 📖
8.1. Normative References 💜
[G.680] ITU-T Recommendation G.680, "Physical transfer functions
of optical network elements", July 2007.
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
August 2006.8.2. Informative References 🦋
[Eppstein] Eppstein, D., "Finding the k shortest paths", 35th IEEE
Symposium on Foundations of Computer Science, Santa Fe,
pp. 154-165, 1994.
[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.Sup39] ITU-T Series G Supplement 39, "Optical system design and
engineering considerations", February 2006.
[RFC4054] Strand, J., Ed., and A. Chiu, Ed., "Impairments and Other
Constraints on Optical Layer Routing", RFC 4054,
May 2005.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
[RFC6163] Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku,
"Framework for GMPLS and Path Computation Element (PCE)
Control of Wavelength Switched Optical Networks (WSONs)",
RFC 6163, April 2011.9. Contributors 🎀
okay the squad! these are the people who helped make this doc happen 🥰
Ming Chen
Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129
P.R. China
Phone: +86-755-28973237
EMail: mchen@huawei.com
Rebecca Han
Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129
P.R.China
Phone: +86-755-28973237
EMail: hanjianrui@huawei.com
Gabriele Galimberti
Cisco
Via Philips 12
20052 Monza
Italy
Phone: +39 039 2091462
EMail: ggalimbe@cisco.com
Alberto Tanzi
Cisco
Via Philips 12
20052 Monza
Italy
Phone: +39 039 2091469
EMail: altanzi@cisco.com
David Bianchi
Cisco
Via Philips 12
20052 Monza
Italy
EMail: davbianc@cisco.com
Moustafa Kattan
Cisco
Dubai 500321
United Arab Emirates
EMail: mkattan@cisco.com
Dirk Schroetter
Cisco
EMail: dschroet@cisco.com
Daniele Ceccarelli
Ericsson
Via A. Negrone 1/A
Genova - Sestri Ponente
Italy
EMail: daniele.ceccarelli@ericsson.com
Elisa Bellagamba
Ericsson
Farogatan 6
Kista 164 40
Sweden
EMail: elisa.bellagamba@ericsson.com
Diego Caviglia
Ericsson
Via A. Negrone 1/A
Genova - Sestri Ponente
Italy
EMail: diego.caviglia@ericsson.comAuthors' Addresses 💌
Young Lee (editor)
Huawei Technologies
5340 Legacy Drive, Building 3
Plano, TX 75024
USA
Phone: (469) 277-5838
EMail: leeyoung@huawei.com
Greg M. Bernstein (editor)
Grotto Networking
Fremont, CA
USA
Phone: (510) 573-2237
EMail: gregb@grotto-networking.com
Dan Li
Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129
P.R. China
Phone: +86-755-28973237
EMail: danli@huawei.com
Giovanni Martinelli
Cisco
Via Philips 12
20052 Monza
Italy
Phone: +39 039 2092044
EMail: giomarti@cisco.com📦 where this page comes from
- ietf: rfc6566 2012-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms