RFC 7176
Transparent Interconnection of Lots of Links (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 [RFC7177]. 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 with the Padding TLV to the exact size being tested. 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.
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 IIH PDU used by the TRILL protocol. Section 4.4 of the TRILL standard [RFC6325] and [RFC7177] 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 [RFC7177]. In a TRILL IIH PDU, the IS-IS common header and the fixed PDU Header are the same as a Level 1 IIH PDU. The IS-IS Neighbor TLV (6) is not used in a TRILL IIH and is ignored if it appears there. Instead, TRILL LAN 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 appears in TRILL IIH PDUs and LSP number zero PDUs.4.4. Link State PDUs (LSPs)
An LSP number zero MUST NOT be originated larger than 1470 bytes, but a larger LSP number zero 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.5. IANA Considerations
This section gives IANA considerations for the TLVs, sub-TLVs, and PDUs specified herein. A number of new code points are assigned, and those that were assigned by [RFC6326] are included here for convenience. IANA has replaced all [RFC6326] references in the IANA registries with references to this document.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 LSPs, 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 n y n n * TRILL Neighbor TLV 2.5 145 y n n n *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; the column headers are described 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 RFC TLV Name
=========== ===== ======== ==============
Grp. Adr. 142 7176 Group Address
MT Port 143 6165 MT-Port-Cap-TLV
MT Cap. 242 4971 Router CAPABILITY
144 6329 MT-Capability
Ext. Reach 22 5305 Extended IS Reachability
222 5120 MT-ISN
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 a PDU (or set of PDUs in the
case of LSPs), 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.
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 2 X - - - *
GIPV6-ADDR 2.1.3 3 X - - - *
GLMAC-ADDR 2.1.4 4 X - - - *
GLIP-ADDR 2.1.5 5 X - - - *
GLIPV6-ADDR 2.1.6 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 7 - X - - 0-1
VLANs-Appointed 2.2.5 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 15 - - X - *
RBCHANNELS 2.3.9 16 - - X - *
AFFINITY 2.3.10 17 - - X - *
LABEL-GROUP 2.3.11 18 - - X - *
MTU 2.4 28 - - - X 0-1
=================================================================
Name Section sub- Grp. MT MT Ext. NUMBER
TLV# Adr. Port Cap. Reach
IANA has entered the newly assigned sub-TLV numbers in the above
table in the relevant existing sub-TLV registries, as determined by
which column has an X for that sub-TLV. For the sub-TLVs from
NICKNAME through and including VLAN-GROUP, which previously existed
only in the registry of sub-TLVs under TLV 242, IANA has added each
sub-TLV with the same sub-TLV number to the existing registry for
sub-TLVs under TLV 144.
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), bits in reserved fields (RESV), or
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 have been 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 FGL-safe [RFC7172]
2-13 Unassigned
14-31 Extended header flag support. [RFC7179]
Sub-Registry Name: PORT-TRILL-VER Sub-TLV Capability Flags
Registration Procedures: IETF Review
Reference: (This document)
Bit Description Reference
===== ============= ===========
0 Hello reduction support. [RFC7180]
1-2 Unassigned
3-13 Hop-by-hop extended flag support. [RFC7179]
14-31 Unassigned
5.5. TRILL Neighbor Record Flags
A sub-registry has been created within the TRILL Parameters Registry
as follows:
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][RFC7176][RFC7177]
1 OOMF Offering OOMF service [RFC7180]
2-7 - Unassigned
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.
7. Changes from RFC 6326
Non-editorial changes from [RFC6326] are summarized in the list
below:
1. Added 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. Added the PORT-TRILL-VER sub-TLV (Section 2.2.4). 3. Added the VLANs-Appointed sub-TLV (Section 2.2.5). 4. Changed the TRILL-VER sub-TLV as listed below. a. Added 4 bytes of TRILL Header extended flags and capabilities supported information. b. Required that the TRILL-VER sub-TLV appear in LSP number zero. The above changes to TRILL-VER are backward 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 the implementation supports only version zero with no extended flag or capabilities support, which will be correct (Section 2.3.1). 5. Clarified the use of invalid VLAN IDs (0x000 and 0xFFF) 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. Added the Interested Labels and Spanning Tree Roots sub-TLV to indicate attachment of an IS to a fine-grained label [RFC7172] analogous to the existing Interested VLANs and Spanning Tree Roots sub-TLV for VLANs (Section 2.3.8). 7. Added the RBridge Channel Protocols sub-TLV so ISs can announce the RBridge Channel protocols they support (Section 2.3.9). 8. Permitted specification of the length of the link SNPA field in TRILL Neighbor TLVs. This change is backward 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. Made 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, required that LSP number zero PDUs be originated
as no larger than 1470 bytes but processed regardless of size
(Section 4.4).
11. Required that the originatingLSPBufferSize TLV, if present,
appear in LSP number zero (Section 4.5).
12. Created sub-registries for and specified the IANA Considerations
policy for reserved and capability bits in the TRILL version sub-
TLVs (Section 5.4).
13. Added the distribution tree Affinity sub-TLV so ISs can request
distribution tree attachments (Section 2.3.10).
14. Added the LABEL-GROUP sub-TLV analogous to the VLAN-GROUP sub-TLV
(Section 2.3.11).
15. Added multi-topology to permit sub-TLVs previously only in the
Router Capability TLV to also appear in the MT-Capability TLV and
to permit the MTU sub-TLV previously limited to the Extended
Reachability TLV to also appear in the MT-ISN TLV.
16. Added a sub-registry for Neighbor TLV Neighbor RECORD flag bits
(Section 5.5).
17. Explicitly stated 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).
8. References
8.1. Normative References
[ISO-10589]
International Organization for Standardization,
"Intermediate System to Intermediate System intra-domain
routeing information exchange protocol for use in
conjunction with the protocol for providing the
connectionless-mode network service (ISO 8473)", Second
Edition, November 2002.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 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., Ed., Shen, N., Ed., and R. Aggarwal, Ed., "Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information", RFC 4971, July 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", RFC 5305, October 2008. [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, April 2011. [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011. [RFC6328] Eastlake 3rd, D., "IANA Considerations for Network Layer Protocol Identifiers", BCP 164, RFC 6328, July 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 6439, November 2011. [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, May 2014. [RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, Y., and V. Manral, "Transparent Interconnection of Lots of Links (TRILL): Adjacency", RFC 7177, May 2014.
[RFC7178] Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. Ward, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support", RFC 7178, May 2014. [RFC7179] Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and C. Bestler, "Transparent Interconnection of Lots of Links (TRILL): Header Extension", RFC 7179, May 2014. [RFC7180] Eastlake 3rd, D., Zhang, M., Ghanwani, A., Manral, V., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7180, May 2014.8.2. Informative References
[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. [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. [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 7042, October 2013. [RFC7175] Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support", RFC 7175, May 2014. [Affinity] Senevirathne, T., Pathangi, J., and J. Hudson, "Coordinated Multicast Trees (CMT) for TRILL", Work in Progress, April 2014.
[MultiLevel] Perlman, R., Eastlake 3rd, D., Ghanwani, A., and H. Zhai, "Flexible Multilevel TRILL (Transparent Interconnection of Lots of Links)", Work in Progress, January 2014. [Resilient] Zhang, M. Senevirathne, T., Pathangi, J., Banerjee, A., and A. Ghanwani, "TRILL Resilient Distribution Trees", Work in Progress, December 2013.9. Acknowledgements
The authors gratefully acknowledge the contributions and reviews by the following individuals: Ross Callon, Spencer Dawkins, Adrian Farrel, Alexey Melnikov, Radia Perlman, Carlos Pignataro, and Joe Touch. The authors also acknowledge the contributions to [RFC6326] by the following individuals: Mike Shand, Stewart Bryant, Dino Farinacci, Les Ginsberg, Sam Hartman, Dan Romascanu, Dave Ward, and Russ White. In particular, thanks to Mike Shand for his detailed and helpful comments.
Authors' Addresses
Donald Eastlake 3rd 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 USA Phone: +1-408-853-2291 EMail: tsenevir@cisco.com Anoop Ghanwani Dell 5450 Great America Parkway Santa Clara, CA 95054 USA EMail: anoop@alumni.duke.edu Dinesh Dutt Cumulus Networks 1089 West Evelyn Avenue Sunnyvale, CA 94086 USA EMail: ddutt.ietf@hobbesdutt.com Ayan Banerjee Insieme Networks 210 West Tasman Drive San Jose, CA 95134 USA EMail: ayabaner@gmail.com