diff options
Diffstat (limited to 'doc/rfc/rfc6326.txt')
| -rw-r--r-- | doc/rfc/rfc6326.txt | 1403 |
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc6326.txt b/doc/rfc/rfc6326.txt new file mode 100644 index 0000000..9ba8a77 --- /dev/null +++ b/doc/rfc/rfc6326.txt @@ -0,0 +1,1403 @@ + + + + + + +Internet Engineering Task Force (IETF) D. Eastlake +Request for Comments: 6326 Huawei +Category: Standards Track A. Banerjee +ISSN: 2070-1721 D. Dutt + Cisco + R. Perlman + Intel + A. Ghanwani + Brocade + July 2011 + + + Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS + +Abstract + + The IETF has standardized the Transparent Interconnection of Lots of + Links (TRILL) protocol, which provides transparent Layer 2 forwarding + using encapsulation with a hop count and IS-IS link state routing. + This document specifies the data formats and code points for the + IS-IS extensions to support TRILL. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6326. + +Copyright Notice + + Copyright (c) 2011 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 + + + +Eastlake, et al. Standards Track [Page 1] + +RFC 6326 TRILL Use of IS-IS July 2011 + + + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Conventions Used in This Document ..........................3 + 2. TLV and Sub-TLV Extensions to IS-IS for TRILL ...................3 + 2.1. The Group Address TLV ......................................3 + 2.1.1. The Group MAC Address Sub-TLV .......................4 + 2.2. Multi-Topology-Aware Port Capability Sub-TLVs ..............5 + 2.2.1. The Special VLANs and Flags Sub-TLV .................6 + 2.2.2. Enabled-VLANs Sub-TLV ...............................7 + 2.2.3. Appointed Forwarders Sub-TLV ........................8 + 2.3. Sub-TLVs for the Router Capability TLV .....................9 + 2.3.1. The TRILL Version Sub-TLV ...........................9 + 2.3.2. The Nickname Sub-TLV ...............................10 + 2.3.3. The Trees Sub-TLV ..................................11 + 2.3.4. The Tree Identifiers Sub-TLV .......................11 + 2.3.5. The Trees Used Identifiers Sub-TLV .................12 + 2.3.6. Interested VLANs and Spanning Tree Roots Sub-TLV ...12 + 2.3.7. The VLAN Group Sub-TLV .............................15 + 2.4. MTU Sub-TLV of the Extended Reachability TLV ..............15 + 2.5. TRILL Neighbor TLV ........................................16 + 3. The MTU PDUs ...................................................18 + 4. Use of Existing PDUs and TLVs ..................................19 + 4.1. TRILL IIH PDUs ............................................19 + 4.2. Area Address ..............................................19 + 4.3. Protocols Supported .......................................19 + 5. IANA Considerations ............................................20 + 5.1. Allocations from Existing Registries ......................20 + 5.2. New Sub-Registries Created ................................21 + 6. Security Considerations ........................................22 + 7. References .....................................................22 + 7.1. Normative References ......................................22 + 7.2. Informative References ....................................23 + 8. Acknowledgements ...............................................23 + Appendix A. Initial IS-IS PDU Registry ............................24 + + + + + + + + + + + + + +Eastlake, et al. Standards Track [Page 2] + +RFC 6326 TRILL Use of IS-IS July 2011 + + +1. Introduction + + The IETF has standardized the TRILL protocol [RFC6325], which + provides transparent Layer 2 forwarding 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 as well as supporting VLANs. Intermediate Systems + (ISs) implementing TRILL can incrementally replace IEEE [802.1Q-2005] + bridges. + + This document, in conjunction with [RFC6165], specifies the data + formats and code points for the IS-IS [ISO-10589] [RFC1195] + extensions to support TRILL. + +1.1. Conventions Used in This Document + + The terminology and acronyms defined in [RFC6325] are used herein + with the same meaning. + + Additional acronyms used in this document are: + + IIH - IS-IS Hello + + IS - Intermediate System (for this document, all relevant + intermediate systems are RBridges) + + NLPID - Network Layer Protocol Identifier + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +2. TLV and Sub-TLV Extensions to IS-IS for TRILL + + This section, in conjunction with [RFC6165], specifies the data + formats and code points for the TLVs and sub-TLVs added to IS-IS to + support the TRILL standard. 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 provided in Section 5. + +2.1. The Group Address TLV + + The Group Address (GADDR) TLV, IS-IS TLV type 142, is carried only in + an LSP PDU and carries sub-TLVs that in turn advertise multicast + group listeners. Section 2.1.1 below specifies a sub-TLV that + advertises listeners by MAC address. It is anticipated that + + + + +Eastlake, et al. Standards Track [Page 3] + +RFC 6326 TRILL Use of IS-IS July 2011 + + + additional sub-TLVs for additional address types such as IP addresses + will be specified in other documents. 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. The 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 as specified in Section 4.5.5 of [RFC6325]. It has the + following format: + + +-+-+-+-+-+-+-+-+ + |Type=GMAC-ADDR | (1 byte) + +-+-+-+-+-+-+-+-+ + | Length | (1 byte) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RESV | Topology-ID | (2 bytes) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RESV | VLAN ID | (2 bytes) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Num Group Recs | (1 byte) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | GROUP RECORDS (1) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ................. | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | GROUP RECORDS (N) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + +Eastlake, et al. Standards Track [Page 4] + +RFC 6326 TRILL Use of IS-IS July 2011 + + + where each group record is of the form: + + +-+-+-+-+-+-+-+-+ + | Num of Sources| (1 byte) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Group Address (6 bytes) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Source 1 Address (6 bytes) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Source 2 Address (6 bytes) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ..... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Source M Address (6 bytes) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + o Type: GADDR sub-TLV type, set to 1 (GMAC-ADDR). + + o Length: Variable, minimum 5. + + o RESV: Reserved. 4-bit fields that MUST be sent as zero and + ignored on receipt. + + o Topology-ID: This field is not used in TRILL, where it is sent as + zero and ignored on receipt, but is included for use by other + technologies. + + o VLAN ID: This carries the 12-bit VLAN identifier for all + subsequent MAC addresses in this sub-TLV, or the value zero if no + VLAN is specified. + + o Number of Group Records: A 1-byte integer that is the number of + group records in this sub-TLV. + + o Group Record: Each group record carries the number of sources. It + then has a 48-bit multicast address followed by 48-bit 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. + +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 remainder of this + section specifies the sub-TLVs that TRILL uses the MT-PORT-CAP TLV to + transport. + + + + + +Eastlake, et al. Standards Track [Page 5] + +RFC 6326 TRILL Use of IS-IS July 2011 + + +2.2.1. The 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 encapsulated data frame. See + [RFC6325], Section 4.6.2, point 8. + + o Outer.VLAN: A copy of the 12-bit outer VLAN ID of the TRILL IIH + frame containing this sub-TLV when that frame was sent, 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. + + 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]: + + + + + + +Eastlake, et al. Standards Track [Page 6] + +RFC 6326 TRILL Use of IS-IS July 2011 + + + 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 for + end station service at the port of the originating IS on which the + 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 + order bit of the first byte of the VLAN bit-map. + + + + + +Eastlake, et al. Standards Track [Page 7] + +RFC 6326 TRILL Use of IS-IS July 2011 + + + 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 Section 4.2.4 of + [RFC6325]. It has the following format: + + +-+-+-+-+-+-+-+-+ + | Type | (1 byte) + +-+-+-+-+-+-+-+-+ + | Length | (1 byte) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Appointment Information (1) | (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. + + o RESV: 4 bits that MUST be sent as zero and ignored on receipt. + + + + + +Eastlake, et al. Standards Track [Page 8] + +RFC 6326 TRILL Use of IS-IS July 2011 + + + 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 + Section 4.4 of [RFC6325], appointing an IS forwarder on a port for + a VLAN not enabled on that port has no effect. + + 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. + +2.3. Sub-TLVs for the Router Capability TLV + + The Router Capability TLV is specified in [RFC4971]. All of the sub- + sections of this Section 2.3 below specify sub-TLVs that can be + carried in the Router Capability TLV for TRILL. + +2.3.1. The TRILL Version Sub-TLV + + The TRILL Version (TRILL-VER) sub-TLV indicates the maximum version + of the TRILL standard supported. By implication, lower versions are + also supported. If this sub-TLV is missing, the originating IS only + supports the base version of the protocol [RFC6325]. + + +-+-+-+-+-+-+-+-+ + | Type | (1 byte) + +-+-+-+-+-+-+-+-+ + | Length | (1 byte) + +-+-+-+-+-+-+-+-+ + | Max-version | (1 byte) + +-+-+-+-+-+-+-+-+ + + o Type: Router Capability sub-TLV type, set to 13 (TRILL-VER). + + o Length: 1. + + o Max-version: Set to maximum version supported. + + + + + + + + + + + + + + + +Eastlake, et al. Standards Track [Page 9] + +RFC 6326 TRILL Use of IS-IS July 2011 + + +2.3.2. The 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 be carried. + + +-+-+-+-+-+-+-+-+ + |Type = NICKNAME| (1 byte) + +-+-+-+-+-+-+-+-+ + | Length | (1 byte) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NICKNAME RECORDS (1) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ................. | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NICKNAME RECORDS (N) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + where each nickname record is of the form: + + +-+-+-+-+-+-+-+-+ + | Nickname.Pri | (1 byte) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tree Root Priority | (2 byte) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Nickname | (2 bytes) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + o Type: Router Capability 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]. + + + + + + + + + + +Eastlake, et al. Standards Track [Page 10] + +RFC 6326 TRILL Use of IS-IS July 2011 + + +2.3.3. The Trees Sub-TLV + + Each IS providing TRILL service uses the TREES sub-TLV to announce + three numbers related to the computation of distribution trees as + specified in Section 4.5 of [RFC6325]. Its format is as follows: + + +-+-+-+-+-+-+-+-+ + |Type = TREES | (1 byte) + +-+-+-+-+-+-+-+-+ + | Length | (1 byte) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Number of trees to compute | (2 byte) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Maximum trees able to compute | (2 byte) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Number of trees to use | (2 byte) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + o Type: Router Capability 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. The 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 + 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: + + + + + + + + + + + +Eastlake, et al. Standards Track [Page 11] + +RFC 6326 TRILL Use of IS-IS July 2011 + + + +-+-+-+-+-+-+-+-+ + |Type=TREE-RT-IDs| (1 byte) + +-+-+-+-+-+-+-+-+ + | Length | (1 byte) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Starting Tree Number | (2 bytes) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Nickname (K-th root) | (2 bytes) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Nickname (K+1 - th root) | (2 bytes) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Nickname (...) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + o Type: Router Capability 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 a 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. The 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 Router Capability 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. + + + + + +Eastlake, et al. Standards Track [Page 12] + +RFC 6326 TRILL Use of IS-IS July 2011 + + + In the set of LSPs originated by an IS, the union of the VLAN ranges + in all occurrences of this sub-TLV MUST be precisely the set of VLANs + for which the originating IS is appointed forwarder on at least one + port, and the VLAN ranges in multiple VLANs sub-TLVs for an IS MUST + NOT overlap unless the information provided about a VLAN is the same + in every instance. However, as a transient state these conditions + may be violated. If a VLAN is not listed in any INT-VLAN sub-TLV for + an IS, that IS is assumed to be uninterested in receiving traffic for + that VLAN. If a VLAN appears in more than one INT-VLAN sub-TLV for + an IS with different information in the different instances, the + following apply: + + - If those sub-TLVs provide different nicknames, it is + unspecified which nickname takes precedence. + - The largest appointed forwarder status lost counter 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) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+ + + + +Eastlake, et al. Standards Track [Page 13] + +RFC 6326 TRILL Use of IS-IS July 2011 + + + o Type: Router Capability sub-TLV type, set to 10 (INT-VLAN). + + o Length: 10 + 6*n, where n is the number of root bridge IDs. + + o Nickname: As specified in [RFC6325], Section 4.2.4.4, this field + may be used to associate a nickname held by the originating IS + with the VLAN range indicated. When not used in this way, it is + set to zero. + + o Interested VLANS: The Interested VLANs field is formatted as shown + below. + + 0 1 2 3 4 - 15 16 - 19 20 - 31 + +----+----+----+----+------------+----------+------------+ + | M4 | M6 | R | R | VLAN.start | RESV | VLAN.end | + +----+----+----+----+------------+----------+------------+ + + - M4, M6: These bits indicate, respectively, that there is an + IPv4 or IPv6 multicast router on a link for which the + originating IS is appointed forwarder for every VLAN in the + indicated range as specified in [RFC6325], Section 4.2.4.4, + item 5.1. + + - R, RESV: These reserved bits MUST be sent as zero and are + ignored on receipt. + + - VLAN.start and VLAN.end: This VLAN ID range is inclusive. A + range of one VLAN ID is indicated by setting them both to that + VLAN ID value. + + 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 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, only + one spanning tree root could be seen on any particular port, there + may be multiple ports in the same VLAN connected to different + bridged LANs with different spanning tree roots. + + + + + + +Eastlake, et al. Standards Track [Page 14] + +RFC 6326 TRILL Use of IS-IS July 2011 + + + An INT-VLAN sub-TLV asserts that the information provided (multicast + router attachment, appointed forwarder status lost counter, and root + bridges) is the same for all VLANs in the range specified. If this + is not the case, the range MUST be split into subranges meeting this + criteria. It is always safe to use sub-TLVs with a "range" of one + VLAN ID, but this may be too verbose. + +2.3.7. The VLAN Group Sub-TLV + + The VLAN Group Router Capability 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 announcing IS between + the listed VLANs. It is structured as follows: + + +-+-+-+-+-+-+-+-+ + |Type=VLAN-GROUP| (1 byte) + +-+-+-+-+-+-+-+-+ + | Length | (1 byte) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RESV | Primary VLAN ID | (2 bytes) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RESV | Secondary VLAN ID | (2 bytes) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | more Secondary VLAN IDs ... (2 bytes each) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + o Type: Router Capability sub-TLV type, set to 14 (VLAN-GROUP). + + o Length: 4 + 2*n, where n is the number of secondary VLAN ID + fields, which 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.4. MTU Sub-TLV of the Extended Reachability TLV + + 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 TLV (type 22). + + + + +Eastlake, et al. Standards Track [Page 15] + +RFC 6326 TRILL Use of IS-IS July 2011 + + + +-+-+-+-+-+-+-+-+ + | Type = MTU | (1 byte) + +-+-+-+-+-+-+-+-+ + | Length | (1 byte) + +-+-+-+-+-+-+-+-+ + |F| Reserved | (1 byte) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MTU | (2 bytes) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + o Type: Extended Reachability 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 Reserved: 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| RESV | (1 byte) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Neighbor RECORDS (1) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ................. | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Neighbor RECORDS (N) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + +Eastlake, et al. Standards Track [Page 16] + +RFC 6326 TRILL Use of IS-IS July 2011 + + + The information present for each neighbor is as follows: + + +-+-+-+-+-+-+-+-+ + |F| RESV | (1 bytes) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MTU | (2 bytes) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+ + | MAC Address | (6 bytes) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+ + + o Type: TLV Type, set to TRILL Neighbor TLV 145. + + o Length: 1 + 9*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 RESV: These 7 bits are reserved use and MUST be sent as zero and + ignored on receipt. + + 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 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 MAC Address: The MAC address of the neighbor as in the IS Neighbor + TLV (6). + + 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 RBridge 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. + + + + +Eastlake, et al. Standards Track [Page 17] + +RFC 6326 TRILL Use of IS-IS July 2011 + + +3. The MTU PDUs + + Two PDUs are added to IS-IS, the MTU-probe and MTU-ack PDUs. They + are used to optionally determine the MTU on a link between ISs as + specified in [RFC6325], Section 4.3.2. + + The MTU PDUs have the IS-IS PDU common header (up through the Maximum + Area Addresses byte) with two new PDU Type numbers, one each, as + listed in Section 6. They also have a 20-byte common fixed MTU PDU + header as shown below. + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | PDU Length | (2 bytes) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+ + | Probe ID (6 bytes) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+ + | Probe Source ID (6 bytes) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+ + | Ack Source ID (6 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 arbitrary 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. An IS issuing an + MTU-ack sets this field to its System ID. + + 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 will be + quite small compared with their minimum length (minimum 1470-byte MTU + on an 802.3 link, for example), so this will not be a problem. + + + + +Eastlake, et al. Standards Track [Page 18] + +RFC 6326 TRILL Use of IS-IS July 2011 + + +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] + specifies 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 Section 4.4 of [RFC6325] and 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 (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 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. + + + + + + + + +Eastlake, et al. Standards Track [Page 19] + +RFC 6326 TRILL Use of IS-IS July 2011 + + +5. IANA Considerations + + IANA has allocated the existing registry code points listed in + Section 5.1 and created two new registries with the initial contents + as described in Section 5.2. + +5.1. Allocations from Existing Registries + + This document specifies two new 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 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 NUMBER + + GADDR-TLV 2.1 142 - X - * + TRILL Neighbor TLV 2.5 145 X - - * + + This document specifies eleven new sub-TLVs from existing sub-TLV + sequences -- namely, VLAN-FLAGS, Enabled-VLANs, AppointedFwrdrs, + TRILL Version (TRILL-VER), NICKNAME, TREES, TREE-RT-IDs, + TREE-USE-IDs, INT-VLAN, VLAN-GROUP, and MTU. The TLVs in which these + sub-TLVs occur are shown in the table below along with the section of + this document where they are discussed. + + Those sub-TLVs with an "X" in the column labeled "MT Port Capabil." + are sub-TLVs of TLV 143 [RFC6165], the MT-PORT-CAP-TLV. Those sub- + TLVs with an "X" in the column labeled "Router Capabil." are sub-TLVs + of TLV 242, the IS-IS Router CAPABILITY TLV. Those sub-TLVs with an + "X" in the column labeled "Extended IS Reach" are sub-TLVs of TLV 22, + the Extended IS reachability TLV. + + The final "NUM" column indicates the permitted number of occurrences + of the sub-TLV cumulatively within all occurrences of their TLV in + that TLV's carrying PDU (or set of PDUs in the case of LSP), as + follows: + + + + + + + +Eastlake, et al. Standards Track [Page 20] + +RFC 6326 TRILL Use of IS-IS July 2011 + + + 0-1 = MAY occur zero or one times. If it occurs more than once, + results are unspecified. + 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 "NUM" columns are irrelevant to the + IANA sub-registries. + + Section sub- MT Port Router Extended NUM + TLV# Capabil. Capabil. IS Reach + VLAN-FLAGS 2.2.1 1 X - - 1 + Enabled-VLANs 2.2.2 2 X - - * + AppointedFwrdrs 2.2.3 3 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 - * + MTU 2.4 28 - - X 0-1 + +5.2. New Sub-Registries Created + + This document creates two new IS-IS PDUs -- namely, the MTU-PROBE-PDU + and MTU-ACK-PDU, as described in Section 3. IANA assigned new PDU + types to these PDUs and reflect them in a newly created PDU registry + (see Appendix A). + + MTU-PROBE-PDU PDU Number: 23 + MTU-ACK-PDU PDU Number: 28 + + IANA created a new sub-TLV IS-IS sub-registry for sub-TLVs within the + Group Address (GADDR) TLV and specified an initial sub-TLV within + that registry -- namely, the Group MAC Address (GMAC-ADDR) sub-TLV + (1). The GMAC-ADDR sub-TLV may occur 0, 1, or more times in a GADDR + TLV. + + The initial sub-registry is shown below. + + Registry Name: IS-IS Group Address Type Codes for TLV 10 + Reference: This document + Registration Procedures: Expert Review [RFC5226] + + + + + + + +Eastlake, et al. Standards Track [Page 21] + +RFC 6326 TRILL Use of IS-IS July 2011 + + + Registry: + Value Group Address Type Code Reference + ------- ----------------------------- --------- + 0 Reserved This document + 1 GMAC-ADDR This document + 2-254 Unassigned This document + 255 Reserved This document + +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. References + +7.1. 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. + + [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. + + [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. + + + + +Eastlake, et al. Standards Track [Page 22] + +RFC 6326 TRILL Use of IS-IS July 2011 + + + [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, July 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, July 2011. + +7.2. Informative References + + [802.1Q-2005] "IEEE Standard for Local and metropolitan area networks + / Virtual Bridged Local Area Networks", 802.1Q-2005, 19 + May 2006. + + [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. + +8. Acknowledgements + + The authors gratefully acknowledge the contributions and review by + the following: 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. + + + + + + + + + + + + + + +Eastlake, et al. Standards Track [Page 23] + +RFC 6326 TRILL Use of IS-IS July 2011 + + +Appendix A. Initial IS-IS PDU Registry + + The following is the suggested initial IS-IS PDU registry before + MTU-PROBE-PDU and MTU-ACK-PDU, which should be added with this + document as REFERENCE: + + Registry Name: IS-IS PDUs + Reference: This document + Registration Procedures: IETF Review [RFC5226] + + MNEMONIC PDU# REFERENCE + + Unassigned 0-14 + L1-LAN-HELLO-PDU 15 [ISO-10589] + L2-LAN-HELLO-PDU 16 [ISO-10589] + P2P-HELLO-PDU 17 [ISO-10589] + L1-LSP-PDU 18 [ISO-10589] + Unassigned 19 + L2-LSP-PDU 20 [ISO-10589] + Unassigned 21-23 + L1-CSNP-PDU 24 [ISO-10589] + L2-CSNP-PDU 25 [ISO-10589] + L1-PSNP-PDU 26 [ISO-10589] + L2-PSNP-PDU 27 [ISO-10589] + Unassigned 28-31 + + + + + + + + + + + + + + + + + + + + + + + + + + +Eastlake, et al. Standards Track [Page 24] + +RFC 6326 TRILL Use of IS-IS July 2011 + + +Authors' Addresses + + Donald Eastlake + Huawei + 155 Beaver Street + Milford, MA 01757 USA + + Phone: +1-508-333-2270 + EMail: d3e3e3@gmail.com + + + Ayan Banerjee + Cisco Systems + 170 West Tasman Drive + San Jose, CA 95134 USA + + EMail: ayabaner@cisco.com + + + Dinesh Dutt + Cisco Systems + 170 West Tasman Drive + San Jose, CA 95134-1706 USA + + Phone: +1-408-527-0955 + EMail: ddutt@cisco.com + + + Radia Perlman + Intel Labs + 2200 Mission College Blvd. + Santa Clara, CA 95054-1549 USA + + Phone: +1-408-765-8080 + EMail: Radia@alum.mit.edu + + + Anoop Ghanwani + Brocade + 130 Holger Way + San Jose, CA 95134 USA + + Phone: +1-408-333-7149 + EMail: anoop@alumni.duke.edu + + + + + + + +Eastlake, et al. Standards Track [Page 25] + |