RFC 7579

Internet Engineering Task Force (IETF) G. Bernstein, Ed.
Request for Comments: 7579 Grotto Networking
Category: Standards Track Y. Lee, Ed.
ISSN: 2070-1721 D. Li
Huawei
W. Imajuku
NTT
J. Han
Huawei
June 2015 General Network Element Constraint Encoding
for GMPLS-Controlled Networks
Abstract
Generalized Multiprotocol Label Switching (GMPLS) can be used to
control a wide variety of technologies. In some of these
technologies, network elements and links may impose additional
routing constraints such as asymmetric switch connectivity, non-local
label assignment, and label range limitations on links.
This document provides efficient, protocol-agnostic encodings for
general information elements representing connectivity and label
constraints as well as label availability. It is intended that
protocol-specific documents will reference this memo to describe how
information is carried for specific uses.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7579.

1. Introduction
Some data-plane technologies that wish to make use of a GMPLS control
plane contain additional constraints on switching capability and
label assignment. In addition, some of these technologies must
perform non-local label assignment based on the nature of the
technology, e.g., wavelength continuity constraint in Wavelength
Switched Optical Networks (WSONs) [RFC6163]. Such constraints can
lead to the requirement for link-by-link label availability in path
computation and label assignment.
This document provides efficient encodings of information needed by
the routing and label assignment process in technologies such as WSON
and are potentially applicable to a wider range of technologies.
Such encodings can be used to extend GMPLS signaling and routing
protocols. In addition, these encodings could be used by other
mechanisms to convey this same information to a path computation
element (PCE).
1.1. Node Switching Asymmetry Constraints
For some network elements, the ability of a signal or packet on a
particular input port to reach a particular output port may be
limited. Additionally, in some network elements (e.g., a simple
multiplexer), the connectivity between some input and output ports
may be fixed. To take into account such constraints during path
computation, we model this aspect of a network element via a
connectivity matrix.
The connectivity matrix (ConnectivityMatrix) represents either the
potential connectivity matrix for asymmetric switches or fixed
connectivity for an asymmetric device such as a multiplexer. Note
that this matrix does not represent any particular internal blocking
behavior but indicates which input ports and labels (e.g.,
wavelengths) could possibly be connected to a particular output port
and label pair. Representing internal state-dependent blocking for a
node is beyond the scope of this document and, due to its highly
implementation-dependent nature, would most likely not be subject to
standardization in the future. The connectivity matrix is a
conceptual M*m by N*n matrix where M represents the number of input
ports (each with m labels) and N the number of output ports (each
with n labels).

1.2. Non-local Label Assignment Constraints
If the nature of the equipment involved in a network results in a
requirement for non-local label assignment, we can have constraints
based on limits imposed by the ports themselves and those that are
implied by the current label usage. Note that constraints such as
these only become important when label assignment has a non-local
character. For example, in MPLS, an LSR may have a limited range of
labels available for use on an output port and a set of labels
already in use on that port; these are therefore unavailable for use.
This information, however, does not need to be shared unless there is
some limitation on the LSR's label swapping ability. For example, if
a Time Division Multiplexer (TDM) node lacks the ability to perform
time-slot interchange or a WSON lacks the ability to perform
wavelength conversion, then the label assignment process is not local
to a single node. In this case, it may be advantageous to share the
label assignment constraint information for use in path computation.
Port label restrictions (PortLabelRestriction) model the label
restrictions that the network element (node) and link may impose on a
port. These restrictions tell us what labels may or may not be used
on a link and are intended to be relatively static. More dynamic
information is contained in the information on available labels.
Port label restrictions are specified relative to the port in general
or to a specific connectivity matrix for increased modeling
flexibility. [Switch] gives an example where both switch and fixed
connectivity matrices are used and both types of constraints occur 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 provides encodings for the information elements defined
in [RFC7446] that have applicability to WSON. The encodings are
designed to be suitable for use in the GMPLS routing protocols OSPF
[RFC4203] and IS-IS [RFC5307] and in the PCE Communication Protocol
(PCEP) [RFC5440]. Note that the information distributed in [RFC4203]
and [RFC5307] is arranged via the nesting of sub-TLVs within TLVs;
this document defines elements to be used within such constructs.
Specific constructs of sub-TLVs and the nesting of sub-TLVs of the
information element defined by this document will be defined in the
respective protocol enhancement documents.

2.1. Connectivity Matrix Field
The Connectivity Matrix Field represents how input ports are
connected to output ports for network elements. The switch and fixed
connectivity matrices can be compactly represented in terms of a
minimal list of input and output port set pairs that have mutual
connectivity. As described in [Switch], such a minimal list
representation leads naturally to a graph representation for path
computation purposes; this representation involves the fewest
additional nodes and links.
The Connectivity Matrix Field is uniquely identified only by the
advertising node. There may be more than one Connectivity Matrix
Field associated with a node as a node can partition the switch
matrix into several sub-matrices. This partitioning is primarily to
limit the size of any individual information element used to
represent the matrix and to enable incremental updates. When the
matrix is partitioned into sub-matrices, each sub-matrix will be
mutually exclusive to one another in representing which ports/labels
are associated with each sub-matrix. This implies that two matrices
will not have the same {src port, src label, dst port, dst label}.
Each sub-matrix is identified via a different Matrix ID that MUST
represent a unique combination of {src port, src label, dst port, dst
label}.
A TLV encoding of this list of link set pairs 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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:
o 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.
o 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.
The 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. The use of the reserved value of 0xFF for the MatrixID
indicates that a 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.

1 - Inclusive Range
Indicates that the link set defines a range of links. It
contains two link identifiers. The first identifier indicates
the start of the range. The second identifier indicates the
end of the range. All links with numeric values between the
bounds are considered to be part of the set. A value of zero
in either position indicates that there is no bound on the
corresponding portion of the range. Note that the Action
field can be set to 0x01 (Inclusive Range) only 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, we think in terms of unidirectional and
bidirectional links. For example, label restrictions or
connectivity may be different for an input port than for its
"companion" output port, if one exists. Note that "interfaces"
such as those discussed in the Interfaces MIB [RFC2863] are
assumed to be bidirectional. This also applies to the links
advertised in various link state routing protocols.
Format: The format of the link identifier (6 bits)
0 - Link Local Identifier
Indicates that the links in the link set are identified by
link local identifiers. All link local identifiers are
supplied in the context of the advertising node.
1 - Local Interface IPv4 Address
Indicates that the links in the link set are identified by
Local Interface IPv4 Address.
2 - Local Interface IPv6 Address
Indicates that the links in the link 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 is dependent on the link format
The link identifier represents the port that is being described
either for connectivity or for label restrictions. This can be
the link local identifier of GMPLS routing [RFC4202], GMPLS OSPF
routing [RFC4203], and IS-IS GMPLS routing [RFC5307]. The use of
the link local identifier format can result in more compact
encodings when the assignments are done in a reasonable fashion.
2.4. Available Labels Field
The Available Labels Field consists of priority flags and a single
variable-length Label Set Field as follows:
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): A bitmap used to indicate which
priorities are being advertised. The bitmap is in ascending order,
with the leftmost bit representing priority level 0 (i.e., the
highest) and the rightmost bit representing priority level 7 (i.e.,
the lowest). A bit MUST be set (1) corresponding to each priority
represented in the sub-TLV and MUST NOT be set (0) when the
corresponding priority is not 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 indicates the availability of the labels for use in
Label Switched Path (LSP) setup and preemption as described in
[RFC3209].

When a label is advertised as available for priorities 0, 1, ... M,
it may be used by any LSP of priority N <= M. When a label is in use
by an LSP of priority M, it may be used by an LSP of priority N < M
if LSP preemption is supported.
When a label was initially advertised as available for priorities 0,
1, ... M and once a label is used for an LSP at a priority, say N
(N<=M), then this label is 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 consists of priority flags and a
single variable-length Label Set Field as follows:
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): A bitmap used to indicate which
priorities are being advertised. The bitmap is in ascending order,
with the leftmost bit representing priority level 0 (i.e., the
highest) and the rightmost bit representing priority level 7 (i.e.,
the lowest). A bit MUST be set (1) corresponding to each priority
represented in the sub-TLV and MUST NOT be set (0) when the
corresponding priority is not 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 specified in 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.3. Bitmap Label Set
For bitmap sets (Action = 4), 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | Num Labels | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Base Label |
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bitmap Word #1 (Lowest numerical labels) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bitmap Word #N (Highest numerical labels) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this case, Num Labels tells us the number of labels represented by
the bitmap. Each bit in the bitmap represents a particular label
with a value of 1/0 indicating whether or not the label is in the
set. Bit position zero represents the lowest label and corresponds
to the base label, while each succeeding bit position represents the
next label logically above the previous.
The size of the bitmap is Num Labels bits, but the bitmap is padded
out to a full multiple of 32 bits so that the field is a multiple of
four bytes. Bits that do not represent labels SHOULD be set to zero
and MUST be ignored.
3. Security Considerations
This document defines protocol-independent encodings for WSON
information and does not introduce any security issues.
However, other documents that make use of these encodings within
protocol extensions need to consider the issues and risks associated
with inspection, interception, modification, or spoofing of any of
this information. It is expected that any such documents will
describe the necessary security measures to provide adequate
protection. A general discussion on security in GMPLS networks can
be found in [RFC5920].