Network Working Group A. Banerjee, Ed. Internet-Draft Cisco Systems Intended status: Standards Track July 11, 2009 Expires: January 12, 2010 Extensions to IS-IS for Layer-2 Systems draft-ietf-isis-layer2-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 12, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document specifies the IS-IS extensions necessary to support multi-link IPv4 and IPv6 networks, as well as to provide true link state routing to any protocols running directly over layer 2. While Banerjee, et al. Expires January 12, 2010 [Page 1] Internet-Draft Layer-2-IS-IS July 2009 supporting this concept involves several pieces, this document only describes extensions to IS-IS. We leave it to the systems using these IS-IS extensions to explain how the information carried in IS-IS is used. Banerjee, et al. Expires January 12, 2010 [Page 2] Internet-Draft Layer-2-IS-IS July 2009 Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. TLV and sub-TLV Enhancements to IS-IS . . . . . . . . . . . . 4 2.1. The MAC-Reachability TLV . . . . . . . . . . . . . . . . . 5 2.2. The Group Address TLV . . . . . . . . . . . . . . . . . . 6 2.2.1. The Group MAC Address sub-TLV . . . . . . . . . . . . 6 2.2.2. The Group IP Address sub-TLV . . . . . . . . . . . . . 8 2.2.3. The Group IPv6 Address sub-TLV . . . . . . . . . . . . 10 2.3. Multi Topology aware Port Capability TLV . . . . . . . . . 12 2.3.1. The Special VLANs and Flags sub-TLV . . . . . . . . . 13 2.3.2. Enabled VLANs sub-TLV . . . . . . . . . . . . . . . . 14 2.3.3. Appointed Forwarders sub-TLV . . . . . . . . . . . . . 14 2.3.4. Hop-by-Hop Options (HBHOPT) sub-TLV . . . . . . . . . 15 2.3.5. Base VLAN-Identifiers sub-TLV . . . . . . . . . . . . 16 2.4. Sub-TLVs for the Router Capability TLV . . . . . . . . . . 18 2.4.1. The TRILL Version sub-TLV . . . . . . . . . . . . . . 18 2.4.2. The Nickname sub-TLV . . . . . . . . . . . . . . . . . 18 2.4.3. The Trees sub-TLV . . . . . . . . . . . . . . . . . . 19 2.4.4. The Tree Roots Identifier Sub-TLV . . . . . . . . . . 20 2.4.5. The Tree Used Identifier Sub-TLV . . . . . . . . . . . 21 2.4.6. Interested VLANs and Spanning Tree Roots sub-TLV . . . 22 2.4.7. The VLAN Group sub-TLV . . . . . . . . . . . . . . . . 23 2.4.8. The Ingress-to-Egress Options (ITEOPT) sub-tlv . . . . 24 2.5. Multi Topology Aware Capability TLV . . . . . . . . . . . 25 2.5.1. SPB Instance sub-TLV . . . . . . . . . . . . . . . . . 26 2.5.2. Service Identifier and Unicast Address sub-TLV . . . . 29 2.6. SPB Link Metric sub-tlv . . . . . . . . . . . . . . . . . 30 3. The Multicast Group PDU . . . . . . . . . . . . . . . . . . . 31 3.1. The Multicast Group Partial Sequence Number PDU . . . . . 32 3.2. The Multicast Group Complete Sequence Number PDU . . . . . 32 3.3. Enhancements to the flooding process . . . . . . . . . . . 32 3.4. Enhancements to the maximum sequence number reached . . . 33 4. Considerations for Using L2 Information in IS-IS . . . . . . . 33 4.1. Building SPF Trees with Layer 2 Information . . . . . . . 33 4.2. Designated Intermediate Routers . . . . . . . . . . . . . 33 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 6. Security Considerations . . . . . . . . . . . . . . . . . . . 34 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 35 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 9.1. Normative References . . . . . . . . . . . . . . . . . . . 37 9.2. Informative References . . . . . . . . . . . . . . . . . . 37 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37 Banerjee, et al. Expires January 12, 2010 [Page 3] Internet-Draft Layer-2-IS-IS July 2009 1. Overview There are a number of systems (for example, [RBRIDGES], [802.1aq]) that use layer 2 addresses carried in a link state routing protocol, specifically IS-IS [IS-IS] [RFC1195], to provide true layer 2 routing in specific environments. This document specifies a set of TLVs and sub-TLVs to be added to [IS-IS] level 1 PDUs, and three new PDU types, to support these proposed systems. Some of these TLVs are generic layer 2 additions and some are specific to [RBRIDGES] or to [802.1aq]. This draft does not propose any new forwarding mechanisms using this additional information carried within IS-IS. This document specifies additional TLVs and sub-TLVs, to carry unicast and multicast attached address information. It also proposes additional TLVs and sub-TLVs to carry information as required by the IETF RBridge and IEEE 802.1aq protocols. This document specifies three new IS-IS PDUs, the Multicast Group (MGROUP) PDU, for carrying a list of attached or joined multicast groups. The Multicast Group Complete Sequence Number (MGROUP-CSNP) PDU and the Multicast Group Partial Sequence Number (MGROUP-PSNP) PDU packets are also defined to be used with the new MGROUP-PDU to perform database exchange on the MGROUP PDU packets. 1.1. Terminology The term "Hello" or "Hello PDU" in this document, when not further qualified, includes both LAN IIH PDU and P2P IIH PDU. 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 RFC 2119. 2. TLV and sub-TLV Enhancements to IS-IS In this section we describe the enhancements that are being proposed for the TLV and sub-TLVs as needed by Layer-2 technologies. In particular, Sections 2.1 specifies the MAC-Reachability TLV; Section 2.2 specifies the Group Address TLV and its sub-TLVs; Section 2.3 specifies the Port Capabilities TLV. These are expected to be of generic use in current and future Layer-2 uses of IS-IS. We propose enhancements to the Capability TLV in Section 2.4 and in Section 2.5 we propose a Multi Topology aware Capability TLV with its sub-TLVs. Banerjee, et al. Expires January 12, 2010 [Page 4] Internet-Draft Layer-2-IS-IS July 2009 2.1. The MAC-Reachability TLV The MAC-Reachability (MAC-RI) TLV is IS-IS TLV type 141 and has the following format: +-+-+-+-+-+-+-+-+ | Type= MAC-RI | (1 byte) +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+ | Confidence | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Topology-Id/ Nickname-Id | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESV | VLAN-ID | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC (1) (6 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ................. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC (N) (6 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: TLV Type, set to 141 (MAC-RI). o Length: Total number of bytes contained in the value field given by 5 + 6*n bytes. o Confidence: This carries an 8-bit quantity indicating the confidence level in the MAC addresses being transported. Whether this field is used, and its semantics if used, are further defined by the specific protocol using Layer-2-IS-IS. If not used, it must be set to zero on transmission and be ignored on receipt. o Topology-Id/Nickname-Id: Depending on the technology in which it is used, this carries the topology-id or nickname-id. When this field is set to zero this implies that the MAC addresses are reachable across all topologies or across all nicknames of the originating IS. 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 MAC addresses in this TLV, or the value zero if no VLAN is specified. Banerjee, et al. Expires January 12, 2010 [Page 5] Internet-Draft Layer-2-IS-IS July 2009 o MAC(i): This is the 48-bit MAC address reachable from the IS that is announcing this TLV. The MAC-RI TLV is carried in a standard Level 1 link state PDU. It MUST contain only unicast addresses. 2.2. The Group Address TLV The Group Address (GADDR) TLV is IS-IS TLV type 142 [TBD] and has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type = GADDRTLV| Length | sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: TLV Type, set to GADDR-TLV 142 [TBD]. o Length: Total number of bytes contained in the value field, which includes the length of the sub-tlvs carried in this TLV. o sub-TLVs: The Group Address TLV value contains sub-TLVs formatted as described in [RFC5305]. The sub-TLVs for this TLV are specified in the following subsections. The GADDR TLV is carried within Multicast Group Level 1 link state PDU. 2.2.1. The Group MAC Address sub-TLV The Group MAC Address (GMAC-ADDR) sub-TLV is IS-IS sub-TLV type 1 within the GADDR TLV and has the following format: Banerjee, et al. Expires January 12, 2010 [Page 6] Internet-Draft Layer-2-IS-IS July 2009 +-+-+-+-+-+-+-+-+ | Type=GMAC-ADDR| (1 byte) +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+ | Confidence | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Topology-Id/ Nickname-Id | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESV | VLAN-ID | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Num Group Recs | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GROUP RECORDS (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ................. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GROUP RECORDS (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where each group record is of the form: +-+-+-+-+-+-+-+-+ | RESERVED | (1 byte) +-+-+-+-+-+-+-+-+ | 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: sub-TLV Type, set to 1 (GMAC-ADDR) of length 1 byte. o Length: Total number of bytes contained in the value field. o Confidence: This carries an 8-bit quantity indicating the confidence level in the MAC addresses being transported. Whether this field is used, and its semantics if used, are further defined by the specific protocol using Layer-2-IS-IS. If not used, it must be set to zero on transmission and be ignored on receipt. Banerjee, et al. Expires January 12, 2010 [Page 7] Internet-Draft Layer-2-IS-IS July 2009 o Topology-Id/Nickname-Id: Depending on the technology in which it is used, this carries the topology-id or nickname-id. When this field is set to zero this implies that the MAC addresses are reachable across all topologies or across all nicknames of the originating IS. 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 MAC addresses in this 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 TLV. o Group Record: Each group record has a reserved space and followed by the number of sources, each of length 1 byte. It then has a 48-bit multicast Group Address followed by 48-bit source MAC addresses. An address being a group multicast address or unicast source address can be checked using the multicast bit in the address. 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 repeated in different sub-tlvs. The GMAC-ADDR sub-TLV is carried within the GADDR TLV and MUST be carried in a standard Level 1 link state MGROUP PDU. 2.2.2. The Group IP Address sub-TLV The Group IP Address (GIP-ADDR) sub-TLV is IS-IS TLV type 2 and has the following format: Banerjee, et al. Expires January 12, 2010 [Page 8] Internet-Draft Layer-2-IS-IS July 2009 +-+-+-+-+-+-+-+-+ | Type=GIP-ADDR | +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+ | Confidence | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Topology-Id/ Nickname-Id | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESV | VLAN-ID | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Num Group Recs | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GROUP RECORDS (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ................. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GROUP RECORDS (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where each group record is of the form: +-+-+-+-+-+-+-+-+ | RESERVED | (1 byte) +-+-+-+-+-+-+-+-+ | Num of Sources| (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Address (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source 1 Address (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source 2 Address (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source M Address (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: sub-TLV Type, set to 2 (GIP-ADDR). o Length: Total number of bytes contained in the value field of the TLV. o Confidence: This carries an 8-bit quantity indicating the confidence level in the IP addresses being transported. Whether this field is used, and its semantics if used, are further defined by the specific protocol using Layer-2-IS-IS. If not used, it must be set to zero on transmission and be ignored on receipt. Banerjee, et al. Expires January 12, 2010 [Page 9] Internet-Draft Layer-2-IS-IS July 2009 o Topology-Id/Nickname-Id: Depending on the technology in which it is used, this carries the topology-id or nickname-id. When this field is set to zero this implies that the MAC addresses are reachable across all topologies or across all nicknames of the originating IS. 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 MAC addresses in this 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 TLV. o Group Record: Each group record has a reserved space and followed by the number of sources, each of length 1 byte. It is followed by a 32-bit IPv4 Group Address followed by 32-bit 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 repeated in different sub-tlvs. The GIP-ADDR TLV is carried within the GADDR TLV and MUST be carried in a standard Level 1 link state MGROUP PDU. 2.2.3. The Group IPv6 Address sub-TLV The Group IPv6 Address (GIPV6-ADDR) TLV is IS-IS sub-TLV type 3 and has the following format: Banerjee, et al. Expires January 12, 2010 [Page 10] Internet-Draft Layer-2-IS-IS July 2009 +-+-+-+-+-+-+-+-+ |Type=GIPv6-ADDR| +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+ | Confidence | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Topology-Id/ Nickname-Id | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESV | VLAN-ID | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Num Group Recs | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GROUP RECORDS (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ................. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GROUP RECORDS (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where each group record is of the form: +-+-+-+-+-+-+-+-+ | RESERVED | (1 byte) +-+-+-+-+-+-+-+-+ | Num of Sources| (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Address (16 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source 1 Address (16 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source 2 Address (16 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source M Address (16 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: sub-TLV Type, set to 3 (GIPV6-ADDR). o Length: Total number of bytes contained in the value field. o Confidence: This carries an 8-bit quantity indicating the confidence level in the IPv6 addresses being transported. Whether this field is used, and its semantics if used, are further defined by the specific protocol using Layer-2-IS-IS. If not used, it must be set to zero on transmission and be ignored on receipt. o Topology-Id/Nickname-Id: Depending on the technology in which it is used, this carries the topology-id or nickname-id. When this Banerjee, et al. Expires January 12, 2010 [Page 11] Internet-Draft Layer-2-IS-IS July 2009 field is set to zero this implies that the MAC addresses are reachable across all topologies or across all nicknames of the originating IS. 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 MAC addresses in this TLV, or the value zero if no VLAN is specified. o Number of Group Records: This of length 1 byte and lists the number of group records in this TLV. o Group Record: Each group record has a reserved space and followed by the number of sources, each of length 1 byte. It is followed by a 128-bit multicast IPv6 Group Address followed by 128-bit 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 repeated in different sub-tlvs. The GIPV6-ADDR sub-TLV is carried within the GADDR TLV and MUST be carried in a standard Level 1 link state MGROUP PDU. 2.3. Multi Topology aware Port Capability TLV The Multi Topology aware Port Capability (MT-PORT-CAP) is an IS-IS TLV type 143 [TBD], and has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=MT PORTCAP| Length |O|R|R|R| Topology Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: TLV Type, set to MT-PORT-CAP TLV 143 [TBD]. o Length: Total number of bytes contained in the value field, including the length of the sub-TLVs carried in this TLV. o O bit: The overload bit that follows the semantics associated with an overloaded intermediate system. o Topology Identifier: MT ID is a 12-bit field containing the MT ID of the topology being announced. This field when set to zero implies that it is being used to carry base topology information. Banerjee, et al. Expires January 12, 2010 [Page 12] Internet-Draft Layer-2-IS-IS July 2009 In TRILL this value is set to ZERO, however, in IEEE SPB and SPBB, it may be non-zero. o sub-TLVs: The MT aware Port Capabilities TLV value contains sub- TLVs formatted as described in [RFC5305]. They are defined in the next sections. The MT aware PORT-CAP-TLV MUST be carried only within a LAN IIH PDU, or a P2P IIH PDU. It may occur multiple times in a Hello PDU. 2.3.1. The Special VLANs and Flags sub-TLV The Special VLANs and Flags (VLAN and Flags) sub-TLV MUST appear exactly once in a MT aware Port Capability TLV in every LAN IIH PDU. It has the following format: 0 1 2 3 4 - 15 16 - 19 20 - 31 +----+----+----+----+------------+----------+------------+ | AF | AC | VM | BY | Outer.VLAN | Reserved | Desig.VLAN | +----+----+----+----+------------+----------+------------+ o Type: TLV Type, set to VLAN and Flags sub-TLV 1 [TBD]. o Length: 4 - Number of bytes contained in the value field. o The first and second bytes have a copy of the Outer VLAN ID associated with the Hello frame when it was sent. The lower 4 bits of the first byte give the upper ID bits of the VLAN ID and the second byte gives the lower VLAN ID bits. o The upper 4 bits of the first byte are flag bits as shown. The AF bit, if one, indicates that the sending Intermediate System believes it is Appointed Forwarder for the VLAN and port on which the Hellos was sent. The AC bit, if one, indicates that the sending port is configured as an access port. The VM bit, if a one, indicates that the sending Intermediate System has detected VLAN mapping within the link. The BY bit, if set, indicates bypass psuedonode. o The third and forth bytes give the Designated VLAN for the link. The lower 4 bits of the third byte give the upper ID bits of the Designated VLAN and the forth byte gives the lower VLAN ID bits. The upper 4 bits of the third byte are reserved and MUST be sent as zero and ignored on receipt. The VLAN and Flags sub-TLV is carried within the MT aware PORT-CAP TLV and MUST be carried in LAN IIH PDU. It MUST NOT be carried within a P2P IIH PDU. Banerjee, et al. Expires January 12, 2010 [Page 13] Internet-Draft Layer-2-IS-IS July 2009 2.3.2. Enabled VLANs sub-TLV The Enabled VLAN sub-TLV specifies the VLANs enabled for end station service at the port on which the Hello was sent. o Type: sub-TLV Type, set to Enabled VLANs sub-TLV 2 [TBD]. o Length: variable, depending on contents described next. o The minimum size of the value is 3 bytes. The third and subsequent bytes provide a bit map of enabled VLANs starting at the VLAN ID indicated in the first two bytes. The lower order four bits of the first byte give the upper bits of the starting VLAN ID and the second byte gives the lower bits of that VLAN ID. The upper four bits of the first byte are reserved and MUST be sent as zero and ignored on receipt. The highest order bit of the third byte indicates the VLAN equal to the starting ID while the lowest order bit of the third byte indicated that ID plus 7. For example, VLANs 1 and 14 being enabled for end station service could be encoded in 4-bytes value 0x00 0x01 0x80 0x04 or, alternatively, as 0x00 0x00 0x40 0x02. This sub-TLV may occur more than once in a Hello and a VLAN is enabled for end station service on the port where the Hellos was sent if this is indicated by any occurrence in the Hello. For example, a receiver could allocate a 512-byte buffer and, with appropriate shifting operations, OR in the enabled bits for each subTLV of this type it finds in a Hello to derive the complete bit map of these VLANs. The Enabled VLAN sub-TLV is carried within the MT aware PORT-CAP TLV and MUST be carried in LAN IIH PDU. It MUST NOT be carried within a P2P IIH PDU. 2.3.3. Appointed Forwarders sub-TLV The Appointed Forwarder sub-TLV provides the mechanism by which the Designated Intermediate System can inform other Intermediate Systems on the link that they are the designated VLAN-x forwarder for that link for one or more ranges of VLAN IDs. o Type: sub-TLV Type, set to Enabled VLANs sub-TLV 3 [TBD]. o Length: The size of the value is 6*n bytes where there are n appointments. Each 6-byte part of the value is formatted as follows: Banerjee, et al. Expires January 12, 2010 [Page 14] Internet-Draft Layer-2-IS-IS July 2009 +----------------+-----+-----+---------+-----+----+---------+ | byte 1 - 2 | byte 3 | byte 4 | byte 5 | byte 6 | +----------------+-----+-----+---------+-----+----+---------+ | Appointee Nick | Res | Start VLAN ID | Res | End VLAN ID | +----------------+-----+-----+---------+-----+----+---------+ o The appointed forwarder Intermediate System is specified by its nickname in the first two bytes. o The "Res" fields of 4 bits each are reserved and MUST be sent as zero and ignored on receipt. The VLAN range given is inclusive. To specify a single VLAN, that VLAN ID appears as both the start and end VLAN. The Intermediate System whose nickname is given is appointed forwarder for those VLANs for which it has end station service enabled (see item 2 above) in the inclusive range. For example, assume an Intermediate System with end station service enabled on VLANs 100, 101, 199, and 200 (and possibly other VLANs less than 100 or greater than 200), but not enabled for VLANs 102 through 198. It could be appointed forwarder for these four VLANs through either (1) a single 6-byte value sequence with start and end VLAN IDs of 100 and 200, or (2) a 12-byte value sequence with start and end VLAN IDs of 100 and 101 in the first part and 199 and 200 in the second part. An Intermediate System's nickname may occur as appointed forwarder for multiple VLAN ranges within the same or different Port Capability TLVs within a Designated Intermediate Systems's Hello. In the absence of appointed forwarder sub-TLVs referring to a VLAN, the Designated Intermediate System acts as the appointed forwarder for that VLAN if end station service is enabled. The Appointed Forwarder sub-TLV is carried within the MT aware PORT- CAP TLV and MUST be carried in a LAN IIH PDU. This MUST NOT be carried in a P2P IIH PDU. 2.3.4. Hop-by-Hop Options (HBHOPT) sub-TLV By including this sub-TLV within one or more MT aware Port Capability TLVs in its Hellos, an Intermediate System can advertise the Hop-by- Hop options it supports on the port through which it sends the Hello. This sub-TLV may appear zero or more times within a MT aware Port Capability TLV. By default, in the absence of any HBHOPT sub-TLVs, no Hop-by-Hop options are supported. There are two types of Hop-by-Hop option encoding within the TRILL Header: bit options and TLV encoded options. Banerjee, et al. Expires January 12, 2010 [Page 15] Internet-Draft Layer-2-IS-IS July 2009 The bit-encoded options supported are indicated by an HBHOPT sub-TLV of length 3: an initial value byte of 0xFF followed by four bytes in which each bit indicates that the corresponding bit option is implemented; in those four bytes the top two bits (0xC0000000) are critical option summary bits that all RBridges MUST understand. Those two bits are reserved in the HBHOPT sub-TLV and must be sent as zero are ignored on receipt. The implementation of a TLV encoded option is indicated by an HBHOPT sub-TLV whose value starts with a byte equal to the first byte of the option. Such HBHOPT sub-TLVs may have additional value bytes further indicating how the option is supported as specified with the option's definition, for example a list of supported security algorithms. +-+-+-+-+-+-+-+-+ | Type = HBHOPT | +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+ | Option | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option dependent variable length information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: sub-TLV Type, set to Hop-by-Hop sub-TLV 4 [TBD]. o Length: variable, minimum 1. o Value: The first byte of the option followed by option dependent information. 2.3.5. Base VLAN-Identifiers sub-TLV This sub-TLV is added to an IIH PDU to indicate the algorithms for the VIDs and the Base VIDs and VIDs or Backbone-VIDs (B-VIDs) are in use. This information should be the same on all bridges in the topology identified by MT-PORT-CAP TLV it is being carried. Discrepancies between neighbours with respect to this sub-TLV are temporarily allowed but the Base-VID must agree and use a spanning tree algorithm. Banerjee, et al. Expires January 12, 2010 [Page 16] Internet-Draft Layer-2-IS-IS July 2009 +-+-+-+-+-+-+-+-+ |Type = B-VID | +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+ |M|B| RESERVED | (1 byte) +-+-+-+-+-+-+-+-+-------------------------------- | VID Tuple (1) (4 bytes) | +-----------------------------------------------+ | ......................... | +-----------------------------------------------+ | VID Tuples (N) (4 bytes) | +-----------------------------------------------+ o Type: sub-TLV Type, set to Base-VALN-ID sub-TLV 5 [TBD]. o Length: The size of the value is VID Tuples*4 + 1 bytes. Each 4-byte part of the N-VID tuple is formatted as follows: 0 1 - 3 4 - 15 16 - 19 20 - 31 +-+----------+-------+-----------+------------+ |A| Reserved | VID | Algorithm | B-VID | +-+----------+-------+-----------+------------+ o The M bit when set indicates that the Mode is Shortest Path VIDs one VID per tree. When clear this bit indicates that this is using single VIDs. Neighboring bridges must have matching configuration or the adjacency is rejected. o The B Bit when set indicates this is Backbone Bridging alternatively when clear this bit indicates this is Shortest path bridging. o Combinations of the M and B bits are specified in the [IEEE 802.1aq]. o Algorithm: Specifies the tie breaking algorithm to be used for this VID. Currently only the following values are supported: * ALG = 0 a spanning tree. * ALG = 1 the Low PATHID algorithm is used for this VID. * ALG = 2 the High PATHID algorithm is used. o A bit when set declares this an SPVID with auto allocation. Banerjee, et al. Expires January 12, 2010 [Page 17] Internet-Draft Layer-2-IS-IS July 2009 o VID is the VID for which the given algorithm applies, see [IEEE 802.1aq]. o B-VID is the B-VID for which the given algorithm applies, see [IEEE 802.1aq]. o The "Reserved" fields MUST be sent as zero and ignored on receipt. The Base VLAN-Identifier sub-TLV is carried within the MT aware PORT- CAP TLV and this is carried in a IIH PDU. 2.4. Sub-TLVs for the Router Capability TLV The Router Capability TLV is an optional TLV [RFC 4971] that may be generated by the originating Intermediate System. We specify these additional sub-TLVs that can be carried in it. These sub-TLVs announce the capabilities of the Intermediate System for the entire IS-IS routing domain. 2.4.1. The TRILL Version sub-TLV The TRILL Version (TRILL-VER) sub-TLV indicates support of TRILL Versions. The device announces the maximum version of TRILL, it is capable of supporting, including lower versions. In the event, this sub-TLV is missing, this implies that the node can only support the base version of the protocol. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | Max-version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: sub-TLV Type, set to 5 (TRILL-VER). o Length: 2 - Total number of bytes contained in the TLV. o Reserved: Set to zero on transmission and ignored on receipt. o Max-version: Set to application dependent values. 2.4.2. The Nickname sub-TLV The Nickname (NICK) sub-TLV carries information about the nicknames of the advertising device, along with information about its priority to hold those nicknames. The Nickname sub-TLV MUST be carried within the Router CAPABILITY TLV in a level-1 non-pseudo-node LSP generated by the originating IS. Banerjee, et al. Expires January 12, 2010 [Page 18] Internet-Draft Layer-2-IS-IS July 2009 +-+-+-+-+-+-+-+-+ |Type = NICKNAME| +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NICKNAME RECORDS (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ................. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NICKNAME RECORDS (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where each nickname record is of the form: +-+-+-+-+-+-+-+-+-+ | Priority | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nickname | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: TLV Type, set to 6 (NICK). o Length: Total number of bytes contained in the TLV. o Priority: Set to application dependent values. o Nickname: This is an unsigned 16-bit integer that gives device identifier or alias. Each nickname record consists of a one-byte priority set to application dependent values, and two bytes of device identifier or alias (i.e., actual nickname). 2.4.3. The Trees sub-TLV The Trees sub-TLV MUST occur only once and can be carried within the Router CAPABILITY TLV in a level-1 non-pseudo-node LSP generated by the originating IS. Each device announces four numbers: its own priority to be a multi-destination frame distribution tree root; the number of trees it dictates that all other Intermediate Systems in the campus compute if it is the highest priority tree root; the maximum number of trees it is able to compute; and the number of distribution trees it wishes to be able to use in forwarding multi- destination traffic. Once a node receives a new LSP, it runs an election algorithm, independently of the other nodes in the network, to determine if it is the highest priority root. The node that announced the Banerjee, et al. Expires January 12, 2010 [Page 19] Internet-Draft Layer-2-IS-IS July 2009 numerically highest priority to become a tree root is elected the to be the highest priority tree root. If two devices advertise the same priority, the device with the higher system ID has the higher priority to be a tree root. The elected highest priority tree root dictates the number of distribution tree roots to be used in the network domain and can list those roots in the tree roots identifier sub-TLV. +-+-+-+-+-+-+-+-+ |Type = TREE | +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tree Root Priority | (2 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of trees to compute | (2 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum trees able to compute | (2 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of trees to use | (2 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: sub-TLV Type, set to 7 (TREE). o Length: 6 : Total number of bytes contained in the value field. o Tree Root Pri: This is an unsigned 16-bit integer that gives the value of the priority with which this node wants to be the highest priority root node in the Layer-2 domain. o Number of trees to compute: This is an unsigned 16-bit integer that gives the requested number of distribution trees for multi- destination frames that will be in use in the Layer-2 domain, if this device becomes the highest priority tree root in the domain. o Maximum number of tree able to compute: This is an unsigned 16-bit integer that give the maximum number of threes that the originating IS is able to compute for the campus. o Number of trees to use: This is an unsigned 16-bit integer that gives the number of distribution trees the originating IS wishes to be able to use. 2.4.4. The Tree Roots Identifier Sub-TLV The tree root identifier sub-TLV is is an ordered list of nicknames. When originated by the Intermediate System which is the highest priority tree root, this list is the tree roots for which other Banerjee, et al. Expires January 12, 2010 [Page 20] Internet-Draft Layer-2-IS-IS July 2009 Intermediate Systems are required to compute trees. If this information is spread across multiple sub-tlvs, the starting tree root identifier is used to figure out the ordered list. It is carried within the CAPABILITY TLV in a level-1 non-pseudo-node LSP and is given as: +-+-+-+-+-+-+-+-+ |Type=TREE-RT-ID| +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Starting Tree Root Identifier| (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nickname (K-th root) | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nickname (K+1 - th root) | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nickname (...) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: sub-TLV Type, set to 8 (TREE-RT-IDs). o Length: Total number of bytes contained in the value field. o Starting Tree Root Identifier: This identifies the starting tree root identifier of the nicknames which are roots for the domain. This is set to 1 for the first sub-TLV. The starting value and the length field gives the number of nicknames being carried in the sub-TLV. In the event a tree identifier can be computed from two such sub-TLVs and are different, then it is assumed that this is a transient condition which will get cleared. o Nickname: The nickname associated with a Intermediate System id on which this tree is based. A locally significant hash may be used by edge devices to determine which multicast root (or set of multicast roots) is used to send traffic for a specific multicast group. If there is a discrepancy between the number of multi-destination trees the broadcast-root has announced, and the number of roots the root-identifier sub-tlv carries, nodes MUST compute trees for the additional roots. 2.4.5. The Tree Used Identifier Sub-TLV This sub-TLV has the same structure as the Tree Roots Identifier Sub- TLV specified in the above section. The only difference is that its sub-TLV type is set to 9 TBD (TREE-USE-IDs) and the roots listed are only those that the originating intermediate systems wishes to use. Banerjee, et al. Expires January 12, 2010 [Page 21] Internet-Draft Layer-2-IS-IS July 2009 2.4.6. Interested VLANs and Spanning Tree Roots sub-TLV The value of this sub-TLV consists of a VLAN range, flags, and a variable length list of spanning tree root bridge IDs. This sub-TLV may appear zero, one, or many times. The union of the VLAN ranges in all occurrences MUST be precisely the set of VLANs for which the originating Intermediate System is appointed forwarder on at least one port and the VLAN ranges in multiple VLANs sub-TLVs for an Intermediate System MUST NOT overlap. That is, the intersection of the VLAN ranges for any pair of these sub-TLVs originated by an Intermediate System must be null. The value length is 4 + 6*n where n is the number of root bridge IDs. The initial 4 bytes of value are as follows: +-+-+-+-+-+-+-+-+ |Type = INT-VLAN| +-+-+-+-+-+-+-+-+ | Length | (1 byte) +---------------+-----+ | Nickname-Id | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interested VLANS | (8 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Root Bridges | (6*n bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: sub-TLV Type, set to 10 (INT-VLAN). o Length: Total number of bytes contained in the value field. o Nickname Id: If this is set to 0, then it applies to all device- ids generated by the node. It may alternatively be set to a specific nickname-id, in the event a node wants to segregate traffic using multiple device-ids. o Interested VLANS: In the Interested VLANs, as shown below, the M4 bit indicates that there is an IPv4 multicast router on a link for which the originating Intermediate System is appointed forwarder for every VLAN in the indicated range. The M6 bit indicates the same for an IPv6 multicast router. The R and Reserved bits MUST be sent as zero and are ignored on receipt. The VLAN start and end IDs are inclusive. A range of one VLAN ID is indicated by setting them both to that VLAN ID value. It has the following format: Banerjee, et al. Expires January 12, 2010 [Page 22] Internet-Draft Layer-2-IS-IS July 2009 0 1 2 3 4 - 15 16 - 19 20 - 31 +----+----+----+----+------------+----------+------------+ | M4 | M6 | R | R | VLAN start | Reserved | VLAN end | +----+----+----+----+------------+----------+------------+ | Appointed Forwarder Status Lost Counter | +----+----+----+----+------------+----------+------------+ 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 Intermediate System is appointed forwarder for the VLANs in the range. This information is learned from BPDUs heard by the Intermediate System. If MSTP is in use on a link, the root bridge referred to is the CIST (common and internal spanning tree) root bridge. (While, of course, only one spanning tree root should be seen on any particular port, there may be multiple ports in the same VLAN connected to differed bridged LANs with different spanning tree roots.) If no spanning tree roots can be seen on any of the links in any of the VLANs in the range indicated for which the Intermediate System is appointed forwarder (for example all such links are point-to-point links to other Intermediate Systems or to end stations so no BPDUs are received) then the listed set of spanning tree root IDs will be null. If there are any two VLANs in the range indicated for which the value of the M4, or M6 bits are different, the sub-TLV is incorrect and must be split into multiple sub-TLVs each indicating only VLANs with the same M4, and M6 values. If there are any two VLANs in the range indicated for which the set of root bridge IDs see on all links for which the Intermediate System is appointed forwarder for the VLAN are not the same, the sub-TLV is incorrect and must be split into multiple subTLVs each indicating only VLANs with the same set of DRB seen root bridge IDs. It is always safe to use sub-TLVs with a "range" of one VLAN ID but this may be too verbose. This sub-TLV is carried within the CAPABILITY TLV in a level-1 non- pseudo-node LSP. 2.4.7. The VLAN Group sub-TLV The VLAN Group sub-TLV consists of two or more 16-bit fields each of which has a VLAN ID in the low order 12 bits. The top 4 bits MUST be sent as zero and ignored on receipt. The first such VLAN ID is the primary, or may be zero if there is no primary. It is carried within the CAPABILITY TLV in a level-1 non-pseudo-node LSP and is given as: Banerjee, et al. Expires January 12, 2010 [Page 23] Internet-Draft Layer-2-IS-IS July 2009 +-+-+-+-+-+-+-+-+ |Type=VLAN-GROUP| +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLAN-GROUP RECORDS (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ................. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLAN-GROUP RECORDS (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where each VLAN group record is of the form: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Primary VLAN ID (2 bytes) | Secondary VLAN ID (2 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: TLV Type, set to 11 (VLAN-GROUPs). o Length: Total number of bytes contained in the value field. o Primary VLAN-ID: This identifies the primary VLAN-ID. o Secondary VLAN-ID: This identifies the secondary VLAN-ID, address learning is shared at the Intermediate System that announces this sub-tlv. This sub-TLV may appear zero, one, or multiple times. 2.4.8. The Ingress-to-Egress Options (ITEOPT) sub-tlv By including this sub-TLV within one or more Router Capability TLVs in its LSPs, an RBridge can advertise the Ingress-to-Egress options it supports. This sub-TLV may appear zero or more times within a Router Capability TLV. By default, in the absence of any ITEOPT sub- TLVs, no Ingress-to-Egress options are supported. All Ingress-to-Egress options are TLV encoded within the TRILL Header options area. The implementation of a TLV encoded option is indicated by an ITEOPT sub-TLV whose value starts with a byte equal to the first byte of the option. Such ITEOPT sub-TLVs may have additional value bytes further indicating how the option is supported as specified in the option's definition, for example a list of supported security algorithms. Banerjee, et al. Expires January 12, 2010 [Page 24] Internet-Draft Layer-2-IS-IS July 2009 +-+-+-+-+-+-+-+-+ | Type = ITEOPT | +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+ | Option | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option dependent variable length information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: sub-TLV Type, set to Ingress-to-Egress option sub-TLV 12 [TBD]. o Length: variable, minimum 1. o Value: The first byte of the option followed by option dependent information. 2.5. Multi Topology Aware Capability TLV This section defines a new optional Intermediate System to Intermediate System (IS-IS) TLV named MT-CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities for a particular topology within an IS-IS level or the entire routing domain. This is different from Capability TLV defined in RFC 4971, in the sense, the capabilities announced here are topology scoped. The Multi Topology Aware Capability (MT-CAPABILITY) is an optional IS-IS TLV type 144 [TBD], that may be generated by the originating IS and has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=MTCAPABTLV| Length |O|R|R|R| Topology Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: TLV Type, set to MT-CAPABILITY TLV 144 [TBD]. o Length: Total number of bytes contained in the value field, including the length of the sub-TLVs carried in this TLV. o O bit: The overload bit that follows the semantics associated with an overloaded intermediate system. o Topology Identifier: MT ID is a 12-bit field containing the MT ID of the topology being announced. This field when set to zero Banerjee, et al. Expires January 12, 2010 [Page 25] Internet-Draft Layer-2-IS-IS July 2009 implies that it is being used to carry base topology information. In TRILL this value is set to ZERO, however, in IEEE SPB and SPBB, it may be non-zero. o sub-tlvs: The MT aware Capabilities TLV value contains sub-TLVs formatted as described in [RFC5305]. They are defined in the next sections. The MT-aware CAPABILITY TLV MUST be carried only within a LSP PDU. It may occur multiple times in a LSP PDU. 2.5.1. SPB Instance sub-TLV The SPB Instance sub-TLV gives the SPSourceID for this node/topology instance. This is the 20 bit value that is used in the formation of multicast DA addresses for packets originating from this node/ instance. The SPSourceID occupies the upper 20 bits of the multicast DA together with 4 other bits (see the SPB 802.1ah multicast DA address format section). This TLV SHOULD be carried within the fragment ZERO LSP. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| reserved | N-VID | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLAN-ID (1) Tuples | (4 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLAN-ID (N) Tuples | (4 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R R R R| SPS Flags |V| SPSOURCEID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved (Auto Allocation Tiebreaker) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bridge Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bridge Identifier (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CIST Root Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CIST Root Identifier (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CIST External ROOT Path Cost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where VLAN-ID tuples have the format as: Banerjee, et al. Expires January 12, 2010 [Page 26] Internet-Draft Layer-2-IS-IS July 2009 0 1 2- 3 4 - 15 16 - 19 20 - 31 +-+-+---------+-------+-----------+------------+ |A|U|Reserved | VID | Algorithm | B-VID | +-+-+---------+-------+-----------+------------+ o Type: TLV Type, set to SPB Instance sub-TLV 1 [TBD]. o Length: Total number of bytes contained in the value field. o S bit indicates the presence of sub-TLVs following this value. o The N-VID must be set to the number of VIDs tuples that follow. This allows the sub-TLV starting point to be found. Note N-VID here does not include the Base VID. o Each VID Tuple consists of: o ALG specifies the tie breaking algorithm to be used for this VID. Currently only the following values are supported: * ALG = 0 a spanning tree. * ALG = 1 the Low PATHID algorithm is used for this VID. * ALG = 2 the High PATHID algorithm is used. o VID is the VID for which the given algorithm applies. This structure is used to indicate both shortest path VIDs and Single VIDs in the Case of SPBB. Note the VID represents the SPVID associated with SPT Set. More details are in [REF]. o U bit, when set indicates that there are I-SIDs that locally use the VID associated with this SPT SET. This U bit is used to avoid taking actions that would adversely affect traffic network wide. o A bit, A bit when set declares this is an SPVID with auto allocation. If the VID value is zero. A VID will be allocated once the bridge has synchronized the IS-IS LSPs. Neighbor bridges can distribute the LSPs but MUST not populate filtering databases (forwarding) for traffic from a bridge that has an SPVID of 0. When the bridge allocating receives the complete LSPs from the IS-IS adjacency it will allocate one or more SPVIDs according to the allocation logic. It will then re-advertise this LSP with the allocated value. If bridges detect a collision of allocated SPVIDs the loosing bridge will have its forwarding removed just as if it was unallocated. When the originating bridge detects it is a loosing bridge in a collision it reallocates and simply re- advertises a new SPVID. A bridge SHOULD remember SPVID Banerjee, et al. Expires January 12, 2010 [Page 27] Internet-Draft Layer-2-IS-IS July 2009 allocations through restarts by storing them in non volatile memory and therefore reuse the SPVID value. o The SPSOURCEID is a 20 bit value used to construct multicast DA's as described below for multicast packets originating from the origin (SPB node) of the link state packet (LSP) that contains this TLV. More details are in [REF]. o The Auto Allocation Tie Breaker is a reserved field that would allow collisions in SPSOURCEID to be resolved. If these fields are equal then the Bridge Priority takes precedence and if Bridge Priority is equal then the numerically higher Bridge ID wins. The V bit indicates this SPSOURCEID is auto allocated. Note SPSOURCEIDs are only used in the case of Backbone Brides with single VIDs ( Base-VID TLV B bit = 1 and M bit = 0). Single VIDS are not auto allocated. If the A bit is clear the SPSOURCEID has been configured and must be unique. When the bridge allocating receives the complete LSP from the IS-IS adjacency it will allocate a SPSOURCEID according to the allocation logic. It will then re-advertise this LSP with the allocated value. If bridges detect a collision of allocated SPSOURCEIDs the loosing bridge (determined by the tie breaking algorithm) will have its forwarding removed just as if it was unallocated. When the originating bridge detects it is a loosing bridge in a collision it reallocates and simple re-advertises a new SPSOURCEID. A bridge SHOULD remember SPSOURCEID allocations through restarts by storing them in non volatile memory and reuse the SPSOURCEID value. o Bridge Identifier is the Spanning tree compatible Bridge identifier. This is configured exactly as specified in IEEE802 [802.1D]. This allows SPB to build a compatible Spanning tree using link state. o The four most significant bits of the most significant byte of a Bridge Identifier comprise a settable priority component that permits the relative priority of Bridges to be managed. The next most significant twelve bits of a Bridge Identifier (the four least significant bits of the most significant byte, plus the second most significant byte) comprise a locally assigned system ID extension. The six least significant bytes ensure the uniqueness of the Bridge identifier; they shall be derived from the globally unique Bridge Address according to the following procedure. The third most significant byte is derived from the initial byte of the MAC Address; the least significant bit of the byte (Bit 1) is assigned the value of the first bit of the Bridge Address, the next most significant bit is assigned the value of the second bit of the Bridge Address, and so on. The fourth Banerjee, et al. Expires January 12, 2010 [Page 28] Internet-Draft Layer-2-IS-IS July 2009 through eighth bytes are similarly assigned the values of the second to the sixth bytes of the Bridge Address. o CIST Root Identifier is for SPB interworking with RSTO and MSTP at SPT Region Boundaries. This is an imported value from a Spanning tree. o CIST External Root Path Cost is the cost from the Spanning tree algorithm to the Root. 2.5.2. Service Identifier and Unicast Address sub-TLV The SPB Service Identifier and Unicast Address TLV is used to introduce service group membership on the originating node and/or to advertise an additional B-MAC unicast address present on, or reachable by the node. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | B-MAC ADDRESS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | B-MAC ADDRESS (cont) | Res. | VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|R| Reserved | ISID #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|R| Reserved | ISID #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|R| Reserved | ISID #n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: TLV Type, set to Service Identifier and Unicast Address sub- TLV 2 [TBD]. o Length: Total number of bytes contained in the value field. o B-MAC ADDRESS is a unicast address of this node. It may be either the single nodal address, or may address a port or any other level of granularity relative to the node. In the case where the node only has one B-MAC address this should be the same as the SYS-ID of the node. To add multiple B-MACs this TLV must be repeated per additional B-MAC. o ISID #1 .. #N are 24 bit service group membership identifiers. If two nodes have an ISID in common, intermediate nodes on the unique shortest path between them will create forwarding state for the related B-MAC addresses and will also construct multicast forwarding state using the ISID and the node's SPSOURCEID to Banerjee, et al. Expires January 12, 2010 [Page 29] Internet-Draft Layer-2-IS-IS July 2009 construct a multicast DA as described in IEEE 802.1aq LSB. Each ISID has a Transmit(T) and Receive(R) bit which indicates if the membership is as a Transmitter/Receiver or both (with both bits set). In the case where the Transmit(T) and Receive(R) bits are both zero, the ISID is ignored. If more ISIDs are associated with a particular B-MAC than can fit in a single TLV, this TLV can be repeated with the same B-MAC but with different ISID values. 2.6. SPB Link Metric sub-tlv The SPB Link Metric Sub TLV occurs nested as within the Extended Reachability TLV (type 22), or the Multi Topology Intermediate System TLV (type 222). If this sub TLV is not present for an ISIS adjacency then that adjacency MUST NOT carry SPB traffic for the given topology instance. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved (must be 0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPB-LINK-METRIC | Num port ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: TLV Type, set to SPB Link Metric sub-TLV 5 [TBD]. o Length: Total number of bytes contained in the value field. o SPB-LINK-METRIC indicates the administrative cost or weight of using this link as a 24 bit unsigned number. Smaller numbers indicate lower weights and are more likely to carry SPB traffic. Only one metric is allowed per SPB instance per link. If multiple metrics are required multiple SPB instances are required, either within IS-IS or within several independent IS-IS instances. o Num of Ports is the number of ports associated with this link. o Port Identifier is the standard IEEE port identifier used to build a spanning tree associated with this link. SPB routes follow the minimum sum of link metrics from the source to the destination. If any SPB link metric is not the same as its reverse direction metric the metric for both directions of the above calculation is considered to be the maximum of the two differing metrics. If an SPB metric TLV is missing from one or both directions of an adjacency no SPB traffic may flow between those nodes for the Banerjee, et al. Expires January 12, 2010 [Page 30] Internet-Draft Layer-2-IS-IS July 2009 corresponding SPB topology instance (MT-ID). In the event of two or more equal minimum sum of link metrics paths, the unique shortest path is chosen according to the symmetric tie breaking algorithm Low- PATHID and/or High-PATHID as described in IEEE 802.1aq LSB. When a single SPB instance is used this TLV occurs as a sub-TLV of TLV 22 but when multiple instances are used it must be present as a sub-TLV of the Multi Topology Intermediate System Tlv (type 222) with the appropriate MT-ID to correlate it with the other top level TLV's used to specify the SPB topology instance in question. 3. The Multicast Group PDU The systems that this dcoument is concerned with want to carry not only layer-2 unicast information in the link state protocols, but also multicast information. This document specifies three new IS-IS PDUs, the Multicast Group (MGROUP) PDU, for carrying a list of attached or joined multicast groups. The Multicast Group Complete Sequence Number (MGROUP-CSNP) PDU and the Multicast Group Partial Sequence Number (MGROUP-PSNP) PDU packets are also defined to be used with the new MGROUP-PDU to perform database exchange on the MGROUP PDU packets. In the Layer-2 environment, it is expected the join/leave frequency of the multicast members will be much higher than unicast topology changes. It is efficient to separate the updates for the group membership change information from the remainder of the information by placing this information in a separate PDU. This enables reachability information, that would trigger an SPF, to be not impacted at all. Furthermore, during SPF runs, TLVs being on different PDUs which do not affect SPF need not be inspected during processing. The choice of a different PDU also opens the LSP-space to another 256 fragments to carry a large number of groups. This additional space can be used judiciously to carry only multicast information. The Multicast Group (MGROUP) PDU can be used to advertise a set of attached, or joined, multicast groups. The MGROUP PDU is formatted identical to a Level 1 Link State PDU, as described in Section 9.3 of [IS-IS]. One field, PDU Type, is changed to 19 [TBD], to signify this PDU is carrying multicast group information, rather than unicast reachability information. The PDU MUST NOT carry Area Address TLV or Protocol Support TLV in the zeroth fragment. The Multicast Group PDU carries TLVs indicating multicast membership information. There are three sub-TLVs of the GADDR TLV defined in this document, that MAY be present in this PDU, namely, GMAC-ADDR, Banerjee, et al. Expires January 12, 2010 [Page 31] Internet-Draft Layer-2-IS-IS July 2009 GIP-ADDR, and GIPV6-ADDR TLVs. One or more TLVs MAY be carried in a single MGROUP PDU. Future multicast address TLVs MAY be defined using other type codes, and be carried in an MGROUP PDU. The information carried in this PDU is processed in a similar fashion as described in [RFC 1584]. 3.1. The Multicast Group Partial Sequence Number PDU The Multicast Group Partial Sequence Number (MGROUP-PSNP) PDU is used to reliably flood the MGROUP PDU following the base protocol specifications. 3.2. The Multicast Group Complete Sequence Number PDU The Multicast Group Complete Sequence Number PDU (MGROUP-CSNP) PDU is used to reliably flood the MGROUP PDU following the base protocol specifications. 3.3. Enhancements to the flooding process This document proposes that the information contained in the MGROUP- PDU is in a parallel database and its update mechanisms mimic that of the regular database. Nodes running IS-IS in an L2 domain MUST support these additional MGROUP PDUs defined in this document. In general, the flooding of the MGROUP-PDU in tandem with the MGROUP- PSNP and MGROUP-CSNP PDUs uses the same update procedures as defined for the regular LSP, PSNP, and CSNP PDUs. For example, on P2P links CSNP is exchanged on the formation of an adjacency. In a similar fashion a MGROUP-CSNP MUST also be exchanged between the neighbors at the same time. This gets the initial MGROUP-database synchronization going. After this similar actions of the base protocol specifications for the regular database synchronization will be maintained to keep the MGROUP-database synchronized. Similarly, on LAN links the DIS is responsible for sending periodic CSNP transmissions. The DIS in the L2 IS-IS network domain will also be responsible for sending periodic MGROUP-CSNP transmissions. The update and flooding process will work in parallel for the two databases and there is no further synchronization between them. In general, the database synchronization is performed in parallel with no interactions between the messages. However, the initial triggers that start a CSNP exchange are correlated, in the sense it Banerjee, et al. Expires January 12, 2010 [Page 32] Internet-Draft Layer-2-IS-IS July 2009 also triggers a MGROUP-CSNP exchange. For example, during graceful restart [RFC 5306], the normal hello operations as described in the RFC will be followed. The enhancements will take place such that CSNP and PSNP triggers will necessitate a parallel MGROUP-CSNP and MGROUP-PSNP exchange and update process will be triggered in parallel for the MGROUP-PDUs. After both databases containing the regular PDUs and MGROUP-PDUs have been obtained, the restart process is deemed complete. 3.4. Enhancements to the maximum sequence number reached In the event, LSPs reach the maximum sequence number, ISO/IEC 10589 states the rules for the process to shut down and its duration. With the introduction of the MGROUP-PDU, the same process now applies when LSPs from either database reach the maximum sequence number. 4. Considerations for Using L2 Information in IS-IS While this document does not specify the way in which addresses carried in these TLVs are used in IS-IS, two general areas of concern are considered in this section: building the SPF tree when using this information, and the election of designated intermediate systems (DIS) in an environment using this information. 4.1. Building SPF Trees with Layer 2 Information Each IS which is part of a single broadcast domain from a layer 2 perspective will build multiple SPF trees (SPT) for every IS that is announced by the IS deemed to be the broadcast root. We assume some mechanism for forwarding traffic to these attached addresses added to the SPT is provided for in the mechanism proposing the use of these extension TLVs. 4.2. Designated Intermediate Routers A single DIS SHOULD be elected as described in [IS-IS] for each layer 2 broadcast domain (VLAN) for which information is being carried in IS-IS. This reduces the amount of work required to flood and maintain synchronized databases over the underlying media on which IS-IS is running and providing layer 2 forwarding information for. 5. Acknowledgements The authors would like to thank Les Ginsberg for his useful comments. Banerjee, et al. Expires January 12, 2010 [Page 33] Internet-Draft Layer-2-IS-IS July 2009 6. Security Considerations This document adds no additional security risks to IS-IS, nor does it provide any additional security for IS-IS. 7. IANA Considerations This document creates three new PDU types, namely the MCAST PDU, MCAST-CSNP PDU, and the MCAST-PSNP PDU. IANA SHOULD assign a new PDU type to the level-1 PDUs described above and reflect it in the PDU registry. MCAST-PDU Level-1 PDU Type: 19 MCAST-CSNP-PDU Level-1 PDU Type: 22 MCAST-PSNP-PDU Level-1 PDU Type: 29 This document requires the definition a set of new ISIS TLVs, the MAC-Reachability TLV (type 141), the Group Address TLV (type 142), and the Link-Capability TLV (type 143), that needs to be reflected in the ISIS TLV code-point registry. This document creates a number of new sub-TLV in the numbering space for the Group Address TLV, the Link Capability TLV, and the Capability TLV. The TLV and sub-TLVs are given below along with technologies that use them. Banerjee, et al. Expires January 12, 2010 [Page 34] Internet-Draft Layer-2-IS-IS July 2009 IIH LSP SNP MCAST MCAST TRILL/ LSP SNP IEEE MAC-RI TLV (141) - X - - - T/I GADDR-TLV (142) - - - X - T/I GADDR-TLV.GMAC-ADDR sub-tlv 1 - - - X - T/I GADDR-TLV.GMAC-IP sub-tlv 2 - - - X - T/I GADDR-TLV.GMAC-IPV6 sub-tlv 3 - - - X - T/I MT-Port-Cap-TLV (143) X - - - - T/- PortCap.VLAN and Flags sub-tlv 1 X - - - - T/- PortCap.Enabled-VLANs sub-tlv 2 X - - - - T/- PortCap.AppointedFwrdrs sub-tlv 3 X - - - - T/- PortCap.HopbyHopOptions sub-tlv 4 X - - - - T/- PortCap.BaseVLANID sub-tlv 5 X - - - - -/I CAPABILITY.Trill-Version sub-tlv 5 - X - - - T/- CAPABILITY.Nickname sub-tlv 6 - X - X - T/- CAPABILITY.Tree sub-tlv 7 - X - - - T/- CAPABILITY.Tree Roots Id sub-tlv 8 - X - - - T/- CAPABILITY.TreeUseRootId sub-tlv 9 - X - - - T/- CAPABILITY.Int-VLANs sub-tlv 10 - X - X - T/- CAPABILITY.VLAN-Groups sub-tlv 11 - X - - - T/- CAPABILITY.ITEOPT sub-tlv 12 - X - - - T/- MT-Capability-TLV (144) X - - - - -/I MT-Cap.SPB Instance sub-tlv 1 X - - - - -/I MT-Cap.Service Id. sub-tlv 2 X - - - - -/I EXT-IS.SPB Link Metric sub-tlv 5 X - - - - -/I MT-EXT-IS.SPB LinkMetric sub-tlv 5 X - - - - -/I IANA SHOULD manage the remaining space using the consensus method. 8. Contributing Authors David Ward Cisco Systems 170 W Tasman Drive San Jose, CA 95138 US Email: wardd@cisco.com Russ White Cisco Systems Banerjee, et al. Expires January 12, 2010 [Page 35] Internet-Draft Layer-2-IS-IS July 2009 170 W Tasman Drive San Jose, CA 95138 US Email: riw@cisco.com Dino Farinacci Cisco Systems 170 W Tasman Drive San Jose, CA 95138 US Email: dino@cisco.com Radia Perlman Sun Microsystems 16 Network Circle Menlo Park, CA 94025 US Email: Radia.Perlman@Sun.com Donald E. Eastlake 3rd Stellar Switches 155 Beaver Street Milford, MA 07157 US Email: d3e3e3@gmail.com Peter Ashwood-Smith Huawei Technologies Canada Co. Ltd. 411 Legget Drive, Suite 503 Kanta, Ontario K2K 3C9 CANADA Email: Peter.AshwoodSmith@huawei.com Don Fedyk Alcatel-Lucent 220 Hayden Road Groton, MA 01450 US Banerjee, et al. Expires January 12, 2010 [Page 36] Internet-Draft Layer-2-IS-IS July 2009 Email: Donald.Fedyk@alcatel-lucent.com 9. References 9.1. Normative References [IS-IS] ISO/IEC 10589, "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)", 2005. [RFC 1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments", 1990. [RFC 4971] Vasseur, JP. and N. Shen, "Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information", 2007. [RFC 5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", 2008. [RFC 5306] Shand, M. and L. Ginsberg, "Restart Signaling for Intermediate System to Intermediate System (IS-IS)", 2004. 9.2. Informative References [IEEE 802.1aq] "Standard for Local and Metropolitan Area Networks / Virtual Bridged Local Area Networks / Amendment 9: Shortest Path Bridging, Draft IEEE P802.1aq/D1.5", 2008. [RBRIDGES] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. Ghanwani, "RBridges: Base Protocol Specification", 2009. [RFC 1584] Moy, J., "Multicast Extensions to OSPF", March 1994. Banerjee, et al. Expires January 12, 2010 [Page 37] Internet-Draft Layer-2-IS-IS July 2009 Author's Address Ayan Banerjee (editor) Cisco Systems 170 W Tasman Drive San Jose, CA 95138 US Email: ayabaner@cisco.com Banerjee, et al. Expires January 12, 2010 [Page 38]