Network Working Group Donald Eastlake INTERNET-DRAFT Huawei Intended status: Proposed Standard Tissa Senevirathne Obsoletes: 6326 Cisco Anoop Ghanwani Dell Dinesh Dutt Ayan Banerjee Cumulus Networks Expires: April 11, 2013 October 12, 2012 Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS Abstract The IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides optimal pair-wise data frame forwarding without configuration in multi-hop networks with arbitrary topology and link technology, and 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 Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Distribution of this document is unlimited. Comments should be sent to the TRILL working group mailing list. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. D. Eastlake, et al. [Page 1] INTERNET-DRAFT TRILL Use of IS-IS Table of Contents 1. Introduction............................................3 1.1 Conventions Used in This Document....................3 2. TLV and Sub-TLV Extensions to IS-IS for TRILL..........5 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..................8 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.......11 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...........................16 2.3 Sub-TLVs of the Router and MT Capability TLVs.......17 2.3.1 TRILL Version Sub-TLV.............................17 2.3.2 Nickname Sub-TLV..................................18 2.3.3 Trees Sub-TLV.....................................19 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..21 2.3.7 VLAN Group Sub-TLV................................24 2.3.8 Interested Labels and Spanning Tree Roots Sub-TLV.24 2.3.9 RBridge Channel Protocols Sub-TLV.................26 2.3.10 Affinity Sub-TLV.................................28 2.3.11 Label Group Sub-TLV..............................30 2.4 MTU Sub-TLV for Ext. Reachability and MT ISN TLVs...30 2.5 TRILL Neighbor TLV..................................31 3. MTU PDUs...............................................34 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)..............................36 4.5 Originating LSP Buffer Size.........................36 5. IANA Considerations....................................37 5.1 TLVs................................................37 5.2 sub-TLVs............................................37 5.3 PDUs................................................39 5.4 Reserved and Capability Bits........................39 5.5 TRILL Neighbor Record Flags.........................39 6. Security Considerations................................41 7. Change from RFC 6326...................................42 8. Normative References...................................44 9. Informative References.................................45 Acknowledgements..........................................47 D. Eastlake, et al. [Page 2] INTERNET-DRAFT TRILL Use of IS-IS 1. Introduction The IETF TRILL (Transparent Interconnection of Lots of Links) protocol [RFC6325] [RFC6327] provides transparent forwarding in multi-hop networks with arbitrary topology and link technologies using encapsulation 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 RBridges (Routing Bridges) 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 as the TRILL Working Group passed it up to the IESG in 2009. There has been substantial development of TRILL since them. The main changes from [RFC6326] are summarized below and a full list is given in Section 7. 1. Addition of multicast group announcements by IPv4 and IPv6 address. 2. Addition of facilities for announcing capabilities supported. 3. Addition of a tree affinity sub-TLV whereby ISs can request distribution tree association. 4. Addition of multi-topology support. 5. Addition of control plane support for TRILL Data frame fine- grained labels. This support is independent of the data plane representation. 6. Fix the reported errata [Err2869] in [RFC6326]. Changes herein to TLVs and sub-TLVs specified in [RFC6326] are backwards 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: D. Eastlake, et al. [Page 3] INTERNET-DRAFT TRILL Use of IS-IS 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]. 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]. D. Eastlake, et al. [Page 4] INTERNET-DRAFT TRILL Use of IS-IS 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 advertises 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: D. Eastlake, et al. [Page 5] INTERNET-DRAFT TRILL Use of IS-IS +-+-+-+-+-+-+-+-+ |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 D. Eastlake, et al. [Page 6] INTERNET-DRAFT TRILL Use of IS-IS VLAN is specified. o Number of Group Records: A 1-byte unsigned integer that is the number of group records in this sub-TLV. o Group Record: 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 TBD [2 suggested] 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 TBD [2 suggested] (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 Number of Group Records: This is of length 1 byte and lists the number of group records in this sub-TLV. o Group Record: 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 D. Eastlake, et al. [Page 7] INTERNET-DRAFT TRILL Use of IS-IS 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 TBD [3 suggested] 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 TBD [3 suggested] (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 Number of Group Records: This is of length 1 byte and lists the number of group records in this sub-TLV. o Group Record: 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. D. Eastlake, et al. [Page 8] INTERNET-DRAFT TRILL Use of IS-IS +-+-+-+-+-+-+-+-+ |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 TBD [4 suggested] (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 identifier for all subsequent MAC addresses in this sub-TLV, or the value zero if no D. Eastlake, et al. [Page 9] INTERNET-DRAFT TRILL Use of IS-IS label is specified. o Number of Group Records: A 1-byte unsigned integer that is the number of group records in this sub-TLV. o Group Record: 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 TBD [5 suggested] 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 TBD [5 suggested] (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 identifier for all subsequent IPv4 addresses in this sub-TLV, or the value zero if no label is specified. o Number of Group Records: This is of length 1 byte and lists the number of group records in this sub-TLV. o Group Record: 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 D. Eastlake, et al. [Page 10] INTERNET-DRAFT TRILL Use of IS-IS 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 TBD [6 suggested] 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 TBD [6 suggested] (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 identifier for all subsequent IPv6 addresses in this sub-TLV, or the value zero if no label is specified. o Number of Group Records: This of length 1 byte and lists the number of group records in this sub-TLV. o Group Record: 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 (MT-PORT- CAP) TLV as specified in [RFC6165]. The following subsections of D. Eastlake, et al. [Page 11] INTERNET-DRAFT TRILL Use of IS-IS this Section 2.2 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 | Desig.VLAN | (2 bytes) +--+--+--+--+-------------------+ o Type: sub-TLV type, set to MT-PORT-CAP 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). 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 Desig.VLAN: The 12-bit ID of the Designated VLAN for the link, as specified in [RFC6325], Section 4.2.4.2. D. Eastlake, et al. [Page 12] INTERNET-DRAFT TRILL Use of IS-IS 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 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 D. Eastlake, et al. [Page 13] INTERNET-DRAFT TRILL Use of IS-IS 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 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 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. D. Eastlake, et al. [Page 14] INTERNET-DRAFT TRILL Use of IS-IS o RESV: 4 bits that MUST be sent as zero and ignored on receipt. o Start.VLAN, End.VLAN: These fields are the VLAN IDs of the appointment range, inclusive. To specify a single VLAN, the VLAN's ID appears as both the start and end VLAN. As specified in [RFC6439], appointing an IS forwarder on a port for a VLAN not enabled on that port has no effect. If the range specified is or includes the value 0x000 or 0xFFF, such values are ignored as they are not valid VLAN numbers 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 sub-TLV type, set to TBD [7 suggested] (PORT- TRILL-VER). o Length: 5. o Max-version: A one byte unsigned integer set to 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 [ExtendHeader] are supported. Bits 0 through 2 and 14 to 31 are D. Eastlake, et al. [Page 15] INTERNET-DRAFT TRILL Use of IS-IS 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 sub-TLV specifies the VLANs for which the port of the originating IS on which the containing Hello was sent is appointed forwarder. 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 VLANS-Appointed sub-TLV TBD [8 suggested]. 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 D. Eastlake, et al. [Page 16] INTERNET-DRAFT TRILL Use of IS-IS 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 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. 2.3 Sub-TLVs of the Router and MT Capability TLVs The Router Capability TLV is specified in [RFC4971] and the MT Capability TLV in [RFC6329]. All of the sub-sections of this Section 2.3 below specify sub-TLVs that can be carried in the Router Capability TLV (#242) and the MT (multi-topology) 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). D. Eastlake, et al. [Page 17] INTERNET-DRAFT TRILL Use of IS-IS o Length: 5. o Max-version: A one byte unsigned integer set to 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 [ExtendHeader] 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, MUST occur in a Router Capabilities TLV in the LSP number zero for the originating IS. If found 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 supported bits 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. 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 as specified in [RFC6325], Section 3.7.3. Multiple instances of this sub-TLV may occur. D. Eastlake, et al. [Page 18] INTERNET-DRAFT TRILL Use of IS-IS +-+-+-+-+-+-+-+-+ |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 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: D. Eastlake, et al. [Page 19] INTERNET-DRAFT TRILL Use of IS-IS +-+-+-+-+-+-+-+-+ |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 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 (...) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D. Eastlake, et al. [Page 20] INTERNET-DRAFT TRILL Use of IS-IS o Type: Router 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: D. Eastlake, et al. [Page 21] INTERNET-DRAFT TRILL Use of IS-IS - 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 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. D. Eastlake, et al. [Page 22] INTERNET-DRAFT TRILL Use of IS-IS 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-TVL 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. 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. D. Eastlake, et al. [Page 23] INTERNET-DRAFT TRILL Use of IS-IS 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 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 announces its fine- grained label connectivity and related information in the "Interested Labels and Bridge Spanning Tree Roots sub-TLV" (INT-LABEL) which is a variation of the "Interested VLANs and Spanning Tree Roots sub-TLV" (INT-VLAN) structured as below. D. Eastlake, et al. [Page 24] INTERNET-DRAFT TRILL Use of IS-IS +-+-+-+-+-+-+-+-+ |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 and MT Capability sub-TLV Type, set to TBD [15 suggested] (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 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. D. Eastlake, et al. [Page 25] INTERNET-DRAFT TRILL Use of IS-IS - Label.start and Label.end: If the BM bit is zero: This fine- grained label ID range is inclusive. These fields are treated as unsigned integers. Setting them both to that 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 in 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 [Channel] it supports through use of this sub-TLV. D. Eastlake, et al. [Page 26] INTERNET-DRAFT TRILL Use of IS-IS +-+-+-+-+-+-+-+-+ |Type=RBCHANNELS| (1 byte) +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... | Zero or more bit vectors (variable) +-+-+-+-... o Type: Router and MT Capabilities RBridge Channel Protocols sub- TLV, set to TBD [16 suggested] (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. An RBridge Channel protocols-supported bit vector 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 that IS does not support the RBridge Channel facility. D. Eastlake, et al. [Page 27] INTERNET-DRAFT TRILL Use of IS-IS 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 and 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 RBridge channel protocol support announcement. 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 tree 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 ISes 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. D. Eastlake, et al. [Page 28] INTERNET-DRAFT TRILL Use of IS-IS +-+-+-+-+-+-+-+-+ | 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 and MT Capability sub-TLV type, set to TBD [17 suggested] (AFFINITY). o Length: 1 + size of all Affinity Records included, where an Affinity Record listing n tree roots is 3+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. D. Eastlake, et al. [Page 29] INTERNET-DRAFT TRILL Use of IS-IS 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 Label 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 and MT Capability sub-TLV type, set to TBD [18 suggested] (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 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 Ext. 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 (multi-topology) ISN (Intermediate System Neighbors) (#222) TLVs. D. Eastlake, et al. [Page 30] INTERNET-DRAFT TRILL Use of IS-IS +-+-+-+-+-+-+-+-+ | Type = MTU | (1 byte) +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+ |F| RESV | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTU | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: Extended Reachability and MT IS 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 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 [RFC6327]. 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D. Eastlake, et al. [Page 31] INTERNET-DRAFT TRILL Use of IS-IS 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 [RFC5342]. (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 [ClearCorrect] 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: Sub-Network Point of Attachment (MAC address) of the D. Eastlake, et al. [Page 32] INTERNET-DRAFT TRILL Use of IS-IS neighbor. As specified in [RFC6327] 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. D. Eastlake, et al. [Page 33] INTERNET-DRAFT TRILL Use of IS-IS 3. MTU PDUs The IS-IS MTU-probe and MTU-ack PDUs are used to optionally determine the MTU on a link between ISs as specified in Section 4.3.2 of [RFC6325] and in [RFC6327]. The MTU PDUs have the IS-IS PDU common header (up through the Maximum Area Addresses byte) with PDU Type numbers as indicated in Section 5. They also have a common fixed MTU PDU header as shown below that is 8 + 2*(ID Length) bytes long, 20 bytes in the case of the usual 6-bytes System IDs. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PDU Length | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+ | Probe ID (6 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+ | Probe Source ID (ID Length bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+ | Ack Source ID (ID Length bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+ As with other IS-IS PDUs, the PDU length gives the length of the entire IS-IS packet starting with and including the IS-IS common header. The Probe ID field is an opaque 48-bit quantity set by the IS issuing an MTU-probe and copied by the responding IS into the corresponding MTU-ack. For example, an IS creating an MTU-probe could compose this quantity from a port identifier and probe sequence number relative to that port. The Probe Source ID is set by an IS issuing an MTU-probe to its System ID and copied by the responding IS into the corresponding MTU- ack. The Ack Source ID is set to zero in MTU-probe PDUs and ignored on receipt. An IS issuing an MTU-ack sets the Ack Source ID field to its System ID. The System ID length is usually 6 bytes but could be a different value as indicated by the ID Length field in the IS-IS PDU Header. The TLV area follows the MTU PDU header area. This area MAY contain an Authentication TLV and MUST be padded to the exact size being tested with the Padding TLV. Since the minimum size of the Padding TLV is 2 bytes, it would be impossible to pad to exact size if the total length of the required information bearing fixed fields and TLVs added up to 1 byte less than the desired length. However, the length of the fixed fields and substantive TLVs for MTU PDUs is expected to be quite small compared with their minimum length (minimum 1470-byte MTU on an IEEE 802.3 link, for example), so this should not be a problem. D. Eastlake, et al. [Page 34] INTERNET-DRAFT TRILL Use of IS-IS 4. Use of Existing PDUs and TLVs The sub-sections below provide details of TRILL use of existing PDUs and TLVs. 4.1 TRILL IIH PDUs The TRILL IIH PDU is the variation of the LAN IIH PDU used by the TRILL protocol. Section 4.4 of the TRILL standard [RFC6325] and [RFC6327] specify the contents of the TRILL IIH and how its use in TRILL differs from Layer 3 LAN IIH PDU use. The adjacency state machinery for TRILL neighbors is specified in detail in [RFC6327]. In a TRILL IIH PDU, the IS-IS common header and the fixed PDU Header are the same as a Level 1 LAN IIH PDU. The Maximum Area Addresses octet in the common header MUST be set to 0x01. The IS-IS Neighbor TLV (6) is not used in a TRILL IIH and is ignored if it appears there. Instead, TRILL IIH PDUs use the TRILL Neighbor TLV (see Section 2.5). 4.2 Area Address TRILL uses a fixed zero Area Address as specified in [RFC6325], Section 4.2.3. This is encoded in a 4-byte Area Address TLV (TLV #1) as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01, Area Address Type | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x02, Length of Value | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01, Length of Address | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00, zero Area Address | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.3 Protocols Supported NLPID (Network Layer Protocol ID) 0xC0 has been assigned to TRILL [RFC6328]. A Protocols Supported TLV (#129, [RFC1195]) including that value MUST appear in TRILL IIH PDUs and LSP number zero PDUs. D. Eastlake, et al. [Page 35] INTERNET-DRAFT TRILL Use of IS-IS 4.4 Link State PDUs (LSPs) A number zero LSP MUST NOT be originated larger than 1470 bytes but a larger number zero LSP successfully received MUST be processed and forwarded normally. 4.5 Originating LSP Buffer Size The originatingLSPBufferSize TLV (#14) MUST be in LSP number zero; however, if found in other LSP fragments, it is processed normally. Should there be more than one originatingLSPBufferSize TLV for an IS, the minimum size, but not less than 1470, is used. D. Eastlake, et al. [Page 36] INTERNET-DRAFT TRILL Use of IS-IS 5. IANA Considerations This section give IANA Considerations for the TLVs, sub-TLVs, and PDUs specified herein. 5.1 TLVs This document specifies two IS-IS TLV types -- namely, the Group Address TLV (GADDR-TLV, type 142) and the TRILL Neighbor TLV (type 145). The PDUs in which these TLVs are permitted for TRILL are shown in the table below along with the section of this document where they are discussed. The final "NUMBER" column indicates the permitted number of occurrences of the TLV in their PDU, or set of PDUs in the case of LSP, which in these two cases is "*" indicating that the TLV MAY occur 0, 1, or more times. IANA has registered these two code points in the IANA IS-IS TLV registry (ignoring the "Section" and "NUMBER" columns, which are irrelevant to that registry). Section TLV IIH LSP SNP Purge NUMBER ======= === === === === ===== ====== GADDR-TLV 2.1 142 - X - - * TRILL Neighbor TLV 2.5 145 X - - - * 5.2 sub-TLVs This document specifies a number of sub-TLVs. The TLVs in which these sub-TLVs occur are shown in the second table below along with the section of this document where they are discussed. The TLVs within which these sub-TLVs can occur are determined by the presence of an "X" in the relevant column and the column header as shown in the first table below. In some cases, the column header corresponds to two different TLVs in which the sub-TLV can occur. Column Head TLV RFCref TLV Name =========== ===== ======== ============== Grp. Adr. 142 This doc Group Address MT Port 143 6165 MT-PORT-CAP MT Cap. 242 4971 Router CAPABILITY 144 6329 MT-Capability Ext. Reach 22 5305 Extended IS Reachability 222 5120 MT ISN D. Eastlake, et al. [Page 37] INTERNET-DRAFT TRILL Use of IS-IS The final "NUMBER" column below indicates the permitted number of occurrences of the sub-TLV cumulatively within all occurrences of their TLV(s) in those TLVs' carrying PDU (or set of PDUs in the case of LSP), as follows: 0-1 = MAY occur zero or one times. 1 = MUST occur exactly once. If absent, the PDU is ignored. If it occurs more than once, results are unspecified. * = MAY occur 0, 1, or more times. The values in the "Section" and "NUMBER" columns are irrelevant to the IANA sub-registries. The numbers in square brackets are suggested values. sub- Grp. MT MT Ext. Name Section TLV# Adr. Port Cap. Reach NUMBER ================================================================ GMAC-ADDR 2.1.1 1 X - - - * GIP-ADDR 2.1.2 TBD[2] X - - - * GIPV6-ADDR 2.1.3 TBD[3] X - - - * GLMAC-ADDR 2.1.4 TBD[4] X - - - * GLIP-ADDR 2.1.5 TBD[5] X - - - * GLIPV6-ADDR 2.1.6 TBD[6] X - - - * VLAN-FLAGS 2.2.1 1 - X - - 1 Enabled-VLANs 2.2.2 2 - X - - * AppointedFwrdrs 2.2.3 3 - X - - * PORT-TRILL-VER 2.2.4 TBD[7] - X - - 0-1 VLANs-Appointed 2.2.5 TBD[8] - X - - * NICKNAME 2.3.2 6 - - X - * TREES 2.3.3 7 - - X - 0-1 TREE-RT-IDs 2.3.4 8 - - X - * TREE-USE-IDs 2.3.5 9 - - X - * INT-VLAN 2.3.6 10 - - X - * TRILL-VER 2.3.1 13 - - X - 0-1 VLAN-GROUP 2.3.7 14 - - X - * INT-LABEL 2.3.8 TBD[15] - - X - * RBCHANNELS 2.3.9 TBD[16] - - X - * AFFINITY 2.3.10 TBD[17] - - X - * LABEL-GROUP 2.3.11 TBD[18] - - X - * MTU 2.4 28 - - - X 0-1 ================================================================ Name Section sub- Grp. MT MT Ext. NUMBER TLV# Adr. Port Cap. Reach D. Eastlake, et al. [Page 38] INTERNET-DRAFT TRILL Use of IS-IS 5.3 PDUs The IS-IS PDUs registry remains as established in [RFC6326] except that the references to [RFC6326] are updated to reference this document. 5.4 Reserved and Capability Bits Any reserved bits (R) or bits in reserved fields (RESV) or the capabilities bits in the PORT-TRILL-VER and TRILL-VER sub-TLVs, which are specified herein as "MUST be sent as zero and ignored on receipt" or the like, are allocated based on IETF Review [RFC5226]. Two sub-registries are created within the TRILL Parameters Registry as follows: Sub-Registry Name: TRILL-VER Sub-TLV Capability Flags Registration Procedures: IETF Review Reference: (This document) Bit Description Reference ===== ============= =========== 0 Affinity sub-TLV support. [Affinity] 1-13 Available 14-31 Extended header flag support. [ExtendHeader] Sub-Registry Name: PORT-TRILL-VER Sub-TLV Capability Flags Registration Procedures: IETF Review Reference: (This document) Bit Description Reference ===== ============= =========== 0 Hello reduction support. [ClearCorrect] 1-2 Available 3-13 Hop-by-hop extended flag support. [ExtendHeader] 14-31 Available 5.5 TRILL Neighbor Record Flags A sub-registry is created within the TRILL Parameters Registry as follows: D. Eastlake, et al. [Page 39] INTERNET-DRAFT TRILL Use of IS-IS Sub-Registry Name: TRILL Neighbor TLV NEIGHBOR RECORD Flags Registration Procedures: Standards Action Reference: (This document) Bit Short Name Description Reference ============== ============= =========== 0 Fail Failed MTU test. [RFC6325] 1 OOMF Offering OOMF service. [ClearCorrect] 2-7 - Available. D. Eastlake, et al. [Page 40] INTERNET-DRAFT TRILL Use of IS-IS 6. Security Considerations For general TRILL protocol security considerations, see the TRILL base protocol standard [RFC6325]. This document raises no new security issues for IS-IS. IS-IS security may be used to secure the IS-IS messages discussed here. See [RFC5304] and [RFC5310]. Even when IS-IS authentication is used, replays of Hello packets can create denial-of-service conditions; see [RFC6039] for details. These issues are similar in scope to those discussed in Section 6.2 of [RFC6325], and the same mitigations may apply. D. Eastlake, et al. [Page 41] INTERNET-DRAFT TRILL Use of IS-IS 7. Change from RFC 6326 Non-editorial changes from [RFC6326] are summarized in the list below: 1. Additional of five sub-TLVs under the Group Address (GADDR) TLV covering VLAN labeled IPv4 and IPv6 addresses and fine-grained labeled MAC, IPv4, and IPv6 addresses. (Sections 2.1.2, 2.1.3, 2.1.4, 2.1.5, and 2.1.6). 2. Addition of the PORT-TRILL-VER sub-TLV. (Section 2.2.4) 3. Addition of the VLANs-Appointed sub-TLV. (Section 2.2.5) 4. Change the TRILL-VER sub-TLV as listed below. 4.a Addition of 4 bytes of TRILL Header extended flags and capabilities supported information. 4.b Require that the TRILL-VER sub-TLV appear in LSP number zero. The above changes to TRILL-VER are backwards compatible because the [RFC6326] conformant implementations of TRILL thus far have only supported version zero and not supported any optional capabilities or extended flags, the level of support indicated by the absence of the TRILL-VER sub-TLV. Thus, if an [RFC6326] conformant implementation of TRILL rejects this sub-TLV due to the changes specified in this document, it will, at worst, decide that support of version zero and no extended flags or capabilities is indicated, which is the best an [RFC6326] conformant implementation of TRILL can do anyway. Similarly, a TRILL implementation that supports TRILL-VER as specified herein and rejects TRILL-VER sub-TLVs in an [RFC6326] conformant TRILL implementation because they are not in LSP number zero will decide that that implementation supports only version zero with no extended flag or capabilities support, which will be correct. (Section 2.3.1) 5. Clarification of the use of invalid VLAN IDs in the Appointed Forwarders sub-TLV and the Interested VLANs and Spanning Tree Roots sub-TLV. (Sections 2.2.3 and 2.3.6) 6. Addition of the Interested Labels and Spanning Tree Roots sub-TLV to indicate attachment of an IS to a fine-grained label analogous to the existing Interested VLANs and Spanning Tree Roots sub-TLV for VLANs. (Section 2.3.8) 7. Addition of the RBridge Channel Protocols sub-TLV so ISs can announce the RBridge Channel protocols they support. (Section 2.3.9) D. Eastlake, et al. [Page 42] INTERNET-DRAFT TRILL Use of IS-IS 8. Permit specification of the length of the link SNPA field in TRILL Neighbor TLVs. This change is backwards compatible because the size of 6 bytes is specially encoded as zero, the previous value of the bits in the new SIZE field. (Section 2.5) 9. Make the size of the MTU PDU Header Probe Source ID and Ack Source ID fields be the ID Length from the IS-IS PDU Header rather than the fixed value 6. (Section 3) 10. For robustness, require LSP number zero PDUs be originated as no larger than 1470 bytes but processed regardless of size. (Section 4.4) 11. Require that the originatingLSPBufferSize TLV, if present, appear in LSP number zero. (Section 4.5) 12. Create sub-registries for and specify the IANA Considerations policy for reserved and capability bits in the TRILL version sub- TLVs. (Section 5.4) 13. Addition of the distribution tree Affinity sub-TLV so ISs can request distribution tree attachments. (Section 2.3.10) 14. Add LABEL-GROUP sub-TLV analogous to the VLAN-GROUP sub-TLV. (Section 2.3.11) 15. Add multi-topology: permit sub-TLVs previously only in Router Capabilities TLV to also appear in MT Capabilities TLV; permit MTU sub-TLV previously limited to Extended Reachability TLV to also appear in MT ISN TLV. 16. Addition of a sub-registry for Neighbor TLV Neighbor RECORD flag bits. (Section 5.5) 17. Explicitly state that if the number of sources in a GADDR-TLV sub-TLV is zero, it indicates a listener for (*,G), that is, a listener not restricted by source. (Section 2.1) D. Eastlake, et al. [Page 43] INTERNET-DRAFT TRILL Use of IS-IS 8. Normative References [ISO-10589] - ISO/IEC 10589:2002, Second Edition, "Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", 2002. [RFC1195] - Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments", 1990. [RFC1982] - Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996. [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4971] - Vasseur, JP. and N. Shen, "Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information", 2007. [RFC5120] - Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, February 2008. [RFC5226] - Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5305] - Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", 2008. [RFC6165] - Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, April 2011. [RFC6325] - Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. Ghanwani, "RBridges: Base Protocol Specification", RFC 6325, June 2011. [RFC6327] - Eastlake, D., Perlman, R., Ghanwani, A., Dutt, D., and V. Manral, "RBridges: Adjacency", RFC 6327, July 2011. [RFC6328] - Eastlake, D., "IANA Considerations for Network Layer Protocol Identifiers", RFC 6328, June 2011. [RFC6329] - Fedyk, D., Ed., Ashwood-Smith, P., Ed., Allan, D., Bragg, A., and P. Unbehagen, "IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging", RFC 6329, April 2012. [RFC6439] - Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC D. Eastlake, et al. [Page 44] INTERNET-DRAFT TRILL Use of IS-IS 6439, November 2011. [Channel] - D. Eastlake, V. Manral, L. Yizhou, S. Aldrin, D. Ward, draft-ietf-trill-rbridge-channel, in RFC Editor's queue. [ClearCorrect] - D. Eastlake, M. Zhang, A. Ghanwani, V. Manral, A. Banerjee, draft-ietf-trill-clear-correct, in RFC Editor's queue. [ExtendHeader] - D. Eastlake, A. Ghanwani, V. Manral, Y. Li, C. Bestler, draft-ietf-trill-rbridge-extension, in RFC Editor's queue. 9. Informative References [802.1D-2004] - "IEEE Standard for Local and metropolitan area networks / Media Access Control (MAC) Bridges", 802.1D-2004, 9 June 2004. [802.1Q-2011] - "IEEE Standard for Local and metropolitan area networks / Virtual Bridged Local Area Networks", 802.1Q-2011, 31 August 2011. [Err2869] - RFC Errata, Errata ID 2869, RFC 6326, http://www.rfc- editor.org. [RFC5304] - Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, October 2008. [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009. [RFC5342] - Eastlake 3rd, D., "IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters", BCP 141, RFC 5342, September 2008. [RFC6039] - Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues with Existing Cryptographic Protection Methods for Routing Protocols", RFC 6039, October 2010. [RFC6326] - Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. Ghanwani, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 6326, July 2011. [Affinity] - draft-ietf-trill-cmt, work in progress. D. Eastlake, et al. [Page 45] INTERNET-DRAFT TRILL Use of IS-IS [MultiLevel] - draft-perlman-trill-rbridge-multilevel, work in progress. [Resilient] - draft-zhang-trill-resilient-trees, work in progress. D. Eastlake, et al. [Page 46] INTERNET-DRAFT TRILL Use of IS-IS Acknowledgements The authors gratefully acknowledge the contributions and review by the following: Adrian Farrel, Radia Perlman, Joe Touch. And the contributions by the following to [RFC6326]: Mike Shand, Stewart Bryant, Dino Farinacci, Les Ginsberg, Sam Hartman, Dan Romascanu, Dave Ward, and Russ White. In particular, thanks to Mike Shand for the detailed and helpful comments. This document was produced with raw nroff. All macros used were defined in the source files. D. Eastlake, et al. [Page 47] INTERNET-DRAFT TRILL Use of IS-IS Authors' Addresses Donald Eastlake Huawei Technologies 155 Beaver Street Milford, MA 01757 USA Phone: +1-508-333-2270 EMail: d3e3e3@gmail.com Tissa Senevirathne Cisco Systems 375 East Tasman Drive, San Jose, CA 95134 Phone: +1-408-853-2291 EMail: tsenevir@cisco.com Anoop Ghanwani Dell 350 Holger Way San Jose, CA 95134 USA Phone: +1-408-571-3500 EMail: anoop@alumni.duke.edu Dinesh Dutt Cumulus Networks 1089 West Evelyn Avenue Sunnyvale, CA 94086 USA EMail: ddutt.ietf@hobbesdutt.com Ayan Banerjee Cumulus Networks 1089 West Evelyn Avenue Sunnyvale, CA 94086 USA EMail: ayabaner@gmail.com D. Eastlake, et al. [Page 48] INTERNET-DRAFT TRILL Use of IS-IS Copyright, Disclaimer, and Additional IPR Provisions Copyright (c) 2012 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. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. D. Eastlake, et al. [Page 49]