RFC 7176
Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS
2.3. Sub-TLVs of the Router Capability and MT-Capability TLVs
The Router Capability TLV is specified in [RFC4971] and the MT- Capability TLV in [RFC6329]. All of the following sub-sections specify sub-TLVs that can be carried in the Router Capability TLV (#242) and the MT-Capability TLV (#144) with the same sub-TLV number for both TLVs. These TLVs are in turn carried only by LSPs.
2.3.1. TRILL Version Sub-TLV
The TRILL Version (TRILL-VER) sub-TLV indicates the maximum version of the TRILL standard supported and the support of optional capabilities by the originating IS. By implication, lower versions are also supported. If this sub-TLV is missing, it is assumed that the originating IS only supports the base version (version zero) of the protocol [RFC6325], and no optional capabilities indicated by this sub-TLV are supported. +-+-+-+-+-+-+-+-+ | Type | (1 byte) +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+ | Max-version | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ | Capabilities and Header Flags Supported | (4 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+ 0 1 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 0 1 o Type: Router Capability sub-TLV type, set to 13 (TRILL-VER). o Length: 5. o Max-version: A one-byte unsigned integer set to the maximum version supported. o Capabilities and Header Flags Supported: A bit vector of 32 bits numbered 0 through 31 in network order. Bits 14 through 31 indicate that the corresponding TRILL Header extended flags [RFC7179] are supported. Bits 0 through 13 are reserved to indicate support of optional capabilities. A one bit indicates that the originating IS supports the flag or capability. For example, support of multi-level TRILL IS-IS [MultiLevel]. Bits in this field MUST be set to zero except as permitted for a capability being advertised or an extended header flag supported. This sub-TLV, if present in a Router Capability TLV, MUST occur in the LSP number zero for the originating IS. If found in a Router Capability TLV in other fragments, it is ignored. If there is more than one occurrence in LSP number zero, the minimum of the supported versions is assumed to be correct, and an extended header flag or capability is assumed to be supported only if indicated by all occurrences. The flags and capabilities for which support can be indicated in this sub-TLV are disjoint from those in the PORT-TRILL- VER sub-TLV (Section 2.2.4) so they cannot conflict. However, the
TRILL version is the same as that in the PORT-TRILL-VER sub-TLV, and an IS that is adjacent to the originating IS of TRILL-VER sub-TLV(s) uses the TRILL version it received in PORT-TRILL-VER sub-TLV(s) in preference to that received in TRILL-VER sub-TLV(s). For multi-topology-aware TRILL Switches, the TRILL version and capabilities announced for the base topology are assumed to apply to all topologies for which a separate TRILL version announcement does not occur in an MT-Capability TLV. Such announcements for non-zero topologies need not occur in fragment zero.2.3.2. Nickname Sub-TLV
The Nickname (NICKNAME) Router Capability sub-TLV carries information about the nicknames of the originating IS, along with information about its priority to hold those nicknames and the priority for each nickname to be a tree root as specified in [RFC6325], Section 3.7.3. Multiple instances of this sub-TLV may occur. +-+-+-+-+-+-+-+-+ |Type = NICKNAME| (1 byte) +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NICKNAME RECORDS (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NICKNAME RECORDS (2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ................. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NICKNAME RECORDS (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where each nickname record is of the form: +-+-+-+-+-+-+-+-+ | Nickname.Pri | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tree Root Priority | (2 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nickname | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: Router Capability and MT-Capability sub-TLV type, set to 6 (NICKNAME). o Length: 5*n, where n is the number of nickname records present.
o Nickname.Pri: An 8-bit unsigned integer priority to hold a
nickname as specified in Section 3.7.3 of [RFC6325].
o Tree Root Priority: This is an unsigned 16-bit integer priority to
be a tree root as specified in Section 4.5 of [RFC6325].
o Nickname: This is an unsigned 16-bit integer as specified in
Section 3.7 of [RFC6325].
2.3.3. Trees Sub-TLV
Each IS providing TRILL service uses the TREES sub-TLV to announce
three numbers related to the computation of distribution trees as
specified in Section 4.5 of [RFC6325]. Its format is as follows:
+-+-+-+-+-+-+-+-+
|Type = TREES | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of trees to compute | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum trees able to compute | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of trees to use | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Router Capability and MT-Capability sub-TLV type, set to 7
(TREES).
o Length: 6.
o Number of trees to compute: An unsigned 16-bit integer as
specified in Section 4.5 of [RFC6325].
o Maximum trees able to compute: An unsigned 16-bit integer as
specified in Section 4.5 of [RFC6325].
o Number of trees to use: An unsigned 16-bit integer as specified in
Section 4.5 of [RFC6325].
2.3.4. Tree Identifiers Sub-TLV
The Tree Identifiers (TREE-RT-IDs) sub-TLV is an ordered list of
nicknames. When originated by the IS that has the highest priority
to be a tree root, it lists the distribution trees that the other ISs
are required to compute as specified in Section 4.5 of [RFC6325]. If
this information is spread across multiple sub-TLVs, the starting
tree number is used to allow the ordered lists to be correctly
concatenated. The sub-TLV format is as follows:
+-+-+-+-+-+-+-+-+
|Type=TREE-RT-IDs| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Starting Tree Number | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname (K-th root) | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname (K+1 - th root) | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname (...) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Router Capability and MT-Capability sub-TLV type, set to 8
(TREE-RT-IDs).
o Length: 2 + 2*n, where n is the number of nicknames listed.
o Starting Tree Number: This identifies the starting tree number of
the nicknames that are trees for the domain. This is set to 1 for
the sub-TLV containing the first list. Other Tree-Identifiers
sub-TLVs will have the number of the starting list they contain.
In the event the same tree identifier can be computed from two
such sub-TLVs and they are different, then it is assumed that this
is a transient condition that will get cleared. During this
transient time, such a tree SHOULD NOT be computed unless such
computation is indicated by all relevant sub-TLVs present.
o Nickname: The nickname at which a distribution tree is rooted.
2.3.5. Trees Used Identifiers Sub-TLV
This Router Capability sub-TLV has the same structure as the Tree
Identifiers sub-TLV specified in Section 2.3.4. The only difference
is that its sub-TLV type is set to 9 (TREE-USE-IDs), and the trees
listed are those that the originating IS wishes to use as specified
in [RFC6325], Section 4.5.
2.3.6. Interested VLANs and Spanning Tree Roots Sub-TLV
The value of this sub-TLV consists of a VLAN range and information in common to all of the VLANs in the range for the originating IS. This information consists of flags, a variable length list of spanning tree root bridge IDs, and an Appointed Forwarder status lost counter, all as specified in the sections of [RFC6325] listed with the respective information items below. In the set of LSPs originated by an IS, the union of the VLAN ranges in all occurrences of this sub-TLV MUST be the set of VLANs for which the originating IS is Appointed Forwarder on at least one port, and the VLAN ranges in multiple VLANs sub-TLVs for an IS MUST NOT overlap unless the information provided about a VLAN is the same in every instance. However, as a transient state, these conditions may be violated. If a VLAN is not listed in any INT-VLAN sub-TLV for an IS, that IS is assumed to be uninterested in receiving traffic for that VLAN. If a VLAN appears in more than one INT-VLAN sub-TLV for an IS with different information in the different instances, the following apply: - If those sub-TLVs provide different nicknames, it is unspecified which nickname takes precedence. - The largest Appointed Forwarder status lost counter, using serial number arithmetic [RFC1982], is used. - The originating IS is assumed to be attached to a multicast IPv4 router for that VLAN if any of the INT-VLAN sub-TLVs assert that it is so connected and similarly for IPv6 multicast router attachment. - The root bridge lists from all of the instances of the VLAN for the originating IS are merged. To minimize such occurrences, wherever possible, an implementation SHOULD advertise the update to an interested VLAN and Spanning Tree Roots sub-TLV in the same LSP fragment as the advertisement that it replaces. Where this is not possible, the two affected LSP fragments should be flooded as an atomic action. An IS that receives an update to an existing interested VLAN and Spanning Tree Roots sub-TLV can minimize the potential disruption associated with the update by employing a hold-down timer prior to processing the update so as to allow for the receipt of multiple LSP fragments associated with the same update prior to beginning processing.
The sub-TLV layout is as follows:
+-+-+-+-+-+-+-+-+
|Type = INT-VLAN| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+
| Interested VLANS | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+
| Appointed Forwarder Status Lost Counter | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+
| Root Bridges | (6*n bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
o Type: Router Capability and MT-Capability sub-TLV type, set to 10
(INT-VLAN).
o Length: 10 + 6*n, where n is the number of root bridge IDs.
o Nickname: As specified in [RFC6325], Section 4.2.4.4, this field
may be used to associate a nickname held by the originating IS
with the VLAN range indicated. When not used in this way, it is
set to zero.
o Interested VLANS: The Interested VLANs field is formatted as shown
below.
0 1 2 3 4 - 15 16 - 19 20 - 31
+----+----+----+----+------------+----------+------------+
| M4 | M6 | R | R | VLAN.start | RESV | VLAN.end |
+----+----+----+----+------------+----------+------------+
- M4, M6: These bits indicate, respectively, that there is an
IPv4 or IPv6 multicast router on a link for which the
originating IS is Appointed Forwarder for every VLAN in the
indicated range as specified in [RFC6325], Section 4.2.4.4,
item 5.1.
- R, RESV: These reserved bits MUST be sent as zero and are
ignored on receipt.
- VLAN.start and VLAN.end: This VLAN ID range is inclusive.
Setting both VLAN.start and VLAN.end to the same value
indicates a range of one VLAN ID. If VLAN.start is not equal
to VLAN.end and VLAN.start is 0x000, the sub-TLV is interpreted
as if VLAN.start was 0x001. If VLAN.start is not equal to
VLAN.end and VLAN.end is 0xFFF, the sub-TLV is interpreted as
if VLAN.end was 0xFFE. If VLAN.end is less than VLAN.start,
the sub-TLV is ignored. If both VLAN.start and VLAN.end are
0x000 or both are 0xFFF, the sub-TLV is ignored. The values
0x000 or 0xFFF are not valid VLAN IDs, and a port cannot be
enabled for them.
o Appointed Forwarder Status Lost Counter: This is a count of how
many times a port that was Appointed Forwarder for the VLANs in
the range given has lost the status of being an Appointed
Forwarder for some port as discussed in Section 4.8.3 of
[RFC6325]. It is initialized to zero at an IS when the zeroth LSP
sequence number is initialized. No special action need be taken
at rollover; the counter just wraps around.
o Root Bridges: The list of zero or more spanning tree root bridge
IDs is the set of root bridge IDs seen for all ports for which the
IS is Appointed Forwarder for the VLANs in the specified range as
discussed in [RFC6325], Section 4.9.3.2. While, of course, at
most one spanning tree root could be seen on any particular port,
there may be multiple ports in the same VLANs connected to
different bridged LANs with different spanning tree roots.
An INT-VLAN sub-TLV asserts that the information provided (multicast
router attachment, Appointed Forwarder status lost counter, and root
bridges) is the same for all VLANs in the range specified. If this
is not the case, the range MUST be split into subranges meeting this
criteria. It is always safe to use sub-TLVs with a "range" of one
VLAN ID, but this may be too verbose.
2.3.7. VLAN Group Sub-TLV
The VLAN Group sub-TLV consists of two or more VLAN IDs as specified
in [RFC6325], Section 4.8.4. This sub-TLV indicates that shared VLAN
learning is occurring at the originating IS between the listed VLANs.
It is structured as follows:
+-+-+-+-+-+-+-+-+
|Type=VLAN-GROUP| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Primary VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Secondary VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| more Secondary VLAN IDs ... (2 bytes each)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Router Capability and MT-Capability sub-TLV type, set to 14
(VLAN-GROUP).
o Length: 4 + 2*n, where n is the number of secondary VLAN ID fields
beyond the first. n MAY be zero.
o RESV: a 4-bit field that MUST be sent as zero and ignored on
receipt.
o Primary VLAN ID: This identifies the primary VLAN ID.
o Secondary VLAN ID: This identifies a secondary VLAN in the VLAN
Group.
o more Secondary VLAN IDs: zero or more byte pairs, each with the
top 4 bits as a RESV field and the low 12 bits as a VLAN ID.
2.3.8. Interested Labels and Spanning Tree Roots Sub-TLV
An IS that can handle fine-grained labeling [RFC7172] announces its
fine-grained label connectivity and related information in the
Interested Labels and Spanning Tree Roots sub-TLV (INT-LABEL). It is
a variation of the Interested VLANs and Spanning Tree Roots sub-TLV
(INT-VLAN) and is structured as follows.
+-+-+-+-+-+-+-+-+
|Type=INT-LABEL | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+
| Interested Labels | (7 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+
| Appointed Forwarder Status Lost Counter | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
| Root Bridges | (6*n bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
o Type: Router Capability and MT-Capability sub-TLV type, set to 15
(INT-LABEL).
o Length: 11 + 6*n, where n is the number of root bridge IDs.
o Nickname: This field may be used to associate a nickname held by
the originating IS with the Interested Labels indicated. When not
used in this way, it is set to zero.
o Interested Labels: The Interested Labels field is seven bytes long
and formatted as shown below.
0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+
|M4|M6|BM| R| R| R| R| R| . .
+--+--+--+--+--+--+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label.start - 24 bits |
+--+--+--+--+--+--+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label.end or bit-map - 24 bits |
+--+--+--+--+--+--+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
- M4, M6: These bits indicate, respectively, that there is an
IPv4 or IPv6 multicast router on a link to which the
originating IS is Appointed Forwarder for the VLAN
corresponding to every label in the indicated range.
- BM: If the BM (bit-map) bit is zero, the last three bytes of
the Interested Labels is a Label.end label number. If the BM
bit is one, those bytes are a bit-map as described below.
- R: These reserved bits MUST be sent as zero and are ignored on
receipt.
- Label.start and Label.end: If the BM bit is zero, this fine-
grained label [RFC7172] ID range is inclusive. These fields
are treated as unsigned integers. Setting them both to the
same label ID value indicates a range of one label ID. If
Label.end is less than Label.start, the sub-TLV is ignored.
- Label.start and bit-map: If the BM bit is one, the fine-grained
labels that the IS is interested in are indicated by a 24-bit
bit-map. The interested labels are the Label.start number plus
the bit number of each one bit in the bit-map. So, if bit zero
of the bit-map is a one, the IS is interested in the label with
value Label.start, and if bit 23 of the bit-map is a one, the
IS is interested in the label with value Label.start+23.
o Appointed Forwarder Status Lost Counter: This is a count of how
many times a port that was Appointed Forwarder for a VLAN mapping
to the fine-grained label in the range or bit-map given has lost
the status of being an Appointed Forwarder as discussed in Section
4.8.3 of [RFC6325]. It is initialized to zero at an IS when the
zeroth LSP sequence number is initialized. No special action need
be taken at rollover; the counter just wraps around.
o Root Bridges: The list of zero or more spanning tree root bridge
IDs is the set of root bridge IDs seen for all ports for which the
IS is Appointed Forwarder for a VLAN mapping to the fine-grained
label in the specified range or bit-map. (See [RFC6325], Section
4.9.3.2.) While, of course, at most one spanning tree root could
be seen on any particular port, there may be multiple relevant
ports connected to different bridged LANs with different spanning
tree roots.
An INT-LABEL sub-TLV asserts that the information provided (multicast
router attachment, Appointed Forwarder status lost counter, and root
bridges) is the same for all labels specified. If this is not the
case, the sub-TLV MUST be split into subranges and/or separate bit
maps meeting this criteria. It is always safe to use sub-TLVs with a
"range" of one VLAN ID, but this may be too verbose.
2.3.9. RBridge Channel Protocols Sub-TLV
An IS announces the RBridge Channel protocols [RFC7178] it supports
through use of this sub-TLV.
+-+-+-+-+-+-+-+-+
|Type=RBCHANNELS| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
| Zero or more bit vectors (variable)
+-+-+-+-...
o Type: Router Capability and MT-Capability RBridge Channel
Protocols sub-TLV, set to 16 (RBCHANNELS).
o Length: variable.
o Bit Vectors: Zero or more byte-aligned bit vectors where a one bit
indicates support of a particular RBridge Channel protocol. Each
byte-aligned bit vector is formatted as follows:
| 0 1 2 3 4 5 6 7| 8 9 10 11 12 13 14 15|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Bit Vector Length | Bit Vector Offset |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| bits
+--+--+--...
The Bit Vector Length (BVL) is a seven-bit unsigned integer field
giving the number of bytes of bit vector. The Bit Vector Offset
(BVO) is a nine-bit unsigned integer field.
The bits in each bit vector are numbered in network order, the
high-order bit of the first byte of bits being bit 0 + 8*BVO, the
low-order bit of that byte being 7 + 8*BVO, the high order bit of
the second byte being 8 + 8*BVO, and so on for BVL bytes. A bit
vector of RBridge Channel protocols supported MUST NOT extend
beyond the end of the value in the sub-TLV in which it occurs. If
it does, it is ignored. If multiple byte-aligned bit vectors are
present in one such sub-TLV, their representations are contiguous,
the BVL field for the next starting immediately after the last
byte of bits for the previous bit vector. The one or more bit
vectors present MUST exactly fill the sub-TLV value. If there are
one or two bytes of value left over, they are ignored; if more
than two, an attempt is made to parse them as one or more bit
vectors.
If different bit vectors overlap in the protocol number space they
refer to and they have inconsistent bit values for a channel
protocol, support for the protocol is assumed if any of these bit
vectors has a 1 for that protocol.
The absence of any occurrences of this sub-TLV in the LSP for an
IS implies that the IS does not support the RBridge Channel
facility. To avoid wasted space, trailing bit vector zero bytes
SHOULD be eliminated by reducing BVL, any null bit vectors (ones
with BVL equal to zero) eliminated, and generally the most compact
encoding used. For example, support for channel protocols 1 and
32 could be encoded as
BVL = 5
BVO = 0
0b01000000
0b00000000
0b00000000
0b00000000
0b10000000
or as
BVL = 1
BVO = 0
0b01000000
BLV = 1
BVO = 4
0b1000000
The first takes 7 bytes while the second takes only 6; thus, the
second would be preferred.
In multi-topology-aware RBridges, RBridge Channel protocols for which support is announced in the base topology are assumed to be supported in all topologies for which there is no separate announcement for RBridge Channel protocol support.2.3.10. Affinity Sub-TLV
Association of an IS to a multi-destination distribution tree through a specific path is accomplished by using the Affinity sub-TLV. The announcement of an Affinity sub-TLV by RB1 with the nickname of RB2 as the first part of an Affinity Record in the sub-TLV value is a request by RB1 that all ISs in the campus connect RB2 as a child of RB1 when calculating any of the trees listed in that Affinity Record. Examples of use include [Affinity] and [Resilient]. The structure of the Affinity sub-TLV is shown below. +-+-+-+-+-+-+-+-+ | Type=AFFINITY | (1 byte) +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFFINITY RECORD 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFFINITY RECORD 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .......... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFFINITY RECORD N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where each AFFINITY RECORD is structured as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nickname | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Affinity Flags | (1 byte) +-+-+-+-+-+-+-+-+ |Number of trees| (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tree-num of 1st root | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tree-num of 2nd root | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .......... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tree-num of Nth root | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Router Capability and MT-Capability sub-TLV type, set to 17
(AFFINITY).
o Length: size of all Affinity Records included, where an Affinity
Record listing n tree roots is 4+2*n bytes long.
o Nickname: 16-bit nickname of the IS whose associations to the
multi-destination trees listed in the Affinity Record are through
the originating IS.
o Affinity Flags: 8 bits reserved for future needs to provide
additional information about the affinity being announced. MUST
be sent as zero and ignored on receipt.
o Number of trees: A one-byte unsigned integer giving the number of
trees for which affinity is being announced by this Affinity
Record.
o Tree-num of roots: The tree numbers of the distribution trees this
Affinity Record is announcing.
There is no need for a field giving the number of Affinity Records as
this can be determined by processing those records.
2.3.11 Label Group Sub-TLV
The Label Group sub-TLV consists of two or more fine-grained label
[RFC7172] IDs. This sub-TLV indicates that shared label MAC address
learning is occurring at the announcing IS between the listed labels.
It is structured as follows:
+-+-+-+-+-+-+-+-+
|Typ=LABEL-GROUP| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Primary Label ID | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secondary Label ID | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| more Secondary Label IDs ... (3 bytes each)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Router Capability and MT-Capability sub-TLV type, set to 18
(LABEL-GROUP).
o Length: 6 + 3*n, where n is the number of secondary VLAN ID fields
beyond the first. n MAY be zero.
o Primary Label ID: This identifies the primary Label ID.
o Secondary Label ID: This identifies a secondary Label ID in the
Label Group.
o more Secondary Label IDs: zero or more byte triples, each with a
Label ID.
2.4. MTU Sub-TLV for Extended Reachability and MT-ISN TLVs
The MTU sub-TLV is used to optionally announce the MTU of a link as
specified in [RFC6325], Section 4.2.4.4. It occurs within the
Extended Reachability (#22) and MT-ISN (Intermediate System
Neighbors) (#222) TLVs.
+-+-+-+-+-+-+-+-+
| Type = MTU | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
|F| RESV | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Extended Reachability and MT-ISN sub-TLV type, set to MTU
sub-TLV 28.
o Length: 3.
o F: Failed. This bit is a one if MTU testing failed on this link
at the required campus-wide MTU.
o RESV: 7 bits that MUST be sent as zero and ignored on receipt.
o MTU: This field is set to the largest successfully tested MTU size
for this link or zero if it has not been tested, as specified in
Section 4.3.2 of [RFC6325].
2.5. TRILL Neighbor TLV
The TRILL Neighbor TLV is used in TRILL broadcast link IIH PDUs (see
Section 4.1 below) in place of the IS Neighbor TLV, as specified in
Section 4.4.2.1 of [RFC6325] and in [RFC7177]. The structure of the
TRILL Neighbor TLV is as follows:
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
|S|L|R| SIZE | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor RECORDS (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The information present for each neighbor is as follows:
+-+-+-+-+-+-+-+-+
|F|O| RESV | (1 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+
| SNPA (MAC Address) | (SIZE bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+
o Type: TLV type, set to TRILL Neighbor TLV 145.
o Length: 1 + (SIZE+3)*n, where n is the number of neighbor records,
which may be zero.
o S: Smallest flag. If this bit is a one, then the list of
neighbors includes the neighbor with the smallest MAC address
considered as an unsigned integer.
o L: Largest flag. If this bit is a one, then the list of neighbors
includes the neighbor with the largest MAC address considered as
an unsigned integer.
o R, RESV: These bits are reserved and MUST be sent as zero and
ignored on receipt.
o SIZE: The SNPA size as an unsigned integer in bytes except that 6
is encoded as zero. An actual size of zero is meaningless and
cannot be encoded. The meaning of the value 6 in this field is
reserved, and TRILL Neighbor TLVs received with a SIZE of 6 are
ignored. The SIZE is inherent to the technology of a link and is
fixed for all TRILL Neighbor TLVs on that link but may vary
between different links in the campus if those links are different
technologies, for example, 6 for EUI-48 SNPAs or 8 for EUI-64
SNPAs [RFC7042]. (The SNPA size on the various links in a TRILL
campus is independent of the System ID size.)
o F: Failed. This bit is a one if MTU testing to this neighbor
failed at the required campus-wide MTU (see [RFC6325], Section
4.3.1).
o O: OOMF. This bit is a one if the IS sending the enclosing TRILL
Neighbor TLV is willing to offer the Overload Originated Multi-
destination Frame (OOMF) service [RFC7180] to the IS whose port
has the SNPA in the enclosing Neighbor RECORD.
o MTU: This field is set to the largest successfully tested MTU size
for this neighbor or to zero if it has not been tested.
o SNPA (MAC Address): Subnetwork Point of Attachment of the
neighbor.
As specified in [RFC7177] and Section 4.4.2.1 of [RFC6325], all MAC
addresses may fit into one TLV, in which case both the S and L flags
would be set to one in that TLV. If the MAC addresses don't fit into
one TLV, the highest MAC address in a TRILL Neighbor TLV with the L
flag zero MUST also appear as a MAC address in some other TRILL
Neighbor TLV (possibly in a different TRILL IIH PDU). Also, the
lowest MAC address in a TRILL Neighbor TLV with the S flag zero MUST
also appear in some other TRILL Neighbor TLV (possibly in a different
TRILL IIH PDU). If an IS believes it has no neighbors, it MUST send
a TRILL Neighbor TLV with an empty list of neighbor RECORDS, which
will have both the S and L bits on.
(page 33 continued on part 3)
