RFC 7579

General Network Element Constraint Encoding for GMPLS-Controlled Networks

πŸ“… published June 2015, from ietf

RFC 7579: General Network Element Constraint Encoding for GMPLS-Controlled Networks πŸ¦‹

okay so this is RFC 7579 πŸ’– It's a Standards Track document from the IETF, dated June 2015, and its ISSN is 2070-1721. The authors are G. Bernstein, Ed. (Grotto Networking), Y. Lee, Ed. and D. Li (both Huawei), W. Imajuku (NTT), and J. Han (Huawei). The title block doesn't list anything it obsoletes or updates. πŸŽ€

Abstract ✨

okay so GMPLS (Generalized Multiprotocol Label Switching) can control a whole bunch of different technologies 🌈 and in some of them, network elements and links come with extra routing rules, like asymmetric switch connectivity, non-local label assignment, and label range limits on links. πŸ’…

this doc gives us efficient encodings that don't depend on any one protocol 🧚 for general info elements covering connectivity, label constraints, and label availability. the plan is that protocol-specific docs will point back to this one to explain how the info gets carried for specific uses. 🫢

Status of This Memo

this is an Internet Standards Track document πŸ”₯

it's a product of the Internet Engineering Task Force (IETF). it represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). more on Internet Standards is in Section 2 of RFC 5741. πŸ’œ

for the current status, any errata, and how to send feedback, check out http://www.rfc-editor.org/info/rfc7579. 🌸

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 they stand on the publication date. please actually read those, bestie, because they spell out your rights and restrictions for this document. πŸ™ˆ any Code Components pulled out of this document have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, same as that license says. πŸ’–

Table of Contents

   1. Introduction ....................................................3
      1.1. Node Switching Asymmetry Constraints .......................3
      1.2. Non-local Label Assignment Constraints .....................4
      1.3. Conventions Used in This Document ..........................4
   2. Encoding ........................................................4
      2.1. Connectivity Matrix Field ..................................5
      2.2. Port Label Restrictions Field ..............................6
           2.2.1. SIMPLE_LABEL ........................................8
           2.2.2. CHANNEL_COUNT .......................................8
           2.2.3. LABEL_RANGE .........................................9
           2.2.4. SIMPLE_LABEL & CHANNEL_COUNT ........................9
           2.2.5. LINK_LABEL_EXCLUSIVITY .............................10
      2.3. Link Set Field ............................................10
      2.4. Available Labels Field ....................................12
      2.5. Shared Backup Labels Field ................................13
      2.6. Label Set Field ...........................................14
   3. Security Considerations ........................................16
   4. IANA Considerations ............................................17
   5. References .....................................................17
      5.1. Normative References ......................................17
      5.2. Informative References ....................................18
   Appendix A. Encoding Examples .....................................19
      A.1. Link Set Field ............................................19
      A.2. Label Set Field ...........................................19
      A.3. Connectivity Matrix .......................................20
      A.4. Connectivity Matrix with Bidirectional Symmetry ...........24
      A.5. Priority Flags in Available/Shared Backup Labels ..........26
   Contributors ......................................................27
   Authors' Addresses ................................................28

1. Introduction 🧚

some data-plane technologies that want to use a GMPLS control plane come with extra limits on switching capability and label assignment πŸ“ some of them also have to do non-local label assignment because of how the technology works. the wavelength continuity constraint in Wavelength Switched Optical Networks (WSONs) [RFC6163] is a classic example. constraints like that can mean you need link-by-link label availability in path computation and label assignment. πŸ’…

this document gives efficient encodings for the info that routing and label assignment need in technologies like WSON, and it could fit a much wider range of technologies too ✨ these encodings can extend GMPLS signaling and routing protocols. other mechanisms can also use them to send the same info to a path computation element (PCE). 🫢

1.1. Node Switching Asymmetry Constraints

sometimes a signal or packet on one input port can't reach every output port, and in some network elements (like a simple multiplexer) the connectivity between certain input and output ports is just fixed πŸ™ˆ so for path computation, we model this with a connectivity matrix. πŸ¦‹

the connectivity matrix (ConnectivityMatrix) stands for either the potential connectivity matrix of an asymmetric switch or the fixed connectivity of an asymmetric device like a multiplexer. this matrix doesn't capture any specific internal blocking behavior. it just shows which input ports and labels (e.g., wavelengths) could possibly connect to a given output port and label pair πŸ’– modeling state-dependent internal blocking for a node is out of scope for this document. since it's so implementation-dependent, it probably won't get standardized in the future either 😭 the connectivity matrix is a conceptual M*m by N*n matrix, where M is the number of input ports (each with m labels) and N is the number of output ports (each with n labels). 🌈

1.2. Non-local Label Assignment Constraints

if the equipment in a network needs non-local label assignment, there can be constraints from the limits of the ports themselves and from the current label usage πŸŽ€ these constraints only matter when label assignment is non-local. in MPLS, for example, an LSR might have a limited range of labels it can use on an output port, plus a set of labels already in use on that port. those labels are therefore unavailable 🌸 this info doesn't need to be shared unless the LSR's label swapping ability is limited. for example, if a Time Division Multiplexer (TDM) node can't do time-slot interchange, or a WSON can't do wavelength conversion, then label assignment isn't local to a single node. in that case, it may be useful to share the label assignment constraint info for path computation. πŸ‘‘

port label restrictions (PortLabelRestriction) model the label restrictions that the network element (node) and link can put on a port. they tell us which labels may or may not be used on a link, and they're meant to be relatively static πŸ’… more dynamic info lives in the available labels info. port label restrictions can be given relative to the port in general, or relative to a specific connectivity matrix, for more modeling flexibility ✨ [Switch] shows an example where both switch and fixed connectivity matrices are used, and both types of constraints show up on the same port. πŸ”₯

1.3. 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. Encoding πŸ’–

this section gives encodings for the information elements 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 meant to go inside those constructs 🧚 the specific sub-TLV constructs and how sub-TLVs nest for the info element defined here will be defined in the respective protocol enhancement documents. ✨

2.1. Connectivity Matrix Field πŸ¦‹

okay so the Connectivity Matrix Field is basically how input ports get hooked up to output ports on a network element πŸ”Œβœ¨ The switch and fixed connectivity matrices can be squished down into a minimal list of input and output port set pairs that have mutual connectivity. As described in [Switch], that minimal list naturally turns into a graph for path computation, and this version needs the fewest extra nodes and links πŸ’…

The Connectivity Matrix Field is only uniquely identified by the advertising node 🫢 A node can have more than one of these fields because it can split its switch matrix into several sub-matrices. The main reason for splitting is to keep each information element small and to allow incremental updates πŸ’– When the matrix gets partitioned, each sub-matrix is mutually exclusive from the others in terms of which ports and labels belong to it. This means two matrices will never have the same {src port, src label, dst port, dst label} 😭

Each sub-matrix gets its own Matrix ID, and that Matrix ID MUST represent a unique combination of {src port, src label, dst port, dst label} ✨

Here's the TLV encoding of this list of link set pairs πŸŽ€

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Conn  |   MatrixID    |            Reserved                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Link Set A #1                         |
      :                               :                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Link Set B #1                         :
      :                               :                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Additional Link Set Pairs as Needed           |
      :                     to Specify Connectivity                   :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where:

  • Connectivity (Conn) (4 bits) is the device type.
    • 0 - the device is fixed
    • 1 - the device is switched (e.g., Reconfigurable Optical Add/Drop Multiplexer / Optical Cross-Connect (ROADM/OXC))
  • MatrixID represents the ID of the connectivity matrix and is an 8-bit integer. The value of 0xFF is reserved for use with port label constraints and should not be used to identify a connectivity matrix πŸ™ˆ

Link Set A #1 and Link Set B #1 together represent a pair of link sets. See Section 2.3 for a detailed description of the Link Set Field. There are two permitted combinations for the Link Set Field parameter dir for link set A and B pairs πŸ”₯

  • Link Set A dir=input, Link Set B dir=output In this case, the meaning of the pair of link sets A and B is that any signal that inputs a link in set A can be potentially switched out of an output link in set B 🌸
  • Link Set A dir=bidirectional, Link Set B dir=bidirectional In this case, the meaning of the pair of link sets A and B is that any signal that inputs on the links in set A can potentially output on a link in set B, and any input signal on the links in set B can potentially output on a link in set A. If link set A is an input and link set B is an output for a signal, then it implies that link set A is an output and link set B is an input for that signal 🧚

See Appendix A for both types of encodings as applied to a ROADM example πŸ‘‘


2.2. Port Label Restrictions Field 🌈

The Port Label Restrictions Field tells us what labels may or may not be used on a link πŸ’œ

Port label restrictions can be encoded as follows. More than one of these fields may be needed to fully specify a complex port constraint. When more than one of these fields is present, the resulting restriction is the union of the restrictions expressed in each field. Using the reserved value of 0xFF for the MatrixID means the restriction applies to the port and not to a specific connectivity matrix πŸ’…

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   MatrixID    |    RstType    | Switching Cap |     Encoding  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Additional Restriction Parameters per Restriction Type    |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where:

  • MatrixID: either is the value in the corresponding Connectivity Matrix Field or takes the value 0xFF to indicate the restriction applies to the port regardless of any connectivity matrix πŸ¦‹
  • RstType (Restriction Type) can take the following values and meanings:
    • 0: SIMPLE_LABEL (Simple label selective restriction). See Section 2.2.1 for details.
    • 1: CHANNEL_COUNT (Channel count restriction). See Section 2.2.2 for details.
    • 2: LABEL_RANGE (Label range device with a movable center label and width). See Section 2.2.3 for details.
    • 3: SIMPLE_LABEL & CHANNEL_COUNT (Combination of SIMPLE_LABEL and CHANNEL_COUNT restriction. The accompanying label set and channel count indicate labels permitted on the port and the maximum number of channels that can be simultaneously used on the port). See Section 2.2.4 for details.
    • 4: LINK_LABEL_EXCLUSIVITY (A label may be used at most once amongst a set of specified ports). See Section 2.2.5 for details.

Switching Cap (Switching Capability) is defined in [RFC4203], and LSP Encoding Type is defined in [RFC3471]. The combination of these fields defines the type of labels used in specifying the port label restrictions, as well as the interface type to which these restrictions apply πŸŽ€

The Additional Restriction Parameters per RestrictionType field is an optional field that describes additional restriction parameters for each RestrictionType pertaining to specific protocols ✨

2.2.1. SIMPLE_LABEL πŸ“

In the case of SIMPLE_LABEL, the format is:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | MatrixID      | RstType = 0   | Switching Cap |   Encoding    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Label Set Field                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In this case, the accompanying label set indicates the labels permitted on the port/matrix.

See Section 2.6 for the definition of label set.

2.2.2. CHANNEL_COUNT 🌸

In the case of CHANNEL_COUNT, the format is:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | MatrixID      | RstType = 1   |Switching Cap  |   Encoding    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        MaxNumChannels                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In this case, the accompanying MaxNumChannels indicates the maximum number of channels (labels) that can be simultaneously used on the port/matrix.

MaxNumChannels is a 32-bit integer.

2.2.3. LABEL_RANGE 🧚

In the case of LABEL_RANGE, the format is:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | MatrixID      | RstType = 2   | Switching Cap |  Encoding     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          MaxLabelRange                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Label Set Field                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This is a generalization of the waveband device. The MaxLabelRange indicates the maximum width of the waveband in terms of the channels spacing given in the Label Set Field. The corresponding label set is used to indicate the overall tuning range πŸ‘‘

MaxLabelRange is a 32-bit integer.

See Section 2.6.2 for an explanation of label range.

2.2.4. SIMPLE_LABEL & CHANNEL_COUNT πŸ’–

In the case of SIMPLE_LABEL & CHANNEL_COUNT, the format is:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | MatrixID      | RstType = 3   | Switching Cap |   Encoding    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        MaxNumChannels                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Label Set Field                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In this case, the accompanying label set and MaxNumChannels indicate labels permitted on the port and the maximum number of labels that can be simultaneously used on the port.

See Section 2.6 for the definition of label set.

In the case of Link Label Exclusivity, the format is:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | MatrixID      | RstType = 4   | Switching Cap |   Encoding    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Link Set Field                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In this case, the accompanying link set indicates that a label may be used at most once among the ports in the Link Set Field.

See Section 2.3 for the definition of link set.

Okay bestie, we're going to be describing groups of links constantly, so we need a quick way to say "these links" without listing every single one πŸ’… That's where the link set comes in. It's basically a cousin of the label set concept from [RFC3471]. The Link Set Field lives inside the <ConnectivityMatrix> (see Section 2.1), and here's everything a link set carries πŸ¦‹

       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     |Dir|  Format   |         Length                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Link Identifier 1                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                               :                               :
      :                               :                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Link Identifier N                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Action: 8 bits 🎯

  • 0 - Inclusive List: one or more link identifiers are included in the link set. Each identifier points to a separate link that's part of the set πŸ’–
  • 1 - Inclusive Range: the link set defines a range of links and holds exactly two link identifiers. The first marks the start of the range and the second marks the end. Every link with a numeric value between those bounds is part of the set ✨ A value of zero in either position means that side of the range has no bound. Quick heads-up: the Action field can only be set to 0x01 (Inclusive Range) when the identifier for unnumbered link is used. πŸ™ˆ

Dir: Directionality of the link set (2 bits) ➑️

  • 0 - bidirectional
  • 1 - input
  • 2 - output

In optical networks, people think in terms of unidirectional and bidirectional links 🌈 For example, label restrictions or connectivity might be different for an input port than for its "companion" output port, if one exists. Also, "interfaces" like the ones discussed in the Interfaces MIB [RFC2863] are assumed to be bidirectional, and so are the links advertised in various link state routing protocols. 🫢

Format: The format of the link identifier (6 bits) 🧩

  • 0 - Link Local Identifier: the links in the set are identified by link local identifiers, and all of those are supplied in the context of the advertising node 🌸
  • 1 - Local Interface IPv4 Address: the links in the set are identified by Local Interface IPv4 Address πŸ“
  • 2 - Local Interface IPv6 Address: the links in the set are identified by Local Interface IPv6 Address πŸ’œ
  • Others - Reserved for future use

Note that all link identifiers in the same list must be of the same type. πŸ™ƒ

Length: 16 bits πŸ“ This field indicates the total length in bytes of the Link Set Field.

Link Identifier: length depends on the link format πŸ”‘ The link identifier represents the port being described, either for connectivity or for label restrictions. It can be the link local identifier from GMPLS routing [RFC4202], GMPLS OSPF routing [RFC4203], and IS-IS GMPLS routing [RFC5307]. Using the link local identifier format can give you more compact encodings, as long as the assignments are done in a reasonable fashion 🧚


2.4. Available Labels Field 🏷️

The Available Labels Field is made up of priority flags plus one variable-length Label Set 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     PRI       |              Reserved                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Label Set Field                           |
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where:

PRI (Priority Flags, 8 bits): this is a bitmap that shows which priorities are being advertised πŸŽ€ It's in ascending order, so the leftmost bit is priority level 0 (the highest) and the rightmost bit is priority level 7 (the lowest). A bit MUST be set (1) for each priority represented in the sub-TLV, and it MUST NOT be set (0) when that priority isn't represented. If a label is available at priority M, it MUST be advertised available at each priority N < M. At least one priority level MUST be advertised. 🚨

The PRI field shows whether labels are available for Label Switched Path (LSP) setup and preemption, as described in [RFC3209] 🌟

When a label is advertised as available for priorities 0, 1, ... M, it can be used by any LSP of priority N <= M. When a label is in use by an LSP of priority M, it can be used by an LSP of priority N < M if LSP preemption is supported πŸ‘‘

When a label was first advertised as available for priorities 0, 1, ... M, and then gets used for an LSP at some priority N (N<=M), that label gets advertised as available for 0, ... N-1 πŸ¦‹

Note that the Label Set Field is defined in Section 2.6. See Appendix A.5 for illustrative examples. πŸ“š


2.5. Shared Backup Labels Field πŸ›Ÿ

The Shared Backup Labels Field is also made of priority flags plus one variable-length Label Set 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     PRI         |            Reserved                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Label Set Field                           |
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where:

PRI (Priority Flags, 8 bits): same deal as before, a bitmap of which priorities are being advertised, ascending from level 0 (highest) to level 7 (lowest) 🌈 A bit MUST be set (1) for each priority represented in the sub-TLV, and it MUST NOT be set (0) when that priority isn't represented. If a label is available at priority M, it MUST be advertised available at each priority N < M. At least one priority level MUST be advertised. πŸ’…

The same LSP setup and preemption rules from Section 2.4 apply here πŸŽ€

Note that Label Set Field is defined in Section 2.6. See Appendix A.5 for illustrative examples. πŸ“š


2.6. Label Set Field 🌸

The Label Set Field gets used inside the Available Labels Field or the Shared Backup Labels Field, which are defined in Sections 2.4 and 2.5, respectively. It's also used inside SIMPLE_LABEL, LABEL_RANGE, or SIMPLE_LABEL & CHANNEL_COUNT, which are defined in Sections 2.2.1, 2.2.3, and 2.2.4, respectively 🧚

Here's the general format for a label set 🫢 It uses the Action concept from [RFC3471], plus an extra Action that defines a "bitmap" type of label set. Labels are variable in length. The Action-specific fields are defined in Sections 2.6.1, 2.6.2, and 2.6.3.

      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|    Num Labels = N       |           Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Base Label                           |
     |                             . . .                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      (Action-specific fields)                 |
     |                              . . . .                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Action: 🎯

  • 0 - Inclusive List
  • 1 - Exclusive List
  • 2 - Inclusive Range
  • 3 - Exclusive Range
  • 4 - Bitmap Set

Num Labels is generally the number of labels πŸ”’ but it means something specific depending on the Action value. Check Sections 2.6.1, 2.6.2, and 2.6.3 for the details. Num Labels is a 12-bit integer.

Length is the length in bytes of the entire Label Set Field πŸ“


2.6.1. Inclusive/Exclusive Label Lists πŸ“‹

For inclusive/exclusive lists (Action = 0 or 1), the wavelength set format is:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 or 1 | Num Labels = 2        |          Length               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Label #1                              |
     |                            . . .                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Label #N                              |
     |                            . . .                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Label #1 is the first label to be included or excluded, and Label #N is the last one πŸ’« Num Labels MUST match with N. 🚨


2.6.2. Inclusive/Exclusive Label Ranges 🌈

For inclusive/exclusive ranges (Action = 2 or 3), the label set format is:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |2 or 3 | Num Labels          |               Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Start Label                                |
     |                       . . .                                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     End Label                                 |
     |                       . . .                                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Start Label is the first label in the range to be included or excluded, and End Label is the last label in that same range ✨ Num Labels MUST be two. πŸ™Œ

2.6.3. Bitmap Label Set ✨

okay bestie, for bitmap sets (Action = 4) the label set format 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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  4    |   Num Labels          |             Length            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         Base Label                            |
 |                            . . .                              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Bitmap Word #1 (Lowest numerical labels)                   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 :                                                               :
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Bitmap Word #N (Highest numerical labels)                  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

so Num Labels tells us how many labels the bitmap covers πŸ’– each bit is one label, and a 1 or a 0 says whether that label is in the set or not πŸŽ€ bit position zero is the lowest label and matches the base label, and every bit after it is the next label up 🌸

the bitmap is always padded out to a full multiple of 32 bits, so the whole field is a multiple of four bytes ✨ bits that don't represent labels SHOULD be set to zero and MUST be ignored πŸ’… (that's the whole vibe: be tidy, and don't read the padding like it means something πŸ™ˆ)


3. Security Considerations πŸ”

okay so this document only defines protocol-independent encodings for WSON information, and it doesn't introduce any security issues on its own πŸ’œ

BUT 😭 other documents that use these encodings inside protocol extensions need to think about the risks of inspection, interception, modification, or spoofing of this information. the expectation is that those documents will describe the security measures they need to keep things protected πŸ›‘οΈ for a general discussion of security in GMPLS networks, go read [RFC5920] πŸ“š this part is seriously important, bestie, so don't skip it πŸ‘‘


4. IANA Considerations 🌈

this document only provides general, protocol-independent information encodings 🧚 there's no IANA allocation request for the information elements defined here πŸ“ any IANA allocation requests will show up in protocol-specific documents that build on these encodings ✨


5. References πŸ“–

5.1. Normative References

[G.694.1]  ITU-T, "Spectral grids for WDM applications: DWDM
           frequency grid", ITU-T Recommendation G.694.1, February
           2012.

[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>.

[RFC2863]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group
           MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000,
           <http://www.rfc-editor.org/info/rfc2863>.

[RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
           and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
           Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
           <http://www.rfc-editor.org/info/rfc3209>.

[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>.

[RFC4202]  Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
           Extensions in Support of Generalized Multi-Protocol Label
           Switching (GMPLS)", RFC 4202, DOI 10.17487/RFC4202,
           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, DOI 10.17487/RFC4203, October 2005,
           <http://www.rfc-editor.org/info/rfc4203>.

[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>.

[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>.

5.2. Informative References

[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>.

[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>.

[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>.

[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, Volume 1, Issue 1,
           pp. 187-195, June 2009.

Appendix A. Encoding Examples πŸŽ€

this appendix has examples of the general encoding extensions applied to a few simple ROADM network elements and links πŸ§šβ€β™€οΈ

say we want to describe a set of input ports with link local identifiers numbered 3 through 42 πŸ’« in the Link Set Field we set Action = 1 to mean an inclusive range, Dir = 1 to mean input links, and Format = 0 to mean link local identifiers πŸ¦‹ so we end up with this:

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Action=1     |0 1|0 0 0 0 0 0|             Length = 12       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                     Link Local Identifier = #3                |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                     Link Local Identifier = #42               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A.2. Label Set Field 🌸

in this example we use a 40-channel C-Band Dense Wavelength Division Multiplexing (DWDM) system 🌈 the spacing is 100 GHz, the lowest frequency is 192.0 THz (1561.4 nm), and the highest is 195.9 THz (1530.3 nm) πŸ’œ those frequencies line up with n = -11 and n = 28 ✨ now say these channels are available:

Frequency (THz)       n Value      bitmap position
--------------------------------------------------
   192.0             -11                  0
   192.5              -6                  5
   193.1               0                 11
   193.9               8                 19
   194.0               9                 20
   195.2              21                 32
   195.8              27                 38

using the label format defined in [RFC6205], with the Grid value set to indicate an ITU-T A/2 [G.694.1] DWDM grid and C.S. set to indicate 100 GHz, this lambda bitmap set gets 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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  4    | Num Labels = 40       |    Length = 16 bytes          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Grid |  C.S. |      Reserved   | n  for lowest frequency = -11 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |1 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |1 0 0 0 0 0 1 0|   Not used in 40 Channel system (all zeros)   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

and to encode this same set as an inclusive list, we'd have:

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  0    | Num Labels = 7        |    Length = 32 bytes          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Grid |  C.S. |      Reserved   | n  for lowest frequency = -11 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Grid |  C.S. |      Reserved   | n  for lowest frequency = -6  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Grid |  C.S. |      Reserved   | n  for lowest frequency = -0  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Grid |  C.S. |      Reserved   | n  for lowest frequency = 8   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Grid |  C.S. |      Reserved   | n  for lowest frequency = 9   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Grid |  C.S. |      Reserved   | n  for lowest frequency = 21  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Grid |  C.S. |      Reserved   | n  for lowest frequency = 27  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A.3. Connectivity Matrix ✨

okay so picture a typical 2-degree 40-channel ROADM πŸ¦‹ besides its two line side ports, it has 80 add ports and 80 drop ports. the figure below shows how a typical 2-degree ROADM system that works with bidirectional fiber pairs is totally asymmetrical πŸ’… it's really two unidirectional ROADM subsystems stuck together.

                     (Tributary) Ports #3-#42
                 Input added to    Output dropped from
                 West Line Output    East Line Input
                       vvvvv          ^^^^^
                      | |||.|        | |||.|
                +-----| |||.|--------| |||.|------+
                |    +----------------------+     |
                |    |                      |     |
    Output      |    | Unidirectional ROADM |     |    Input
   -----------------+    |                      |     +--------------
   <=====================|                      |===================<
   -----------------+    +----------------------+     +--------------
                |                                 |
    Port #1     |                                 |   Port #2
(West Line Side) |                                 |(East Line Side)
   -----------------+    +----------------------+     +--------------
   >=====================|                      |===================>
   -----------------+    | Unidirectional ROADM |     +--------------
          Input     |    |                      |     |    Output
                |    |              _       |     |
                |    +----------------------+     |
                +-----| |||.|--------| |||.|------+
                      | |||.|        | |||.|
                       vvvvv          ^^^^^
                 (Tributary) Ports #43-#82
            Output dropped from    Input added to
            West Line Input      East Line Output

okay so looking at the figure 🌸 the input side of ports #3-#42 (add ports) can only hook up to the output on port #1, while the input side of port #2 (line side) can only reach the output on ports #3-#42 (drop) and the output on port #1 (pass through) 🫢 same energy the other way around: the input on ports #43-#82 can only reach the output on port #2 (line), and the input on port #1 can only reach the output on ports #43-#82 (drop) or port #2 (pass through) πŸ’€ we can write this potential connectivity matrix out like this, and it only uses 29 32-bit words ✨ literally so efficient, bestie πŸ‘‘

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Conn = 1   |    MatrixID   |      Reserved                 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       Note: adds to line
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Action=1     |0 1|0 0 0 0 0 0|          Length = 12          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Link Local Identifier = #3                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Link Local Identifier = #42               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Action=0     |1 0|0 0 0 0 0 0|          Length = 8           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Link Local Identifier = #1                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Note: line to drops
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Action=0     |0 1|0 0 0 0 0 0|          Length = 8           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Link Local Identifier = #2                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Action=1     |1 0|0 0 0 0 0 0|          Length = 12          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Link Local Identifier = #3                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Link Local Identifier = #42               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Note: line to line
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Action=0     |0 1|0 0 0 0 0 0|          Length = 8           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Link Local Identifier = #2                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Action=0     |1 0|0 0 0 0 0 0|          Length = 8           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Link Local Identifier = #1                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                            Note: adds to line
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Action=1     |0 1|0 0 0 0 0 0|          Length = 12          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Link Local Identifier = #43               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Link Local Identifier = #82               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Action=0     |1 0|0 0 0 0 0 0|          Length = 8           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Link Local Identifier = #2                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Note: line to drops
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Action=0     |0 1|0 0 0 0 0 0||          Length = 8          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Link Local Identifier = #1                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Action=1     |1 0|0 0 0 0 0 0|          Length = 12          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Link Local Identifier = #43               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Link Local Identifier = #82               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Note: line to line
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Action=0     |0 1|0 0 0 0 0 0|          Length = 8           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Link Local Identifier = #1                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Action=0     |1 0|0 0 0 0 0 0|          Length = 8           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Link Local Identifier = #2                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A.4. Connectivity Matrix with Bidirectional Symmetry

okay so bestie, if you can renumber the ports from the previous example like in this next figure πŸ¦‹, then we get to use the bidirectional symmetry and encode the connectivity matrix bidirectionally. ngl it's so clean πŸ’… Also, heads up: we set dir=bidirectional in the Link Set Fields πŸŽ€

                             (Tributary)
                  Ports #3-42         Ports #43-82
                  West Line Output    East Line Input
                        vvvvv          ^^^^^
                       | |||.|        | |||.|
                 +-----| |||.|--------| |||.|------+
                 |    +----------------------+     |
                 |    |                      |     |
     Output      |    | Unidirectional ROADM |     |    Input
-----------------+    |                      |     +--------------
<=====================|                      |===================<
-----------------+    +----------------------+     +--------------
                 |                                 |
     Port #1     |                                 |   Port #2
(West Line Side) |                                 |(East Line Side)
-----------------+    +----------------------+     +--------------
>=====================|                      |===================>
-----------------+    | Unidirectional ROADM |     +--------------
     Input     |    |                      |     |    Output
                 |    |              _       |     |
                 |    +----------------------+     |
                 +-----| |||.|--------| |||.|------+
                       | |||.|        | |||.|
                        vvvvv          ^^^^^
                  Ports #3-#42            Ports #43-82
             Output dropped from    Input added to
             West Line Input      East Line Output
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Conn = 1   |    MatrixID   |      Reserved                 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                Note: Add/Drop #3-42 to Line side #1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Action=1     |0 0|0 0 0 0 0 0|          Length = 12          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Link Local Identifier = #3                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Link Local Identifier = #42               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Action=0     |0 0|0 0 0 0 0 0|          Length = 8           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Link Local Identifier = #1                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Note: line #2 to add/drops #43-82
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Action=0     |0 0|0 0 0 0 0 0|          Length = 8           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Link Local Identifier = #2                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Action=1     |0 0|0 0 0 0 0 0|          Length = 12          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Link Local Identifier = #43               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Link Local Identifier = #82               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Note: line to line
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Action=0     |0 0|0 0 0 0 0 0|          Length = 8           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Link Local Identifier = #1                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Action=0     |0 0|0 0 0 0 0 0|          Length = 8           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Link Local Identifier = #2                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A.5. Priority Flags in Available/Shared Backup Labels

so if you wanna make one set of labels (that's Label Set Field #1) available only for the highest priority level (Priority Level 0), while letting another set (Label Set Field #2) be available to every priority level, this encoding is how you say it 🌸✨

   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |1 0 0 0 0 0 0 0|              Reserved                         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                     Label Set Field #1                        |
  :                                                               :
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |1 1 1 1 1 1 1 1|              Reserved                         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                     Label Set Field #2                        |
  :                                                               :
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Contributors

Huge shoutout to the people who helped make this happen 🫢🌈

   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

   Rao Rajan
   Infinera
   EMail: rrao@infinera.com

   Giovanni Martinelli
   Cisco
   EMail: giomarti@cisco.com

   Remi Theillaud
   Marben
   EMail: remi.theillaud@marben-products.com

Authors' Addresses

and last but absolutely not least, here are the people who wrote this thing πŸ’–πŸ‘‘

   Greg M. Bernstein (editor)
   Grotto Networking
   Fremont, California
   United States
   Phone: (510) 573-2237
   EMail: gregb@grotto-networking.com


   Young Lee (editor)
   Huawei Technologies
   1700 Alma Drive, Suite 100
   Plano, TX 75075
   United States
   Phone: (972) 509-5599 (x2240)
   EMail: ylee@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