Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7176

Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS

Pages: 45
Proposed Standard
Obsoletes:  6326
Part 3 of 3 – Pages 33 to 45
First   Prev   None

Top   ToC   RFC7176 - Page 33   prevText

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.
Top   ToC   RFC7176 - Page 34
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    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.
Top   ToC   RFC7176 - Page 35

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.
Top   ToC   RFC7176 - Page 36

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.
Top   ToC   RFC7176 - Page 37
     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     -      *
Top   ToC   RFC7176 - Page 38
     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]
Top   ToC   RFC7176 - Page 39
      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).
Top   ToC   RFC7176 - Page 40
   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).
Top   ToC   RFC7176 - Page 41
   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.
Top   ToC   RFC7176 - Page 42
   [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.
Top   ToC   RFC7176 - Page 43
   [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.
Top   ToC   RFC7176 - Page 44
   [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.
Top   ToC   RFC7176 - Page 45

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