RFC 7579
General Network Element Constraint Encoding for GMPLS-Controlled Networks
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 Notice
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. π
this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as 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 fixed1- 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
0xFFis 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 Bdir=outputIn 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 Bdir=bidirectionalIn 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
0xFFto 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.
2.2.5. LINK_LABEL_EXCLUSIVITY β
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.
2.3. Link Set Field πβ¨
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 to0x01(Inclusive Range) when the identifier for unnumbered link is used. π
Dir: Directionality of the link set (2 bits) β‘οΈ
0- bidirectional1- input2- 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 List1- Exclusive List2- Inclusive Range3- Exclusive Range4- 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 π§ββοΈ
A.1. Link Set Field π
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
- ietf: rfc7579 2015-06
- π girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms