RFC 7176
Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS
Internet Engineering Task Force (IETF) D. Eastlake 3rd Request for Comments: 7176 Huawei Obsoletes: 6326 T. Senevirathne Category: Standards Track Cisco ISSN: 2070-1721 A. Ghanwani Dell D. Dutt Cumulus Networks A. Banerjee Insieme Networks May 2014 Transparent Interconnection of Lots of Links (TRILL) Use of IS-ISAbstract
The IETF Transparent Interconnection of Lots of Links (TRILL) protocol provides optimal pair-wise data frame forwarding without configuration in multi-hop networks with arbitrary topology and link technology; it also provides support for multipathing of both unicast and multicast traffic. This document specifies the data formats and code points for the IS-IS extensions to support TRILL. These data formats and code points may also be used by technologies other than TRILL. This document obsoletes RFC 6326. 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/rfc7176.
Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.Table of Contents
1. Introduction ....................................................3 1.1. Conventions Used in This Document ..........................4 2. TLV and Sub-TLV Extensions to IS-IS for TRILL ...................4 2.1. Group Address TLV ..........................................5 2.1.1. Group MAC Address Sub-TLV ...........................5 2.1.2. Group IPv4 Address Sub-TLV ..........................7 2.1.3. Group IPv6 Address Sub-TLV ..........................8 2.1.4. Group Labeled MAC Address Sub-TLV ...................9 2.1.5. Group Labeled IPv4 Address Sub-TLV .................10 2.1.6. Group Labeled IPv6 Address Sub-TLV .................11 2.2. Multi-Topology-Aware Port Capability Sub-TLVs .............12 2.2.1. Special VLANs and Flags Sub-TLV ....................12 2.2.2. Enabled-VLANs Sub-TLV ..............................13 2.2.3. Appointed Forwarders Sub-TLV .......................14 2.2.4. Port TRILL Version Sub-TLV .........................15 2.2.5. VLANs Appointed Sub-TLV ............................17 2.3. Sub-TLVs of the Router Capability and MT-Capability TLVs ..17 2.3.1. TRILL Version Sub-TLV ..............................18 2.3.2. Nickname Sub-TLV ...................................19 2.3.3. Trees Sub-TLV ......................................20 2.3.4. Tree Identifiers Sub-TLV ...........................20 2.3.5. Trees Used Identifiers Sub-TLV .....................21 2.3.6. Interested VLANs and Spanning Tree Roots Sub-TLV ...22 2.3.7. VLAN Group Sub-TLV .................................24 2.3.8. Interested Labels and Spanning Tree Roots Sub-TLV ..25 2.3.9. RBridge Channel Protocols Sub-TLV ..................27 2.3.10. Affinity Sub-TLV ..................................29 2.3.11. Label Group Sub-TLV ...............................30 2.4. MTU Sub-TLV for Extended Reachability and MT-ISN TLVs .....31 2.5. TRILL Neighbor TLV ........................................31 3. MTU PDUs .......................................................33
4. Use of Existing PDUs and TLVs ..................................35 4.1. TRILL IIH PDUs ............................................35 4.2. Area Address ..............................................35 4.3. Protocols Supported .......................................35 4.4. Link State PDUs (LSPs) ....................................35 4.5. Originating LSP Buffer Size ...............................36 5. IANA Considerations ............................................36 5.1. TLVs ......................................................36 5.2. Sub-TLVs ..................................................36 5.3. PDUs ......................................................38 5.4. Reserved and Capability Bits ..............................38 5.5. TRILL Neighbor Record Flags ...............................39 6. Security Considerations ........................................39 7. Changes from RFC 6326 ..........................................39 8. References .....................................................41 8.1. Normative References ......................................41 8.2. Informative References ....................................43 9. Acknowledgements ...............................................441. Introduction
The IETF Transparent Interconnection of Lots of Links (TRILL) protocol [RFC6325] [RFC7177] provides transparent forwarding in multi-hop networks with arbitrary topology and link technologies using a header with a hop count and link-state routing. TRILL provides optimal pair-wise forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. Intermediate Systems (ISs) implementing TRILL are called Routing Bridges (RBridges) or TRILL Switches. This document, in conjunction with [RFC6165], specifies the data formats and code points for the IS-IS [ISO-10589] [RFC1195] extensions to support TRILL. These data formats and code points may also be used by technologies other than TRILL. This document obsoletes [RFC6326], which generally corresponded to the base TRILL protocol [RFC6325]. There has been substantial development of TRILL since the publication of those documents. The main changes from [RFC6326] are summarized below, and a full list is given in Section 7. 1. Added multicast group announcements by IPv4 and IPv6 address. 2. Added facilities for announcing capabilities supported. 3. Added a tree affinity sub-TLV whereby ISs can request distribution tree association.
4. Added multi-topology support.
5. Added control-plane support for TRILL Data frame fine-grained
labels. This support is independent of the data-plane
representation.
6. Fixed the verified erratum [Err2869] in [RFC6326].
Changes herein to TLVs and sub-TLVs specified in [RFC6326] are
backward compatible.
1.1. Conventions Used in This Document
The terminology and acronyms defined in [RFC6325] are used herein
with the same meaning.
Additional acronyms and phrases used in this document are:
BVL - Bit Vector Length
BVO - Bit Vector Offset
IIH - IS-IS Hello
IS - Intermediate System. For this document, all relevant
intermediate systems are RBridges [RFC6325].
MAC - Media Access Control
MT - Multi-Topology
NLPID - Network Layer Protocol Identifier
SNPA - Subnetwork Point of Attachment (MAC Address)
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 [RFC2119].
2. TLV and Sub-TLV Extensions to IS-IS for TRILL
This section, in conjunction with [RFC6165], specifies the data
formats and code points for the TLVs and sub-TLVs for IS-IS to
support the IETF TRILL protocol. Information as to the number of
occurrences allowed, such as for a TLV in a PDU or set of PDUs or for
a sub-TLV in a TLV, is summarized in Section 5.
2.1. Group Address TLV
The Group Address (GADDR) TLV, IS-IS TLV type 142, is carried in an LSP PDU and carries sub-TLVs that in turn advertise multicast group listeners. The sub-TLVs that advertise listeners are specified below. The sub-TLVs under GADDR constitute a new series of sub-TLV types (see Section 5.2). GADDR has the following format: +-+-+-+-+-+-+-+-+ |Type=GADDR-TLV | (1 byte) +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | sub-TLVs... +-+-+-+-+-+-+-+-+-+-+-+-+-+-... o Type: TLV type, set to GADDR-TLV 142. o Length: variable depending on the sub-TLVs carried. o sub-TLVs: The Group Address TLV value consists of sub-TLVs formatted as described in [RFC5305].2.1.1. Group MAC Address Sub-TLV
The Group MAC Address (GMAC-ADDR) sub-TLV is sub-TLV type number 1 within the GADDR TLV. In TRILL, it is used to advertise multicast listeners by MAC address as specified in Section 4.5.5 of [RFC6325]. It has the following format:
+-+-+-+-+-+-+-+-+
|Type=GMAC-ADDR | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Topology-ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Num Group Recs | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each group record is of the following form with k=6:
+-+-+-+-+-+-+-+-+
| Num of Sources| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 1 Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 2 Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source M Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: GADDR sub-TLV type, set to 1 (GMAC-ADDR).
o Length: 5 + m + k*n = 5 + m + 6*n, where m is the number of group
records and n is the sum of the number of group and source
addresses.
o RESV: Reserved. 4-bit fields that MUST be sent as zero and
ignored on receipt.
o Topology-ID: This field carries a topology ID [RFC5120] or zero if
topologies are not in use.
o VLAN ID: This carries the 12-bit VLAN identifier for all
subsequent MAC addresses in this sub-TLV, or the value zero if no
VLAN is specified.
o Num Group Recs: A 1-byte unsigned integer that is the number of
group records in this sub-TLV.
o GROUP RECORDS: Each group record carries the number of sources.
If this field is zero, it indicates a listener for (*,G), that is,
a listener not restricted by source. It then has a 6-byte
(48-bit) multicast MAC address followed by 6-byte source MAC
addresses. If the sources do not fit in a single sub-TLV, the
same group address may be repeated with different source addresses
in another sub-TLV of another instance of the Group Address TLV.
The GMAC-ADDR sub-TLV is carried only within a GADDR TLV.
2.1.2. Group IPv4 Address Sub-TLV
The Group IPv4 Address (GIP-ADDR) sub-TLV is IS-IS sub-TLV type 2
within the GADDR TLV. It has the same format as the Group MAC
Address sub-TLV described in Section 2.1.1 except that k=4. The
fields are as follows:
o Type: sub-TLV type, set to 2 (GIP-ADDR).
o Length: 5 + m + k*n = 5 + m + 4*n, where m is the number of group
records and n is the sum of the number of group and source
addresses.
o Topology-ID: This field carries a topology ID [RFC5120] or zero if
topologies are not in use.
o RESV: Must be sent as zero on transmission and is ignored on
receipt.
o VLAN ID: This carries a 12-bit VLAN identifier that is valid for
all subsequent addresses in this sub-TLV, or the value zero if no
VLAN is specified.
o Num Group Recs: A 1-byte unsigned integer that is the number of
group records in this sub-TLV.
o GROUP RECORDS: Each group record carries the number of sources.
If this field is zero, it indicates a listener for (*,G), that is,
a listener not restricted by source. It then has a 4-byte
(32-bit) IPv4 Group Address followed by 4-byte source IPv4
addresses. If the number of sources do not fit in a single sub-
TLV, it is permitted to have the same group address repeated with
different source addresses in another sub-TLV of another instance
of the Group Address TLV.
The GIP-ADDR sub-TLV is carried only within a GADDR TLV.
2.1.3. Group IPv6 Address Sub-TLV
The Group IPv6 Address (GIPV6-ADDR) sub-TLV is IS-IS sub-TLV type 3
within the GADDR TLV. It has the same format as the Group MAC
Address sub-TLV described in Section 2.1.1 except that k=16. The
fields are as follows:
o Type: sub-TLV type, set to 3 (GIPV6-ADDR).
o Length: 5 + m + k*n = 5 + m + 16*n, where m is the number of group
records and n is the sum of the number of group and source
addresses.
o Topology-Id: This field carries a topology ID [RFC5120] or zero if
topologies are not in use.
o RESV: Must be sent as zero on transmission and is ignored on
receipt.
o VLAN ID: This carries a 12-bit VLAN identifier that is valid for
all subsequent addresses in this sub-TLV, or the value zero if no
VLAN is specified.
o Num Group Recs: A 1-byte unsigned integer that is the number of
group records in this sub-TLV.
o GROUP RECORDS: Each group record carries the number of sources.
If this field is zero, it indicates a listener for (*,G), that is,
a listener not restricted by source. It then has a 16-byte
(128-bit) IPv6 Group Address followed by 16-byte source IPv6
addresses. If the number of sources do not fit in a single sub-
TLV, it is permitted to have the same group address repeated with
different source addresses in another sub-TLV of another instance
of the Group Address TLV.
The GIPV6-ADDR sub-TLV is carried only within a GADDR TLV.
2.1.4. Group Labeled MAC Address Sub-TLV
The GMAC-ADDR sub-TLV of the Group Address (GADDR) TLV specified in Section 2.1.1 provides for a VLAN ID. The Group Labeled MAC Address sub-TLV, below, extends this to a fine-grained label. +-+-+-+-+-+-+-+-+ |Type=GLMAC-ADDR| (1 byte) +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESV | Topology-ID | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fine-Grained Label | (3 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Num Group Recs | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GROUP RECORDS (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GROUP RECORDS (2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ................. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GROUP RECORDS (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where each group record is of the following form with k=6: +-+-+-+-+-+-+-+-+ | Num of Sources| (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Address (k bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source 1 Address (k bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source 2 Address (k bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ..... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source M Address (k bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: GADDR sub-TLV type, set to 4 (GLMAC-ADDR). o Length: 6 + m + k*n = 6 + m + 6*n, where m is the number of group records and n is the sum of the number of group and source addresses.
o RESV: Reserved. 4-bit field that MUST be sent as zero and ignored
on receipt.
o Topology-ID: This field carries a topology ID [RFC5120] or zero if
topologies are not in use.
o Label: This carries the fine-grained label [RFC7172] identifier
for all subsequent MAC addresses in this sub-TLV, or the value
zero if no label is specified.
o Num Group Recs: A 1-byte unsigned integer that is the number of
group records in this sub-TLV.
o GROUP RECORDS: Each group record carries the number of sources.
If this field is zero, it indicates a listener for (*,G), that is,
a listener not restricted by source. It then has a 6-byte
(48-bit) multicast address followed by 6-byte source MAC
addresses. If the sources do not fit in a single sub-TLV, the
same group address may be repeated with different source addresses
in another sub-TLV of another instance of the Group Address TLV.
The GLMAC-ADDR sub-TLV is carried only within a GADDR TLV.
2.1.5. Group Labeled IPv4 Address Sub-TLV
The Group Labeled IPv4 Address (GLIP-ADDR) sub-TLV is IS-IS sub-TLV
type 5 within the GADDR TLV. It has the same format as the Group
Labeled MAC Address sub-TLV described in Section 2.1.4 except that
k=4. The fields are as follows:
o Type: sub-TLV type, set to 5 (GLIP-ADDR).
o Length: 6 + m + k*n = 6 + m + 4*n, where m is the number of group
records and n is the sum of the number of group and source
addresses.
o Topology-ID: This field carries a topology ID [RFC5120] or zero if
topologies are not in use.
o RESV: Must be sent as zero on transmission and is ignored on
receipt.
o Label: This carries the fine-grained label [RFC7172] identifier
for all subsequent IPv4 addresses in this sub-TLV, or the value
zero if no label is specified.
o Num Group Recs: A 1-byte unsigned integer that is the number of
group records in this sub-TLV.
o GROUP RECORDS: Each group record carries the number of sources.
If this field is zero, it indicates a listener for (*,G), that is,
a listener not restricted by source. It then has a 4-byte
(32-bit) IPv4 Group Address followed by 4-byte source IPv4
addresses. If the number of sources do not fit in a single sub-
TLV, it is permitted to have the same group address repeated with
different source addresses in another sub-TLV of another instance
of the Group Address TLV.
The GLIP-ADDR sub-TLV is carried only within a GADDR TLV.
2.1.6. Group Labeled IPv6 Address Sub-TLV
The Group Labeled IPv6 Address (GLIPV6-ADDR) sub-TLV is IS-IS sub-TLV
type 6 within the GADDR TLV. It has the same format as the Group
Labeled MAC Address sub-TLV described in Section 2.1.4 except that
k=16. The fields are as follows:
o Type: sub-TLV type, set to 6 (GLIPV6-ADDR).
o Length: 6 + m + k*n = 6 + m + 16*n, where m is the number of group
records and n is the sum of the number of group and source
addresses.
o Topology-Id: This field carries a topology ID [RFC5120] or zero if
topologies are not in use.
o RESV: Must be sent as zero on transmission and is ignored on
receipt.
o Label: This carries the fine-grained label [RFC7172] identifier
for all subsequent IPv6 addresses in this sub-TLV, or the value
zero if no label is specified.
o Num Group Recs: A 1-byte unsigned integer that is the number of
group records in this sub-TLV.
o GROUP RECORDS: Each group record carries the number of sources.
If this field is zero, it indicates a listener for (*,G), that is,
a listener not restricted by source. It then has a 16-byte
(128-bit) IPv6 Group Address followed by 16-byte source IPv6
addresses. If the number of sources do not fit in a single sub-
TLV, it is permitted to have the same group address repeated with
different source addresses in another sub-TLV of another instance
of the Group Address TLV.
The GLIPV6-ADDR sub-TLV is carried only within a GADDR TLV.
2.2. Multi-Topology-Aware Port Capability Sub-TLVs
TRILL makes use of the Multi-Topology-Aware Port Capability TLV (MT- Port-Cap-TLV) as specified in [RFC6165]. The following subsections specify the sub-TLVs transported by the MT-Port-Cap-TLV for TRILL.2.2.1. Special VLANs and Flags Sub-TLV
In TRILL, a Special VLANs and Flags (VLAN-FLAGS) sub-TLV is carried in every IIH PDU. It has the following format: +--+--+--+--+--+--+--+--+ | Type | (1 byte) +--+--+--+--+--+--+--+--+ | Length | (1 byte) +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Port ID | (2 bytes) +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Sender Nickname | (2 bytes) +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |AF|AC|VM|BY| Outer.VLAN | (2 bytes) +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |TR|R |R |R | Designated-VLAN | (2 bytes) +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ o Type: sub-TLV type, set to MT-Port-Cap-TLV VLAN-FLAGS sub-TLV 1. o Length: 8. o Port ID: An ID for the port on which the enclosing TRILL IIH PDU is being sent as specified in [RFC6325], Section 4.4.2. o Sender Nickname: If the sending IS is holding any nicknames as discussed in [RFC6325], Section 3.7, one MUST be included here. Otherwise, the field is set to zero. This field is to support intelligent end stations that determine the egress IS (RBridge) for unicast data through a directory service or the like and that need a nickname for their first hop to insert as the ingress nickname to correctly format a TRILL Data frame (see [RFC6325], Section 4.6.2, point 8). It is also referenced in connection with the VLANs Appointed Sub-TLV (see Section 2.2.5) and can be used as the egress on one-hop RBridge Channel messages [RFC7178], for example, those use for BFD over TRILL [RFC7175]. o Outer.VLAN: A copy of the 12-bit outer VLAN ID of the TRILL IIH frame containing this sub-TLV, as specified in [RFC6325], Section 4.4.5.
o Designated-VLAN: The 12-bit ID of the Designated VLAN for the
link, as specified in [RFC6325], Section 4.2.4.2.
o AF, AC, VM, BY, and TR: These flag bits have the following
meanings when set to one, as specified in the listed section of
[RFC6325]:
RFC 6325
Bit Section Meaning if bit is one
--------------------------------------
AF 4.4.2 Originating IS believes it is Appointed
Forwarder for the VLAN and port on which the
containing IIH PDU was sent.
AC 4.9.1 Originating port configured as an access port
(TRILL traffic disabled).
VM 4.4.5 VLAN mapping detected on this link.
BY 4.4.2 Bypass pseudonode.
TR 4.9.1 Originating port configured as a trunk port
(end-station service disabled).
o R: Reserved bit. MUST be sent as zero and ignored on receipt.
2.2.2. Enabled-VLANs Sub-TLV
The optional Enabled-VLANs sub-TLV specifies the VLANs enabled at the
port of the originating IS on which the containing Hello was sent, as
specified in [RFC6325], Section 4.4.2. It has the following format:
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN bit-map....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV type, set to MT-Port-Cap-TLV Enabled-VLANs sub-TLV
2.
o Length: Variable, minimum 3.
o RESV: 4 reserved bits that MUST be sent as zero and ignored on
receipt.
o Start VLAN ID: The 12-bit VLAN ID that is represented by the high-
order bit of the first byte of the VLAN bit-map.
o VLAN bit-map: The highest-order bit indicates the VLAN equal to
the start VLAN ID, the next highest bit indicates the VLAN equal
to start VLAN ID + 1, continuing to the end of the VLAN bit-map
field.
If this sub-TLV occurs more than once in a Hello, the set of enabled
VLANs is the union of the sets of VLANs indicated by each of the
Enabled-VLAN sub-TLVs in the Hello.
2.2.3. Appointed Forwarders Sub-TLV
The Designated RBridge (DRB) on a link uses the Appointed Forwarders
sub-TLV to inform other ISs on the link that they are the designated
VLAN-x forwarder for one or more ranges of VLAN IDs as specified in
[RFC6439]. It has the following format:
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointment Information (1) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointment Information (2) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointment Information (N) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each appointment is of the form:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointee Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | End.VLAN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV type, set to MT-Port-Cap-TLV AppointedFwrdrs sub-TLV
3.
o Length: 6*n bytes, where there are n appointments.
o Appointee Nickname: The nickname of the IS being appointed a
forwarder.
o RESV: 4 bits that MUST be sent as zero and ignored on receipt.
o Start.VLAN, End.VLAN: This VLAN ID range is inclusive. Setting
both Start.VLAN and VLAN.end to the same value indicates a range
of one VLAN ID. If Start.VLAN is not equal to VLAN.end and
Start.VLAN is 0x000, the sub-TLV is interpreted as if Start.VLAN
was 0x001. If Start.VLAN 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 Start.VLAN, the sub-TLV is ignored. If both
Start.VLAN 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.
An IS's nickname may occur as Appointed Forwarder for multiple VLAN
ranges by occurrences of this sub-TLV within the same or different MT
Port Capability TLVs within an IIH PDU. See [RFC6439].
2.2.4. Port TRILL Version Sub-TLV
The Port TRILL Version (PORT-TRILL-VER) sub-TLV indicates the maximum
version of the TRILL standard supported and the support of optional
hop-by-hop capabilities. By implication, lower versions are also
supported. If this sub-TLV is missing from an IIH, it is assumed
that the originating IS only supports the base version (version zero)
of the protocol [RFC6325] and supports no optional capabilities
indicated by this sub-TLV.
+-+-+-+-+-+-+-+-+
| 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: MT-Port-Cap-TLV sub-TLV type, set to 7 (PORT-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 3 through 13
indicate that the corresponding TRILL Header hop-by-hop extended
flags [RFC7179] are supported. Bits 0 through 2 and 14 to 31 are
reserved to indicate support of optional capabilities. A one bit
indicates that the flag or capability is supported by the sending
IS. Bits in this field MUST be set to zero except as permitted
for a capability being advertised or if a hop-by-hop extended
header flag is supported.
This sub-TLV, if present, MUST occur in an MT-Port-Cap-TLV in a TRILL
IIH. If there is more than one occurrence, the minimum of the
supported versions is assumed to be correct and a capability or
header flag 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 TRILL-VER
sub-TLV (Section 2.3.1) so they cannot conflict. The flags and
capabilities indicated in this sub-TLV relate to hop-by-hop
processing that can differ between the ports of an IS (RBridge) and
thus must be advertised in IIHs. For example, a capability requiring
cryptographic hardware assist might be supported on some ports and
not others. However, the TRILL version is the same as that in the
PORT-TRILL-VER sub-TLV. An IS, if it is adjacent to the sending IS
of TRILL version 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).
2.2.5. VLANs Appointed Sub-TLV
The optional VLANs Appointed sub-TLV specifies, for the port of the originating IS on which the containing Hello was sent, the VLANs for which it is Appointed Forwarder. This sub-TLV has the following format: +-+-+-+-+-+-+-+-+ | Type | (1 byte) +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESV | Start VLAN ID | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLAN bit-map.... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: sub-TLV type, set to MT-Port-Cap-TLV VLANS-Appointed sub-TLV 8. o Length: Variable, minimum 3. o RESV: 4 reserved bits that MUST be sent as zero and ignored on receipt. o Start VLAN ID: The 12-bit VLAN ID that is represented by the high- order bit of the first byte of the VLAN bit-map. o VLAN bit-map: The highest-order bit indicates the VLAN equal to the start VLAN ID, the next highest bit indicates the VLAN equal to start VLAN ID + 1, continuing to the end of the VLAN bit-map field. If this sub-TLV occurs more than once in a Hello, the originating IS is declaring that it believes itself to be Appointed Forwarder on the port on which the enclosing IIH was sent for the union of the sets of VLANs indicated by each of the VLANs-Appointed sub-TLVs in the Hello.
(page 17 continued on part 2)
