RFC 7446
Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks
RFC 7446: Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks ✨
Authors: Y. Lee (Ed.) from Huawei, G. Bernstein (Ed.) from Grotto Networking, D. Li from Huawei, and W. Imajuku from NTT. 🧚
Category: Informational. It's published for information, not as a standards-track spec 💅
Date: February 2015 📅
ISSN: 2070-1721
Obsoletes/Updates: The header doesn't list any RFCs that this one obsoletes or updates, so it's standing on its own 🫶
Abstract 🌈
okay so this doc gives you a model of the info that the Routing and Wavelength Assignment (RWA) process needs in Wavelength Switched Optical Networks (WSONs) 🦋 The whole point is to make constrained optical path computation easier. It takes compatibility constraints between WSON signal attributes and network elements into account, but it does not cover optical impairments. There's also a bit about which parts could be useful for other techs that use a GMPLS control plane ✨
Status of This Memo 📝
This document is not an Internet Standards Track specification. It's published for informational purposes, so no pressure 🎀
It's a product of the Internet Engineering Task Force (IETF) and it 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 doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 🙈
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7446 🔥
Copyright Notice 💜
Copyright (c) 2015 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) as in effect on the date this document was published. 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 ....................................................3
2. Terminology .....................................................3
3. Routing and Wavelength Assignment Information Model .............3
3.1. Dynamic and Relatively Static Information ..................4
4. Node Information (General) ......................................4
4.1. Connectivity Matrix ........................................5
5. Node Information (WSON Specific) ................................5
5.1. Resource Accessibility/Availability ........................7
5.2. Resource Signal Constraints and Processing Capabilities ...11
5.3. Compatibility and Capability Details ......................12
5.3.1. Shared Input or Output Indication ..................12
5.3.2. Optical Interface Class List .......................12
5.3.3. Acceptable Client Signal List ......................13
5.3.4. Processing Capability List .........................13
6. Link Information (General) .....................................13
6.1. Administrative Group ......................................14
6.2. Interface Switching Capability Descriptor .................14
6.3. Link Protection Type (for This Link) ......................14
6.4. Shared Risk Link Group Information ........................14
6.5. Traffic Engineering Metric ................................15
6.6. Port Label Restrictions ...................................15
6.6.1. Port-Wavelength Exclusivity Example ................17
7. Dynamic Components of the Information Model ....................18
7.1. Dynamic Link Information (General) ........................19
7.2. Dynamic Node Information (WSON Specific) ..................19
8. Security Considerations ........................................19
9. References .....................................................20
9.1. Normative References ......................................20
9.2. Informative References ....................................21
Contributors ......................................................22
Authors' Addresses ................................................231. Introduction 🌸
okay so the WSON information model in this doc is all about making constrained optical path computation work. That makes it NOT a general-purpose network management model, bestie 🙅♀️ This constraint is often called the "wavelength continuity" constraint, and the path computation built around it is known as the Routing and Wavelength Assignment (RWA) problem. So the model has to give enough topology, wavelength restriction, and availability info to support that computation. You can find more on the RWA process and WSON subsystems in [RFC6163]. The model here covers constraints between WSON signal attributes and network elements, but it doesn't cover optical impairments 🦋
The model is useful beyond WSON too, so the doc also points out the parts with general applicability to other technologies that use a GMPLS control plane. Those parts are called "general," and they're different from the "WSON-specific" parts that only apply to WSON tech ✨
2. Terminology 💅
For definitions of Reconfigurable Optical Add/Drop Multiplexer (ROADM), RWA, Wavelength Conversion, Wavelength Division Multiplexing (WDM), WSON, and other related terms, see [RFC6163]. Those are the terms this doc uses 🎀
3. Routing and Wavelength Assignment Information Model 🧚
The WSON RWA information model in this doc has four categories of information. These categories don't care whether the info comes from a switching subsystem or a line subsystem. A switching subsystem means WSON nodes like a ROADM or an Optical Add/Drop Multiplexer (OADM). A line subsystem means devices like a WDM or an Optical Amplifier. The four categories are:
- Node Information
- Link Information
- Dynamic Node Information
- Dynamic Link Information
Note that this is roughly the categorization used in Section 7 of [G.7715] 🫶
Below, where it applies, the doc uses the Reduced Backus-Naur Form (RBNF) syntax from [RBNF] to help define the RWA information model 🌈
3.1. Dynamic and Relatively Static Information 🦋
Literally all the RWA info in a WSON network can change over time. Equipment gets upgraded, links get put in or out of service, and so on. Still, from the RWA computation's point of view, there's a difference between info that can change with every new connection setup in the network and info that's relatively static and doesn't depend on connection establishment. A key example of the first kind is link wavelength usage, since it changes with connection setup and teardown, and it's a key input to the RWA process. Examples of the relatively static kind are the potential port connectivity of a WDM ROADM and the channel spacing on a WDM link 💜
Where possible, this doc separates dynamic and static info, so the two can be kept apart in whatever encodings are used. That lets each type be updated on its own, which cuts down the processing and traffic load from distributing the more dynamic RWA WSON info in a timely way ✨
4. Node Information (General) 🍓
The node info here is the relatively static info about a WSON node. It includes connectivity constraints between ports and wavelengths, because WSON switches can have asymmetric switching properties. More info could cover wavelength converters in the node, if the node has any 💖 In [Switch], it was shown that the wavelength connectivity constraints for a large class of practical WSON devices can be modeled with switched and fixed connectivity matrices, along with matching switched and fixed port constraints. These connectivity matrices go with the node info, and the switched and fixed port wavelength constraints go with the link info 🔥
Formally:
<Node_Information> ::= <Node_ID> [<ConnectivityMatrix>...]Here, Node_ID is an appropriate identifier for the node within the WSON RWA context.
Multiple connectivity matrices are allowed, so the most general cases listed in [Switch] are fully supported 👑
4.1. Connectivity Matrix 💅
The connectivity matrix (ConnectivityMatrix) represents either the potential connectivity matrix for an asymmetric switch (like ROADMs and such) or the fixed connectivity for an asymmetric device like a multiplexer. Note that this matrix doesn't represent any particular internal blocking behavior. It just shows which input ports and wavelengths could possibly connect to a particular output port. For a switch or ROADM, blocking that depends on internal state is out of scope for this doc. Because it's so implementation-dependent, it's most likely never going to be standardized 🙈 The connectivity matrix is a conceptual M by N matrix that represents the potential switched or fixed connectivity, where M is the number of input ports and N is the number of output ports. It's "conceptual" because the matrix tends to have structure that allows for very compact representations, which are useful for both transmission and path computation 🦋
Note that the connectivity matrix info element can be useful in any technology context where asymmetric switches are used ✨
<ConnectivityMatrix> ::= <MatrixID>
<ConnType>
<Matrix>Here's what each part is:
<MatrixID>is a unique identifier for the matrix.<ConnType>is either 0 or 1, depending on whether the connectivity is fixed or switched.<Matrix>represents the fixed or switched connectivity, where Matrix(i, j) = 0 or 1 depending on whether input port i can connect to output port j for one or more wavelengths 🎀
5. Node Information (WSON Specific) ✨
okay so, as [RFC6163] talks about, a WSON node can have electro-optical subsystems inside it 🔧⚡ like regenerators, wavelength converters, or even whole switching subsystems. The model here helps describe how accessible and available limited resources (like regenerators or wavelength converters) are, plus the WSON signal attribute constraints on those electro-optical subsystems. It's kinda specific to WSON tech, so it's giving "only for this crowd" energy 💜
Quick vocab check 🎀: in this doc, "resource" means a physical part of a WSON node, like a regenerator or a wavelength converter. There are usually lots of these inside one node. Don't mix it up with forwarding or switching resources like bandwidth or lambdas, bestie 🙈
A WSON node may have regenerators or wavelength converters sitting in a shared pool. Also, per [RFC6163], a WSON node can include WDM switches that do optical-electronic-optical (OEO) processing 🌈 There are lots of different ways people design WDM switches with regenerator or converter pools. Still, from the path computation point of view, these three things need to be known:
- The nodes that support regeneration or 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.
Resources usually come bundled together in blocks of similar devices, like on line cards or other modules 📦 So the basic identifiable unit of resource in this doc is the "resource block" 🧚
A resource block is a group of resources from the same WSON node that get grouped together for administrative reasons and to make encoding in the protocols easier 💅 Everything in the same resource block acts the same way and has similar characteristics that matter to the optical system, like processing properties, accessibility, etc.
A resource pool is a collection of resource blocks used to represent throughput or cross-connect capabilities in a WSON node ✨ It links input ports or links on the node with output ports or links, and shows how signals can get from an input port or link to an output port or link through a resource block (aka through a resource) 🦋 That means a resource pool can be modeled as a matrix, lowkey iconic.
A resource block can show up in more than one resource pool 🌸
So here's the formal high-level model, periodt:
<Node_Information> ::= <Node_ID>
[<ConnectivityMatrix>...]
[<ResourcePool>]
Where
<ResourcePool> ::= <ResourceBlockInfo>...
[<ResourceAccessibility>...]
[<ResourceWaveConstraints>...]
[<RBPoolState>]First we're gonna look at how resource blocks are accessed, and then we'll talk about their properties 👑
5.1. Resource Accessibility/Availability 💖
Okay this one's giving déjà vu 🙈 A similar technique to what's used for modeling ROADMs and optical switches can also model regenerator/converter accessibility. [RFC6163] discussed this in general, and it uses a matrix to show possible connectivity along with wavelength constraints for links/ports. Since regenerators or wavelength converters can be seen as a scarce resource, it's desirable for the model to include, if wanted, the usage state (availability) of individual regenerators or converters in the pool 🥺 Models that add more state to show blocking conditions on input or output to particular converters are for further study and aren't included here, so don't look for them yet 💀
The three-stage model is shown in Figures 1 and 2. The difference between the two is that in Figure 1, it's assumed that each signal that can reach a resource block may do so, while in Figure 2, access to sets of resource blocks happens over a shared fiber that adds its own wavelength collision constraint 🌈 Figure 1 shows there can be more than one input to each resource block, since each input represents a single wavelength signal. Figure 2 shows a single WDM input or output (like a fiber) going to or from each set of blocks.
This model assumes N input ports (fibers), P resource blocks containing one or more identical resources (e.g., wavelength converters), and M output ports (fibers) 🧃 Since not every input port can necessarily reach each resource block, the model starts with a resource pool input matrix RI(i,p) = {0,1}, which depends on whether input port i can potentially reach resource block p.
Since not every wavelength can necessarily reach all the resources, or the resources might have a limited input wavelength range, the model has a set of relatively static input port constraints for each resource ✨ Also, if access to a set of resource blocks goes through a shared fiber (Figure 2), that would impose a dynamic wavelength availability constraint on that shared fiber. The resource block input port constraint is modeled with a static wavelength set mechanism, and the case of shared access to a set of blocks is modeled with a dynamic wavelength set mechanism 🦋
Next, a state vector RA(j) = {0,...,k} tracks the number of resources in resource block j that are in use. This is the only state kept in the resource pool model 🫶 This state isn't necessary for modeling "fixed" transponder systems or full OEO switches with WDM interfaces, meaning systems where there's no sharing.
After that, a set of static resource output wavelength constraints and possibly dynamic shared output fiber constraints maybe used. The static constraints show which wavelengths a particular resource block can generate or is restricted to generating. For example, a fixed regenerator would be limited to a single lambda 🍓 The dynamic constraints would be used when a single shared fiber is used to output the resource block (Figure 2).
Finally, to complete the model, a resource pool output matrix RE(p,k) = {0,1} may be used, depending on whether the output from resource block p can reach output port k 👑
I1 +-------------+ +-------------+ O1
----->| | +--------+ | |----->
I2 | +------+ Rb #1 +-------+ | O2
----->| | +--------+ | |----->
| | | |
| Resource | +--------+ | Resource |
| Pool +------+ +-------+ Pool |
| | + Rb #2 + | |
| Input +------+ +-------| Output |
| Connection | +--------+ | Connection |
| Matrix | . | Matrix |
| | . | |
| | . | |
IN | | +--------+ | | OM
----->| +------+ Rb #P +-------+ |----->
| | +--------+ | |
+-------------+ ^ ^ +-------------+
| |
| |
| |
| |
Input wavelength Output wavelength
constraints for constraints for
each resource each resource
Note: Rb is a resource block.
Figure 1: Schematic Diagram of the Resource Pool Model I1 +-------------+ +-------------+ O1
----->| | +--------+ | |----->
I2 | +======+ Rb #1 +-+ | | O2
----->| | +--------+ | | |----->
| | |=====| |
| Resource | +--------+ | | Resource |
| Pool | +-+ Rb #2 +-+ | Pool |
| | | +--------+ | |
| Input |====| | Output |
| Connection | | +--------+ | Connection |
| Matrix | +-| Rb #3 |=======| Matrix |
| | +--------+ | |
| | . | |
| | . | |
| | . | |
IN | | +--------+ | | OM
----->| +======+ Rb #P +=======+ |----->
| | +--------+ | |
+-------------+ ^ ^ +-------------+
| |
| |
| |
Single (shared) fibers for block input and output
Input wavelength Output wavelength
availability for availability for
each block input fiber each block output fiber
Note: Rb is a resource block.
Figure 2: Schematic Diagram of the Resource Pool Model with
Shared Block AccessibilityFormally, the model can be specified as:
<ResourceAccessibility> ::= <PoolInputMatrix>
<PoolOutputMatrix>
<ResourceWaveConstraints> ::= <InputWaveConstraints>
<OutputWaveConstraints>
<RBSharedAccessWaveAvailability> ::= [<InAvailableWavelengths>]
[<OutAvailableWavelengths>]
<RBPoolState> ::= <ResourceBlockID>
<NumResourcesInUse>
[<RBSharedAccessWaveAvailability>]
[<RBPoolState>]Note that, except for <RBPoolState>, all the components of <ResourcePool> are relatively static 🫧 Also, <InAvailableWavelengths> and <OutAvailableWavelengths> are only used when there's shared input or output access to the particular block. See the resource block information in the next section for how this gets specified ✨
5.2. Resource Signal Constraints and Processing Capabilities 💅
okay so the wavelength conversion abilities of a resource (think regenerator or wavelength converter) were already modeled in the <OutputWaveConstraints> we talked about earlier. As [RFC6163] explains, you can model the constraints on an electro-optical resource using three pieces: input constraints, processing capabilities, and output constraints ✨
<ResourceBlockInfo> ::= <ResourceBlockSet>
[<InputConstraints>]
[<ProcessingCapabilities>]
[<OutputConstraints>]<ResourceBlockSet> is a list of resource block identifiers that all share the same characteristics 🎀. If that set is missing, the constraints get applied to the entire network element, so no skipping this part bestie 🫶
<InputConstraints> are all about signal compatibility and/or the shared access constraint indication. The juicy details are in Section 5.3 🔥
<InputConstraints> ::= <SharedInput>
[<OpticalInterfaceClassList>]
[<ClientSignalList>]<ProcessingCapabilities> are the important operations that the resource (or network element) can perform on the signal. Again, the details live in Section 5.3 🧚
<ProcessingCapabilities> ::= [<NumResources>]
[<RegenerationCapabilities>]
[<FaultPerfMon>]
[<VendorSpecific>]<OutputConstraints> are either restrictions on the properties of the signal leaving the block, options about the signal properties when it leaves the resource, or the shared fiber output constraint indication 🌸
<OutputConstraints> := <SharedOutput>
[<OpticalInterfaceClassList>]
[<ClientSignalList>]5.3. Compatibility and Capability Details 🦋
5.3.1. Shared Input or Output Indication
as Section 5.2 and Figure 2 show, input or output access to a resource block may happen over a shared fiber 🍓. <SharedInput> and <SharedOutput> are the indicators for this condition, described from the point of view of the block being described.
5.3.2. Optical Interface Class List
<OpticalInterfaceClassList> ::= <OpticalInterfaceClass> ...An Optical Interface Class is a unique number that identifies all the information about the optical characteristics of a physical interface 💜. A class can carry other optical parameters for other interface properties too, but it always includes signal compatibility information ✨
The content of each class is out of scope for this document. Other folks like the ITU or optical equipment vendors can define it 🌈
Even current physical interfaces may support different optical characteristics, so a single interface can support multiple interface classes 🙈. Which optical interface class gets used out of all the ones available on an interface is also out of scope here, and it's actually an output of the RWA process 👑
5.3.3. Acceptable Client Signal List
The list is simply:
<ClientSignalList>::=[<G-PID>]...where the Generalized Protocol Identifiers (G-PID) object represents one of the IETF-standardized G-PID values defined in [RFC3471] and [RFC4328] 💅
5.3.4. Processing Capability List
The ProcessingCapabilities are defined in Section 5.2 🫶
The processing capability list sub-TLV is a list of processing functions that the WSON network element (NE) can perform on the signal. That includes:
- number of resources within the block
- regeneration capability
- fault and performance monitoring
- vendor-specific capability
Note that the code points for fault and performance monitoring and vendor-specific capability are still subject to further study 🥺
6. Link Information (General) 🌈
MPLS-TE routing protocol extensions for OSPF [RFC3630] and IS-IS [RFC5305], along with GMPLS routing protocol extensions for OSPF [RFC4203] and IS-IS [RFC5307], provide the bulk of the relatively static link information the RWA process needs 🎀. WSONs bring in extra link-related constraints though 😭. These come from characterizing WDM line systems, restricting laser transmitter tuning, and switching subsystem port wavelength constraints, like "colored" ROADM drop ports 🔥
The syntax below summarizes both the information from existing GMPLS routing protocols and the new information the RWA process may need ✨
<LinkInfo> ::= <LinkID>
[<AdministrativeGroup>]
[<InterfaceCapDesc>]
[<Protection>]
[<SRLG>...]
[<TrafficEngineeringMetric>]
[<PortLabelRestriction>...]Note that these extra link characteristics only apply to line-side ports of a WDM system, or to add/drop ports that belong to the resource pool (like a regenerator or wavelength converter pool) 💖. Advertising input/output tributary ports is not intended here, so skip those 🙅
6.1. Administrative Group
Administrative Group is defined in [RFC3630] and extended for MPLS-TE in [RFC7308] 🍓. Each set bit corresponds to one administrative group assigned to the interface. A link can belong to multiple groups. This is a configured quantity and can be used to influence routing decisions 💜
6.2. Interface Switching Capability Descriptor
InterfaceSwCapDesc is defined in [RFC4202]. It lets you know the different switching capabilities on this GMPLS interface 🦋. In both [RFC4203] and [RFC5307], this info gets combined with the maximum Link State Protocol Data Unit (LSP) bandwidth that can be used on this link at eight different priority levels 🔥
6.3. Link Protection Type (for This Link)
Protection is defined in [RFC4202] and implemented in [RFC4203] and [RFC5307]. It's used to indicate what protection, if any, is guarding this link 🛡️✨
6.4. Shared Risk Link Group Information
SRLG is defined in [RFC4202] and implemented in [RFC4203] and [RFC5307]. It lets you group links into shared risk groups, meaning links that are likely to fail at the same time for some reason 💀
6.5. Traffic Engineering Metric
TrafficEngineeringMetric is defined in [RFC3630] and [RFC5305] 🌸. It identifies a data-channel link metric value for traffic engineering that's separate from the metric used for path cost computation in the control plane.
Note that multiple "link metric values" could be useful in optical networks 👀. It would be more useful to the RWA process, though, to give them specific meanings, like a "link mile" metric or a "probability of failure" metric 💅
6.6. Port Label Restrictions
Port label restrictions could be applied generally to any label types in GMPLS by adding new kinds of restrictions. Wavelength is a type of label 🌈
Port label (wavelength) restrictions (PortLabelRestriction) model the label (wavelength) restrictions that the link and various optical devices, like Optical Cross-Connects (OXCs), ROADMs, and waveband multiplexers, may impose on a port 🧚. These restrictions tell you which wavelengths may or may not be used on a link, and they're relatively static. They play a big role in fully characterizing a WSON switching device [Switch] 👑. Port wavelength restrictions are specified relative to the port in general or to a specific connectivity matrix (Section 4.1). [Switch] has an example where both switch and fixed connectivity matrices are used and both types of constraints occur on the same port 🫶
<PortLabelRestriction> ::= <MatrixID>
<RestrictionType>
<Restriction parameters list>
<Restriction parameters list> ::=
<Simple label restriction parameters> |
<Channel count restriction parameters> |
<Label range restriction parameters> |
<Simple+channel restriction parameters> |
<Exclusive label restriction parameters>
<Simple label restriction parameters> ::= <LabelSet> ...
<Channel count restriction parameters> ::= <MaxNumChannels>
<Label range restriction parameters> ::= <MaxLabelRange>
(<LabelSet> ...)
<Simple+channel restriction parameters> ::= <MaxNumChannels>
(<LabelSet> ...)
<Exclusive label restriction parameters> ::= <LabelSet> ...Where:
MatrixIDis the ID of the corresponding connectivity matrix (Section 4.1) 🍓
The RestrictionType parameter is used to specify general port restrictions and matrix-specific restrictions. It can take these values and meanings 💖:
SIMPLE_LABEL: Simple label (wavelength) set restriction; theLabelSetparameter is required.CHANNEL_COUNT: The number of channels is restricted to be less than or equal to theMaxNumChannelsparameter (which is required).LABEL_RANGE: Used to indicate a restriction on a range of labels that can be switched. For example, a waveband device with a tunable center frequency and passband. This constraint is characterized by theMaxLabelRangeparameter, which indicates the maximum range of the labels, which may represent a waveband in terms of channels. Note that an additional parameter can be used to indicate the overall tuning range. Specific center frequency tuning info can be obtained from the dynamic channel in use. It's assumed that both center frequency and bandwidth (Q) tuning can be done without causing faults in existing signals 🌊SIMPLE LABEL and CHANNEL COUNT: In this case, the accompanying label set andMaxNumChannelsindicate the labels permitted on the port, and the maximum number of labels that can be used on the port at the same time 🧁LINK LABEL_EXCLUSIVITY: A label (wavelength) can be used at most once among a given set of ports. The set of ports is specified as a parameter to this constraint 🙅♀️
Restriction-specific parameters are used with one or more of the restriction types listed above. The currently defined parameters are 🎀:
LabelSetis a conceptual set of labels (wavelengths).MaxNumChannelsis the maximum number of channels that can be used at the same time (relative to either a port or a matrix).LinkSetis a conceptual set of ports.
MaxLabelRange indicates the maximum range of the labels. For example, if the port is a "colored" drop port of a ROADM, then there are two restrictions: (a) CHANNEL_COUNT, with MaxNumChannels = 1, and (b) SIMPLE_WAVELENGTH, with the wavelength set consisting of a single member that matches the frequency of the permitted wavelength 🌈. See [Switch] for a complete waveband example 🦋.
This information model for port wavelength (label) restrictions is pretty general. It can be applied to ports that have only label restrictions, or to ports that are part of an asymmetric switch and have label restrictions. Plus, the types of label restrictions that can be supported are extensible, so the model can grow with the tech 🚀✨
6.6.1. Port-Wavelength Exclusivity Example ✨
okay so there are lots of different ROADM or switch setups that can lead to the same constraint: a lambda (label) can only be used once across a set of ports 🌈 Figure 3 shows one built from Wavelength Selective Switches (WSSes) [OFC08] 🦋 It's made of splitters, combiners, and WSSes, and it has 11 output ports (numbered in the diagram) 💅 Output ports 1-8 are the drop ports, and each one is meant to support a single wavelength 🌸 Drop ports 1-4 come out of WSS 2, which gets fed from WSS 1 through one fiber 🧚 Because of that internal structure, ports 1-4 have a constraint: a lambda can only be used once over the whole group (assuming unicast and not multicast operation) 👑 Ports 5-8 have a similar constraint for the same reason 💜
| A
v 10 |
+-------+ +-------+
| Split | |WSS 6 |
+-------+ +-------+
+----+ | | | | | | | |
| W | | | | | | | | +-------+ +----+
| S |--------------+ | | | +-----+ | +----+ | | S |
9 | S |----------------|---|----|-------|------|----|---| p |
--| |----------------|---|----|-------|----+ | +---| l |<
| 5 |--------------+ | | | +-----+ | | +--| i |
+----+ | | | | | +------|-|-----|--| t |
+--------|-+ +----|-|---|------|----+ | +----+
+----+ | | | | | | | | |
| S |-----|--------|----------+ | | | | | | +----+
| p |-----|--------|------------|---|------|----|--|--| W |
->| l |-----|-----+ | +----------+ | | | +--|--| S |11
| i |---+ | | | | +------------|------|-------|--| S |->
| t | | | | | | | | | | +---|--| |
+----+ | | +---|--|-|-|------------|------|-|-|---+ | 7 |
| | | +--|-|-|--------+ | | | | | +----+
| | | | | | | | | | | |
+------+ +------+ +------+ +------+
| WSS 1| | Split| | WSS 3| | Split|
+--+---+ +--+---+ +--+---+ +--+---+
| A | A
v | v |
+-------+ +--+----+ +-------+ +--+----+
| WSS 2 | | Comb. | | WSS 4 | | Comb. |
+-------+ +-------+ +-------+ +-------+
1|2|3|4| A A A A 5|6|7|8| A A A A
v v v v | | | | v v v v | | | |
Figure 3: A ROADM Composed from Splitter, Combiners, and WSSes7. Dynamic Components of the Information Model ✨
okay so in the information model we just covered, only a small number of elements are dynamic, meaning they change as connections get set up and torn down 🦋 Depending on the protocol carrying this whole model, the dynamic bits might be sent separately from the much bigger chunk of static info needed to describe WSONs and their network elements 💖
7.1. Dynamic Link Information (General)
for WSON links, wavelength availability and which wavelengths are being used for shared backup can count as dynamic info 🌈 so they get grouped with the other dynamic stuff in this set:
<DynamicLinkInfo> ::= <LinkID>
<AvailableLabels>
[<SharedBackupLabels>]AvailableLabels is the set of labels (wavelengths) that are currently available on the link ✨ Knowing this plus the port wavelength restrictions means you can also figure out which wavelengths are currently in use 🫶 This parameter could potentially be used with other technologies that GMPLS currently covers or may cover in the future 🌸
SharedBackupLabels is the set of labels (wavelengths) currently used for shared backup protection on the link 💜 There's an example of how this shows up in a WSON setting over in [Shared] 🦋 This parameter could also potentially be used with other technologies that GMPLS currently covers or may cover in the future 🧚
Just so you know, the above doesn't dictate a specific encoding or placement for the available label info 💅 In some routing protocols it may be advantageous or required to put this info inside another information element, like the Interface Switching Capability Descriptor (ISCD) 👑 Check the extensions that are specific to each routing protocol for the details on where things go 🌟
7.2. Dynamic Node Information (WSON Specific)
right now, the only node info that can count as dynamic is the resource pool state 🍓 It can be pulled out into its own dynamic node information element like this:
<DynamicNodeInfo> ::= <NodeID> [<ResourcePool>]8. Security Considerations 💀
okay this part is SO important, bestie 😭 This document talks about an information model for RWA computation in WSONs 🔥 From a security standpoint, a model like this is really similar to the info that GMPLS routing protocols can already carry 🌸 That includes network topology, link state and current utilization, and the capabilities of switches and routers in the network ✨ So this information should be protected from disclosure to unintended recipients 🫶 On top of that, intentionally changing this info can seriously mess with network operations, especially because the optical infrastructure being controlled has such a huge capacity 🚨 A general discussion of security in GMPLS networks can be found in [RFC5920] 🔐
9. References 📚
9.1. Normative References
These are the sources the document depends on, so here they are, complete and unedited 💖
[G.7715] ITU-T, "Architecture and requirements for routing in the
automatically switched optical networks", ITU-T
Recommendation G.7715, June 2002.
[RBNF] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used
to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, April 2009,
<http://www.rfc-editor.org/info/rfc5511>.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003,
<http://www.rfc-editor.org/info/rfc3471>.
[RFC3630] van der Meer, J., Mackie, D., Swaminathan, V., Singer, D.,
and P. Gentric, "RTP Payload Format for Transport of MPEG-4
Elementary Streams", RFC 3640, November 2003,
<http://www.rfc-editor.org/info/rfc3640>.
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, October 2005,
<http://www.rfc-editor.org/info/rfc4202>.
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, October 2005,
<http://www.rfc-editor.org/info/rfc4203>.
[RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Extensions for G.709 Optical
Transport Networks Control", RFC 4328, January 2006,
<http://www.rfc-editor.org/info/rfc4328>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, October 2008,
<http://www.rfc-editor.org/info/rfc5305>.
[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 5307, October 2008,
<http://www.rfc-editor.org/info/rfc5307>.
[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,
<http://www.rfc-editor.org/info/rfc6163>.
[RFC7308] Osborne, E., "Extended Administrative Groups in MPLS
Traffic Engineering (MPLS-TE)", RFC 7308, July 2014,
<http://www.rfc-editor.org/info/rfc7308>.9.2. Informative References
these ones are just for extra context, not required reading 🌈
[OFC08] Roorda, P., and B. Collings, "Evolution to Colorless and
Directionless ROADM Architectures", Optical Fiber
Communication / National Fiber Optic Engineers Conference
(OFC/NFOEC), 2008, pp. 1-3.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010,
<http://www.rfc-editor.org/info/rfc5920>.
[Shared] Bernstein, G., and Y. Lee, "Shared Backup Mesh Protection
in PCE-based WSON Networks", iPOP 2008.
[Switch] Bernstein, G., Lee, Y., Gavler, A., and J. Martensson,
"Modeling WDM Wavelength Switching Systems for Use in GMPLS
and Automated Path Computation", Journal of Optical
Communications and Networking, vol. 1, June 2009, pp.
187-195.Contributors 🫶
these lovely people helped make this doc happen 💜
Diego Caviglia
Ericsson
Via A. Negrone 1/A 16153
Genoa, Italy
Phone: +39 010 600 3736
EMail: diego.caviglia@(marconi.com, ericsson.com)
Anders Gavler
Acreo AB
Electrum 236
SE - 164 40 Kista
Sweden
EMail: Anders.Gavler@acreo.se
Jonas Martensson
Acreo AB
Electrum 236
SE - 164 40 Kista
Sweden
EMail: Jonas.Martensson@acreo.se
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
Cyril Margaria
EMail: cyril.margaria@gmail.comAuthors' Addresses 🎀
and these are the editors and authors who wrote it 🌸
Young Lee (editor)
Huawei Technologies
5369 Legacy Drive, Building 3
Plano, TX 75023
United States
Phone: (469) 277-5838
EMail: leeyoung@huawei.com
Greg M. Bernstein (editor)
Grotto Networking
Fremont, CA
United States
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
China
Phone: +86-755-28973237
EMail: danli@huawei.com
Wataru Imajuku
NTT Network Innovation Labs
1-1 Hikari-no-oka, Yokosuka, Kanagawa
Japan
Phone: +81-(46) 859-4315
EMail: imajuku.wataru@lab.ntt.co.jp📦 where this page comes from
- ietf: rfc7446 2015-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms