RFC 7581
Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks
RFC 7581 💖 Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks
okay so this one is an Internet Standards Track doc from the IETF, published in June 2015 with ISSN 2070-1721 🎀. It's RFC 7581, and the authors are G. Bernstein (Ed., Grotto Networking), Y. Lee (Ed.), D. Li (Huawei), W. Imajuku (NTT), and J. Han (Huawei) ✨. The title block doesn't list any document that it obsoletes or updates, so there's nothing to chase 🌸.
Abstract 🦋
okay so a Wavelength Switched Optical Network (WSON) needs certain key info fields to be available, so that path computation and the setup of Label Switched Paths (LSPs) can actually happen 💅. The information model in RFC 7446 shows what info is needed at specific points in the WSON 🧚. Some of that model is generally useful for other technologies too, while other parts are WSON-only 💜.
This document gives efficient, protocol-agnostic encodings for the WSON-specific fields 🔥. Protocol-specific documents are expected to reference this memo to explain how the info gets carried for their particular uses ✨. These encodings can extend GMPLS signaling and routing protocols, and other mechanisms can use them to send this same info to a Path Computation Element (PCE) 🫶.
Status of This Memo 🌈
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
Info about the current status of this document, any errata, and how to give feedback on it can be found at http://www.rfc-editor.org/info/rfc7581.
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) in effect on the date of publication of this document. Please review these documents carefully, since they describe your rights and restrictions with respect to 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 are provided without warranty as described in the Simplified BSD License.
Table of Contents 📖
1. Introduction ....................................................4
1.1. Terminology ................................................4
1.2. Conventions Used in This Document ..........................5
2. Resources, Resource Blocks, and the Resource Pool ...............5
2.1. Resource Block Set Field ...................................6
3. Resource Accessibility/Availability .............................7
3.1. Resource Accessibility Field ...............................7
3.2. Resource Wavelength Constraints Field ......................9
3.3. Resource Block Pool State Field ...........................10
3.4. Resource Block Shared Access Wavelength
Availability Field ........................................12
4. Resource Block Information Field ...............................13
4.1. Optical Interface Class List Subfield .....................15
4.1.1. ITU-T G.698.1 Application Code Mapping .............17
4.1.2. ITU-T G.698.2 Application Code Mapping .............18
4.1.3. ITU-T G.959.1 Application Code Mapping .............20
4.1.4. ITU-T G.695 Application Code Mapping ...............22
4.2. Acceptable Client Signal List Subfield ....................23
4.3. Input Bit Rate List Subfield ..............................24
4.4. Processing Capability List Subfield .......................24
5. Security Considerations ........................................26
6. IANA Considerations ............................................26
6.1. Types for Subfields of WSON Resource Block Information ....26
7. References .....................................................27
7.1. Normative References ......................................27
7.2. Informative References ....................................28
Appendix A. Encoding Examples .....................................30
A.1. Wavelength Converter Accessibility Field ..................30
A.2. Wavelength Conversion Range Field .........................32
A.3. An OEO Switch with DWDM Optics ............................32
Contributors ......................................................35
Authors' Addresses ................................................371. Introduction ✨
A Wavelength Switched Optical Network (WSON) is a Wavelength Division Multiplexing (WDM) optical network where switching happens selectively based on the center wavelength of an optical signal 🌸.
[RFC6163] lays out a framework for Generalized Multiprotocol Label Switching (GMPLS) and Path Computation Element (PCE) control of a WSON 🧚. Building on that framework, [RFC7446] describes an information model that says what info is needed at various points in a WSON so that paths can be computed and Label Switched Paths (LSPs) can be established 💅.
This document gives efficient encodings for the info needed by the Routing and Wavelength Assignment (RWA) process in a WSON 🔥. These encodings can extend GMPLS signaling and routing protocols, and other mechanisms can use them to send the same info to a PCE 🫶. Note that since these encodings are efficient, they can give more accurate analysis of the control-plane communications and processing load for WSONs that want to use a GMPLS control plane 🦋.
Meanwhile, [RFC7579] gives efficient encodings for the info needed by the routing and label assignment process, and those could fit a wider range of technologies 🌈.
1.1. Terminology
Refer to [RFC6163] for definitions of the following:
- Coarse Wavelength Division Multiplexing (CWDM)
- Dense Wavelength Division Multiplexing (DWDM)
- Routing and Wavelength Assignment (RWA)
- Wavelength Division Multiplexing (WDM)
Refer to Section 5 of [RFC7446] for definitions of the following:
- resource
- resource block
- resource pool
The Optical Interface (OI) Code Point is a unique number that identifies all information related to optical characteristics of a physical interface 💜.
1.2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🎀.
2. Resources, Resource Blocks, and the Resource Pool 👑
This section gives encodings for the info fields defined in [RFC7446] that apply to WSON 💖. The encodings are designed to work in the GMPLS routing protocols OSPF [RFC4203] and IS-IS [RFC5307], and in the PCE Communication Protocol (PCEP) [RFC5440] ✨. The info distributed in [RFC4203] and [RFC5307] is arranged by nesting sub-TLVs inside TLVs, and this document defines elements to be used inside those constructs 🧚. The specific sub-TLV constructs and their nesting for the info fields defined here will be defined in the respective protocol enhancement documents 🫶.
This document defines the following info fields for resources inside an optical node:
- Resource Accessibility
<ResourceAccessibility> - Resource Wavelength Constraints
<ResourceWaveConstraints> - Resource Block Pool State
<RBPoolState> - Resource Block Shared Access Wavelength Availability
<RBSharedAccessWaveAvailability> - Resource Block Information
<ResourceBlockInfo>
Each of these fields works with one or more sets of resources, not just a single resource block 🌸. That's what motivates the field definition in Section 2.1 🦋.
2.1. Resource Block Set Field
okay so in a WSON node that has resource blocks (RBs), grouping those blocks into subsets lets you describe their shared properties efficiently 🍓. It also lets you describe the structure and characteristics of the resource pool, if they're nontrivial 💅. The Resource Block Set (RB Set) Field is defined in a similar way to the label set concept in [RFC3471] 🔥.
The info carried in an RB Set Field looks like this 💜:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action |C| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RB Identifier 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RB Identifier n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Action: 8 bits 🎀
0 - Inclusive List: this means the TLV contains one or more RB elements that are included in the list 🌈.
1 - Inclusive Range(s): this means the TLV contains one or more ranges of RBs 💖. Each range is written as two 32-bit RB identifiers. The first 32 bits are the RB identifier for the start of the range, and the next 32 bits are the RB identifier for the end of the range ✨. The Length field is what tells you how many ranges there are 🧚.
C (Connectivity bit) 🫶: set this to 0 to denote fixed (possibly multicast) connectivity, and set it to 1 to denote potential (switched) connectivity. It's used in the Resource Accessibility field and ignored elsewhere 🦋.
Reserved: 7 bits 🌸: this field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt 🍓.
Length: 16 bits 💅: the total length of this field in bytes 🔥.
RB Identifier 💜: the RB identifier is the ID of the resource block, and it's a 32-bit integer. Its scope is local to the node where it's applied 👑.
Usage Note: the inclusive range "Action" can result in a very compact encoding of resource sets 🙈. It can be a great idea to number resource blocks so that status updates (dynamic information) can take advantage of this efficiency 💖.
3. Resource Accessibility/Availability ✨
okay bestie, this section is all about the accessibility and availability of resource blocks inside a resource pool 🧚 it covers four fields: <ResourceAccessibility>, <ResourceWaveConstraints>, <RBPoolState>, and <RBSharedAccessWaveAvailability> 💖
3.1. Resource Accessibility Field 🔌
this field describes how the resource pool is laid out relative to the switching device 🎀 it tells you which input ports can reach which sets of resources, and which sets of resources can reach which output port. these are the <PoolInputMatrix> and <PoolOutputMatrix> from [RFC7446] 💅
here's the layout of the Resource Accessibility field:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Reserved(8bits)|C| Reserved (23 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Link Set Field A #1 |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RB Set Field A #1 |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Link set and RB set pairs as needed to |
: specify PoolInputMatrix :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Link Set Field B #1 |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RB Set B Field #1 (for output connectivity) |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Link Set and RB set pairs as needed to |
: specify PoolOutputMatrix :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+where:
C (Connectivity bit): this one tells you how the input and output ports connect to the resource blocks 👀
0means the device is fixed. For example, a connected port has to go through the resource block 🔒1means the device is switched. For example, a port can be configured to go through a resource, but it isn't required to ✨
for the Input and Output Link Set Fields, the Link Set Field encoding from [RFC7579] is the one to use 🫶
quick heads up: the direction parameter inside the Link Set Field says whether the link set is an input or an output link set, and the bidirectional value for that parameter is not permitted in this field 🙈
check out Appendix A.1 for an illustration of this encoding 🦋
3.2. Resource Wavelength Constraints Field 🌈
okay so resources like wavelength converters can have limited input or output wavelength ranges 💅 and because of how the optical system is built, not every wavelength can necessarily reach or leave every resource 😭 these properties get described using one or more Resource Wavelength Constraints fields, which look like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|O|B| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RB Set Field |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Wavelength Constraints |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Wavelength Constraints |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+I (Input):
1means the Input Wavelength Constraints field is present 🎀0means it isn't ✨
O (Output):
1means the Output Wavelength Constraints field is present 🌸0means it isn't 💫
B (Both):
1means a single Wavelength Constraints field stands in for both the Input and Output ones 🦋
right now, the only valid combinations of (I,O,B) are (1,0,0), (0,1,0), (1,1,0), and (0,0,1) 🧚
RB Set Field: a set of resource blocks (RBs) that all have the same wavelength restrictions 🍓
Input Wavelength Constraints: this shows the wavelength input restrictions for the RBs in the matching RB set. It's encoded with the Label Set Field from [RFC7579] 💜
Output Wavelength Constraints: this shows the wavelength output restrictions for the RBs in the matching RB set. It's also encoded with the Label Set Field from [RFC7579] 💜
3.3. Resource Block Pool State Field 📊
the pool's state is described by how many resources are available with particular characteristics 👑 a resource block set is used to encode all of them, or just a subset of the ones you care about 🫶 the usage state of resources inside a resource block set is encoded in one of two ways: a list of 16-bit integer values, or a bitmap that shows whether each single resource is available or in use 🔥
the bitmap encoding is the right fit when each resource block holds just one resource 🦋
this info can be pretty dynamic, meaning it can change whenever a connection (LSP) gets set up or torn down 😭
here's the layout:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RB Set Field |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RB Usage State |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+where:
Action = 0denotes a list of 16-bit integers 🔢Action = 1denotes a bitmap 🗺️
so Action = 0 covers the case where there are multiple elements for each resource block, and Action = 1 covers the case where each resource block only has a single element 💖
in both cases, the elements of the RB Set Field line up one-to-one with the values in the RB Usage State area 🫶
for the list encoding (Action = 0), it looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action = 0 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RB Set Field |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RB#1 State | RB#2 State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RB#n-1 State | RB#n State or Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+RB#i State (16 bits, unsigned integer): this tells you how many resources are available in Resource Block #i 🌟
whether the last 16 bits hold a wavelength converter (RB) state or padding is decided by the number of elements in the RB Set Field 🎀
for the bitmap encoding (Action = 1), it looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action = 1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RB Set Field |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RB Usage State Bitmap |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...... | Padding Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+RB Usage State Bitmap: it's variable length, but it has to be a multiple of 4 bytes 📏
each bit shows the usage status of one RB. 0 means the RB is available and 1 means it's in use 🟢🔴 the bitmap sequence follows the RB Set Field that comes with this element 💅
Padding bits: variable length 🫧
3.4. Resource Block Shared Access Wavelength Availability Field
okay so resource blocks can be accessed through a shared fiber 🧚 and if that's the case, we need to know which wavelengths are available on those shared fibers to figure out what resources are actually free. it's giving logistics, but make it make sense 💅
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|O|B| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RB Set Field |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Available Wavelength Set Field |
: (Optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Available Wavelength Set Field |
: (Optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the I bit (Input) tells you whether the Input Available Wavelength Set Field is there:
1means it's present 🌸0means it's absent 🙈
the O bit (Output) does the same job for the Output Available Wavelength Set Field:
1means it's present ✨0means it's absent
the B bit (Both) means one single Available Wavelength Set Field covers both the input and the output sets:
1means a single Available Wavelength Set Field represents both 🦋
right now, the only valid combinations of (I,O,B) are (1,0,0), (0,1,0), (1,1,0), and (0,0,1). anything else is not it 💀
RB Set Field: a resource block set where all the members share the same input fiber, the same output fiber, or both. very cute, very shared 🎀
Input Available Wavelength Set Field: this tells you which wavelengths are currently available (aka not being used) on the input fiber to this resource block. it's encoded using the Label Set Field of [RFC7579]. 🌈
Output Available Wavelength Set Field: same vibe, but for the output fiber from this resource block. also encoded using the Label Set Field of [RFC7579] 💜
4.
4. Resource Block Information Field ✨
okay so [RFC7446] defines the Resource Block Information <ResourceBlockInfo> field, and it's used to show a node's resource signal constraints and processing capabilities. this is the main character of the whole section 👑
the fundamental properties of a resource block are:
- Optical Interface Class List(s) 🔥
- Acceptable Client Signal (shared input, modulation, Forward Error Correction (FEC), bit rate, and Generalized Protocol Identifier (G-PID)) 💅
- Input Bit Rate 🍓
- Processing Capabilities (number of resources in a block, regeneration, performance monitoring, vendor specific) 🧚
<ResourceBlockInfo> fields are used to share relatively static info about individual resource blocks. that includes the resource block properties and how many resources are in a block. it's the lore, not the live drama 📚
when you have more than one <ResourceBlockInfo> field, there are no ordering requirements between them. no pressure, any order is valid 🫶 and the length of the <ResourceBlockInfo> field gets worked out from the length of the object that includes it.
the <ResourceBlockInfo> field looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RB Set Field |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|O|B| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Subfield 1 |
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Subfield N |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the RB Set Field is described in Section 2.1. go check it if you missed it 🎀
the shared input or output indication is given by the first bit (I), the second bit (O), and the third bit (B).
I (Input):
1means the resource blocks identified in the RB Set Field used a shared fiber for input access 🦋0means otherwise
O (Output):
1means the resource blocks identified in the RB Set Field used a shared fiber for output access ✨0means otherwise
B (Both):
1means the resource blocks identified in the RB Set Field used a shared fiber for both input and output access 👑0means otherwise
again, the only valid combinations of (I,O,B) are (1,0,0), (0,1,0), (1,1,0), and (0,0,1). same rule, no exceptions 💅
zero or more Optional Subfields MAY be present. they look like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the Length field tells you how long the value portion is, in bytes. so a subfield with no value portion has a length of zero 🙈 the subfield gets padded to 4-byte alignment, but the padding does not count toward the Length field. so a 3-byte value has a length of three, but the whole subfield is 8 bytes. math is mathing 🧮
unrecognized types are not processed, so just skip them, no drama 🫶 and if there are multiple subfields of the same type, only the first one of that type SHOULD be processed. the rest can be ignored 💀
here are the sub-TLV types that are defined:
Value Length Sub-TLV Type
1 variable Optical Interface Class List
2 variable Acceptable Client Signal List
3 variable Input Bit Rate List
4 variable Processing Capability Listfor allocating new types, check the IANA Considerations section 🍓
4.1. Optical Interface Class List Subfield
the Optical Interface Class List subfield looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |I|O|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optical Interface Classes |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+these are the I and O combinations that are defined:
I O
-----
0 0 Invalid
1 0 Optical Interface Class List acceptable in input
0 1 Optical Interface Class List available in output
1 1 Optical Interface Class List available on both input and
output.0 0 is invalid, so don't go there 💀 the resource block MAY contain one or more lists, depending on the input/output flags 🌸
the Optical Interface Classes format goes like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | OI Code Points |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optical Interface Class |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optical Interface Class (Cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the first 32 bits of the encoding shall be used to identify the semantics of the Optical Interface Class, like this:
S (Standard bit):
S=0identifies non-ITU code points 🎀S=1identifies ITU application codes 💖
with S=0, the OI Code Points field can only take this value:
0: reserved
future work may add support for vendor-specific application codes once the ITU-T has finished its work in that area. stay tuned 🔮
with S=1, the OI Code Points field can take these values:
0: reserved1: [G.698.1] application code2: [G.698.2] application code3: [G.959.1] application code4: [G.695] application code
for ITU application codes, the mapping between the string that defines the application code and the 64 bits that implement the optical interface class is given in the following sections. 🦋
4.1.1. ITU-T G.698.1 Application Code Mapping
okay so [G.698.1] defines these application codes: DScW-ytz(v) and B-DScW-ytz(v) 💖 here's what each letter is doing:
B: means BidirectionalD: means a DWDM applicationS: takes valuesN(narrow spectral excursion) orW(wide spectral excursion)c: Channel Spacing (GHz)W: takes valuesS(short-haul) orL(long-haul)y: takes values1(NRZ 2.5G) or2(NRZ 10G)t: onlyDvalue is defined (link does not contain optical amplifier)z: takes values2([G.652] fibre),3([G.653] fibre), or5([G.655] fibre)v: takes valuesS(Short wavelength),C(Conventional), orL(Long wavelength)
The F flag tells you whether there's an optional FEC encoding suffix or not 🎀
these get mapped into the 64-bit Optical Interface Class field like this 🧚
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B| D |S| c | W | y | t | z | v | F |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+and the actual values for each field:
B: 1 bidirectional, 0 otherwiseD(prefix): 0 reserved, 1 (D)S: 0 (N), 1 (W)c: Channel Spacing, 4 bits mapped according to the same definition as in the third figure in Section 3.2 of [RFC6205] (note that DWDM spacing applies here).W: 0 reserved, 2 (S), 3 (L)y: 0 reserved, 1 (1), 2 (2)t: 0 reserved, 4 (D)z: 0 reserved, 2 (2), 3 (3), 5 (5)v: 0 reserved, 1 (S), 2 (C), 3 (L)F(suffix): 0 No FEC encoding suffix present, 1 FEC encoding suffix present
anything not listed here is a no-go for this application code 🙅♀️ and the last 32 bits are reserved, so they shall be set to zero. 🔒
4.1.2. ITU-T G.698.2 Application Code Mapping
[G.698.2] defines these application codes too: DScW-ytz(v) and B-DScW-ytz(v) ✨ the letters mean:
B: means BidirectionalD: means a DWDM applicationS: takes valuesN(narrow spectral excursion) orW(wide spectral excursion)c: Channel Spacing (GHz)W: takes valuesC(link is dispersion compensated) orU(link is dispersion uncompensated)y: takes values1(NRZ 2.5G) or2(NRZ 10G)t: takes valueA(link may contains optical amplifier)z: takes values2([G.652] fibre),3([G.653] fibre), or5([G.655] fibre)v: takes valuesS(Short wavelength),C(Conventional), orL(Long wavelength)- an optional
Fcan be added to indicate a FEC encoding 🌸
same mapping vibes as before, so here's the Optical Interface Class layout 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B| D |S| c | W | y | t | z | v | F |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+and the values:
B: 1 bidirectional, 0 otherwiseD(prefix): 0 reserved, 1 (D)S: 0 (N), 1 (W)c: Channel Spacing, 4 bits mapped according to the same definition as in the third figure in Section 3.2 of [RFC6205] (note that DWDM spacing applies here).W: 0 reserved, 10 (C), 11 (U)y: 0 reserved, 1 (1), 2 (2)t: 0 reserved, 1 (A)z: 0 reserved, 2 (2), 3 (3), 5 (5)v: 0 reserved, 1 (S), 2 (C), 3 (L)F(suffix): 0 reserved, 1 FEC encoding
Values not mentioned here are not allowed in this application code. The last 32 bits are reserved and shall be set to zero. 🔒
4.1.3. ITU-T G.959.1 Application Code Mapping
this one is a bigger family ✨ [G.959.1] defines these application codes: PnWx-ytz and BnWx-ytz. here's the breakdown:
P,B: when present, indicate Plural or Bidirectionaln: maximum number of channels supported by the application code (i.e., an integer number)W: takes valuesI(intra-office),S(short-haul),L(long-haul),V(very long-haul), orU(ultra long-haul)x: maximum number of spans allowed within the application code (i.e., an integer number)y: takes values1(NRZ 2.5G),2(NRZ 10G),9(NRZ 25G),3(NRZ 40G), or7(RZ 40G)t: takes valuesA(power levels suitable for a booster amplifier in the originating ONE and power levels suitable for a pre-amplifier in the terminating ONE),B(booster amplifier only),C(pre-amplifier only), orD(no amplifiers)z: takes values1(1310 nm sources on [G.652] fibre),2(1550 nm sources on [G.652] fibre),3(1550 nm sources on [G.653] fibre), or5(1550 nm sources on [G.655] fibre).
and these suffixes can be tacked onto the end 🎀
F: FEC encodingD: Adaptive dispersion compensationE: receiver capable of dispersion compensationr: reduced target distancea: power levels appropriate to APD receiversb: power levels appropriate to PIN receivers
these values are encoded like this 🧚
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| p | P | n | W | x | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| y | t | z | suffix | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+and the values:
p(prefix): 0 otherwise, 1 Bidirectional (B)P(optional): 0 not present, 2 (P).n: maximum number of channels (10 bits, up to 1023 channels)W: 0 reserved, 1 (I), 2 (S), 3 (L), 4 (V), 5 (U)x: number of spans (6 bits, up to 64 spans)y: 0 reserved, 1 (1), 2 (2), 3 (3), 7 (7), 9 (9)t: 0 reserved, 1 (A), 2 (B), 3 (C), 4 (D)z: 0 reserved, 1 (1), 2 (2), 3 (3), 5 (5)suffix: a 6-bit bitmap, where a "1" in the appropriate slot indicates that the corresponding suffix has been added.
0 1 2 3 4 5
+-+-+-+-+-+-+
|F|D|E|r|a|b|
+-+-+-+-+-+-+4.1.4. ITU-T G.695 Application Code Mapping
[G.695] defines these application codes: CnWx-ytz, B-CnWx-ytz, and S-CnWx-ytz 🍓
the optional prefixes:
B: BidirectionalS: a system using a black link approach
and the rest of the code:
C: CWDM (Coarse WDM) applicationn: maximum number of channels supported by the application code (i.e., an integer number)W: takes valuesS(short-haul) orL(long-haul)x: maximum number of spans allowedy: takes values0(NRZ 1.25G),1(NRZ 2.5G), or2(NRZ 10G).t: takes valueD(link does not contain any optical amplifier).z: takes values1(1310 nm region for [G.652] fibre),2(ITU-T [G.652] fibre),3([G.653] fibre), or5([G.655] fibre)
and the suffix you can add:
F: FEC encoding
since these codes are super similar to the ones from the [G.959.1] section, most of the fields get reused 🙌 the 64-bit Optical Interface Class field is encoded like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| p | C | n | W | x | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| y | t | z | suffix | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+and the values:
p: 0 no prefix, 1 (B) bidirectional, 2 (S) black linkC: 0 reserved, 3 (C)n: maximum number of channels (10 bits, up to 1023 channels)W: 0 reserved, 1 reserved, 2 (S), 3 (L), > 3 reservedx: number of spans (6 bits, up to 64 spans)y: 0 (0), 1 (1), 2 (2), > 2 reservedt: 4 (D), all other values are reservedz: 0 reserved, 1 (1), 2 (2), 3 (3)suffix: a 6-bit bitmap, where a "1" in the appropriate slot indicates that the corresponding suffix has been added.
0 1 2 3 4 5
+-+-+-+-+-+-+
|F|0|0|0|0|0|
+-+-+-+-+-+-+4.2. Acceptable Client Signal List Subfield
this subfield is basically a list of the input client signal types that are acceptable 💅
The acceptable client signal list is a list of Generalized Protocol Identifiers (G-PIDs).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Number of G-PIDs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| G-PID #1 | G-PID #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: | :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| G-PID #N | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Number of G-PIDs: an integer greater than or equal to one.
- G-PIDs: assigned by IANA. Many are defined in [RFC3471] and [RFC4328].
4.3. Input Bit Rate List Subfield
this one pairs up with the client signal list above 🫶 it's the bit rate for each input client signal type that's in the Input Client Signal List.
The number of Input Bit Rates MUST match the number of G-PIDs. 🔥
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Bit Rate of G-PID #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Bit Rate of G-PID #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Input Bit Rates are in IEEE 754 floating point format [IEEE]. 🧮
4.4. Processing Capability List Subfield 🧚
okay so the Processing Capability List subfield is basically a list of capabilities you can get from the referred resources 💅 there are three:
- Regeneration capability
- Fault and performance monitoring
- Vendor-specific capability
bestie, fault and performance monitoring and vendor-specific capability don't have any extra capability parameters, so they're giving low maintenance 🫶
the Processing Capability List subfield is defined like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Processing Cap ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Possible additional capability parameters depending upon |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: the processing ID :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the Processing Cap ID field defines these processing capabilities (this part is so important, bestie 👑):
0: Reserved
1: Regeneration capability
2: Fault and performance monitoring
3: Vendor-specific capabilitywhen the Processing Cap ID is "Regeneration capability", the following additional capability parameters are provided in the following field 🌸
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T | C | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+so the T bit tells you what type of regenerator it is 🦋
T=0: Reserved
T=1: 1R Regenerator
T=2: 2R Regenerator
T=3: 3R Regeneratorand the C bit tells you what the regenerator is capable of 💖
C=0: Reserved
C=1: Fixed Regeneration Point
C=2: Selective Regeneration PoolsHeads up, bestie: when the capability of the regenerator is "Selective Regeneration Pools", regeneration pool properties like input and output restrictions and availability need to be specified. These properties get encoded in the field that provides the additional capability parameters, starting with the bits marked Reserved in the figure right above. An additional specification describing how these parameters get encoded is required before the value C=2 can be used. 🚨
5. Security Considerations 🔐
okay so this document defines protocol-independent encodings for WSON information and does not introduce any security issues, which is a whole vibe ✨
BUT, other documents that use these encodings inside protocol extensions need to think about the issues and risks tied to inspection, interception, modification, or spoofing of any of this information 😭 it's expected that those documents will describe the necessary security measures to give adequate protection. if you want the general tea on security in GMPLS networks, check out [RFC5920] 🕵️♀️
6. IANA Considerations 🎀
this document introduces a new top-level registry for GMPLS routing parameters for WSON encoding. this new IANA registry was created so that a new type and new values can be assigned for the new "GMPLS Routing Parameters for WSON" registry. just note that this registry is only used in routing, not in signaling 🧠
6.1. Types for Subfields of WSON Resource Block Information ✨
under the new "GMPLS Routing Parameters for WSON" registry, a new IANA subregistry was created for nested subfields of the Resource Block Information field. it's named "Types for Subfields of WSON Resource Block Information Registry". this registry will be maintained via Standards Action as defined by [RFC5226] 📋
the initial values in the registry look like this:
Value Length Description Reference
----- ------ ------------ ---------
0 Reserved
1 variable Optical Interface Class List [RFC7581]
2 variable Acceptable Client Signal List [RFC7581]
3 variable Input Bit Rate List [RFC7581]
4 variable Processing Capability List [RFC7581]
5-65535 Unassigned7. References 📚
7.1. Normative References 💜
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. - [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, DOI 10.17487/RFC4328, January 2006,
<http://www.rfc-editor.org/info/rfc4328>. - [RFC6205] Otani, T., Ed., and D. Li, Ed., "Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers", RFC 6205, DOI 10.17487/RFC6205, March 2011,
<http://www.rfc-editor.org/info/rfc6205>. - [RFC7446] Lee, Y., Ed., Bernstein, G., Ed., Li, D., and W. Imajuku, "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks", RFC 7446, DOI 10.17487/RFC7446, February 2015,
<http://www.rfc-editor.org/info/rfc7446>. - [RFC7579] Bernstein, G., Ed., Lee, Y., Ed., Li, D., Imajuku, W., and J. Han, "General Network Element Constraint Encoding for GMPLS-Controlled Networks", RFC 7579, DOI 10.17487/RFC7579, June 2015,
<http://www.rfc-editor.org/info/rfc7579>.
7.2. Informative References 🌈
- [G.652] ITU-T, "Characteristics of a single-mode optical fibre and cable", ITU-T Recommendation G.652, November 2009.
- [G.653] ITU-T, "Characteristics of a dispersion-shifted, single-mode optical fibre and cable", ITU-T Recommendation G.653, July 2010.
- [G.655] ITU-T, "Characteristics of a non-zero dispersion-shifted single-mode optical fibre and cable", ITU-T Recommendation G.655, November 2009.
- [G.695] ITU-T, "Optical interfaces for coarse wavelength division multiplexing applications", ITU-T Recommendation G.695, January 2015.
- [G.698.1] ITU-T, "Multichannel DWDM applications with single-channel optical interfaces", ITU-T Recommendation G.698.1, November 2009.
- [G.698.2] ITU-T, "Amplified multichannel dense wavelength division multiplexing applications with single channel optical interfaces", ITU-T Recommendation G.698.2, November 2009.
- [G.959.1] ITU-T, "Optical transport network physical layer interfaces", ITU-T Recommendation G.959.1, February 2012.
- [IEEE] IEEE, "IEEE Standard for Binary Floating-Point Arithmetic", IEEE Standard 754.
- [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, DOI 10.17487/RFC3471, January 2003,
<http://www.rfc-editor.org/info/rfc3471>. - [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005,
<http://www.rfc-editor.org/info/rfc4203>. - [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. - [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008,
<http://www.rfc-editor.org/info/rfc5307>. - [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009,
<http://www.rfc-editor.org/info/rfc5440>. - [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2009,
<http://www.rfc-editor.org/info/rfc5511>. - [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<http://www.rfc-editor.org/info/rfc5920>. - [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, DOI 10.17487/RFC6163, April 2011,
<http://www.rfc-editor.org/info/rfc6163>.
Appendix A. Encoding Examples 🧁
A.1. Wavelength Converter Accessibility Field ✨
okay so picture this 🦋 Figure 1 shows a wavelength converter pool setup called "shared per fiber." In this one, the input and output pool matrices are just:
+-----+ +-----+
| 1 1 | | 1 0 |
WI =| |, WE =| |
| 1 1 | | 0 1 |
+-----+ +-----+The wavelength converters are resource blocks, and the wavelength converter pool is a resource block pool 🍓 Here's how that gets encoded:
+-----------+ +------+
| |--------------------->| |
| |--------------------->| C |
/| | |--------------------->| o |
/D+--->| |--------------------->| m |
+ e+--->| | | b |=======>
========>| M| | Optical | +-----------+ | i | Port O1
Port I1 + u+--->| Switch | | WC Pool | | n |
\x+--->| | | +-----+ | | e |
\| | +----+->|WC #1|--+---->| r |
| | | +-----+ | +------+
| | | | +------+
/| | | | +-----+ | | |
/D+--->| +----+->|WC #2|--+---->| C |
+ e+--->| | | +-----+ | | o |
========>| M| | | +-----------+ | m |=======>
Port I2 + u+--->| | | b | Port O2
\x+--->| |--------------------->| i |
\| | |--------------------->| n |
| |--------------------->| e |
| |--------------------->| r |
+-----------+ +------+
Figure 1: An Optical Switch Featuring a Shared Per-Fiber Wavelength
Converter Pool Architecture 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |1| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: I1,I2 can connect to either WC1 or WC2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=0 |0| Reserved | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=0 |1| Reserved | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RB ID = #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RB ID = #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: WC1 can only connect to O1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=0 |1| Reserved | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=0 |0| Reserved | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RB ID = #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: WC2 can only connect to O2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=0 |1| Reserved | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier = #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=0 |0| | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RB ID = #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+A.2. Wavelength Conversion Range Field 🌈
this example builds on Figure 1 and shows how to represent the wavelength conversion range of the wavelength converters 💜 say the wavelength range of input and output of WC1 and WC2 is {L1, L2, L3, L4}. Here's the encoding:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Note: WC Set
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action=0 |1| Reserved | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WC ID = #1 | WC ID = #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: wavelength input range
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | Num Wavelengths = 4 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Grid | C.S. | Reserved | n for lowest frequency = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: wavelength output range
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | Num Wavelengths = 4 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Grid | C.S. | Reserved | n for lowest frequency = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+A.3. An OEO Switch with DWDM Optics 🦋
okay bestie, Figure 2 shows an electronic switch fabric surrounded by DWDM optics ✨ in this example, the electronic fabric can handle either G.709 or Synchronous Digital Hierarchy (SDH) signals only (2.5 or 10 Gbps). to describe this node, you need the following info in Reduced Backus-Naur Form (RBNF) form [RFC5511] 💅
<Node_Info> ::= <Node_ID>
[Other GMPLS info-elements]
[<ConnectivityMatrix>...]
[<ResourcePool>]
[<RBPoolState>]so in this case there is complete port-to-port connectivity, which means the <ConnectivityMatrix> is not required 🙈 and since there are enough ports to handle all the wavelength signals, the <RBPoolState> element is not needed either. slay, efficient 👑
so the main focus is the <ResourcePool> field 🌸
<ResourcePool> ::= <ResourceBlockInfo>
[<RBAccessibility>...]
[<ResourceWaveConstraints>...] /| +-----------+ +-------------+ +------+
/D+--->| +--->|Tunable Laser|-->| |
+ e+--->| | +-------------+ | C |
========>| M| | | ... | o |=======>
Port I1 + u+--->| | +-------------+ | m | Port O1
\x+--->| |--->|Tunable Laser|-->| b |
\| | Electric | +-------------+ +------+
| Switch |
/| | | +-------------+ +------+
/D+--->| +--->|Tunable Laser|-->| |
+ e+--->| | +-------------+ | C |
========>| M| | | ... | o |=======>
Port I2 + u+--->| | +-------------+ | m | Port O2
\x+--->| +--->|Tunable Laser|-->| b |
\| | | +-------------+ +------+
| |
/| | | +-------------+ +------+
/D+--->| |--->|Tunable Laser|-->| |
+ e+--->| | +-------------+ | C |
========>| M| | | ... | o |=======>
Port I3 + u+--->| | +-------------+ | m | Port O3
\x+--->| |--->|Tunable Laser|-->| b |
\| +-----------+ +-------------+ +------+
Figure 2: An Optical Switch Built around
an Electronic Switching Fabricthe resource block info tells us about the processing constraints of the receivers, transmitters, and the electronic switch 🔥 the resource availability info is super simple, but it tells us that all signals must traverse the electronic fabric (fixed connectivity) 💖 and the resource wavelength constraints aren't needed, because there are no special wavelength constraints for the resources that wouldn't already show up as port/wavelength constraints 🧚
the <ResourceBlockInfo> is encoded like this 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RB Set Field |
: (only one resource block in this example with shared |
| input/output case) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1|0| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optical Interface Class List(s) |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Client Signal Type |
: (G-PIDs for SDH and G.709) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Bit Rate Range List |
: (2.5 Gbps, 10 Gbps) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Processing Capabilities List |
: Fixed (non optional) 3R regeneration :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+since there's fixed connectivity to the resource blocks (the electronic switch), the <RBAccessibility> looks like this 💅
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connectivity=0|Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Link Set Field A #1 |
: (All input links connect to resource) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RB Set Field A #1 |
: (trivial set only one resource block) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Link Set Field B #1 |
: (All output links connect to resource) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Contributors 🎀
these are the amazing people who contributed to this doc, bestie 🫶
Diego Caviglia
Ericsson
Via A. Negrone 1/A 16153
Genoa
Italy
Phone: +39 010 600 3736
EMail: diego.caviglia@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
Pierre Peloso
ALU
EMail: pierre.peloso@alcatel-lucent.com
Cyril Margaria
EMail: cyril.margaria@gmail.com
Giovanni Martinelli
Cisco
EMail: giomarti@cisco.com
Gabriele M Galimberti
Cisco
EMail: ggalimbe@cisco.com
Lyndon Ong
Ciena Corporation
EMail: lyong@ciena.com
Daniele Ceccarelli
Ericsson
EMail: daniele.ceccarelli@ericsson.comAuthors' Addresses 🫶
the editors and authors, slay 👑
Greg M. Bernstein (editor)
Grotto Networking
Fremont, California
United States
Phone: (510) 573-2237
EMail: gregb@grotto-networking.com
Young Lee (editor)
Huawei Technologies
5340 Legacy Drive Build 3
Plano, TX 75024
United States
Phone: (469) 277-5838
EMail: leeyoung@huawei.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
Jianrui Han
Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base,
Bantian, Longgang District
Shenzhen 518129
China
Phone: +86-755-28972916
EMail: hanjianrui@huawei.com📦 where this page comes from
- ietf: rfc7581 2015-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms