Network Working Group                                   A. Banerjee, Ed.
Internet-Draft                                             Cisco Systems
Intended status: Standards Track                           July 11, 2009                       February 10, 2010
Expires: January 12, August 14, 2010

                Extensions to IS-IS for Layer-2 Systems
                       draft-ietf-isis-layer2-01
                       draft-ietf-isis-layer2-02

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
   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.

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, August 14, 2010.

Copyright Notice

   Copyright (c) 2009 2010 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 (http://trustee.ietf.org/license-info). document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Abstract

   This  Code Components extracted from this document specifies must
   include Simplified BSD License text as described in Section 4.e of
   the IS-IS extensions necessary to support
   multi-link IPv4 Trust Legal Provisions and IPv6 networks, as well are provided without warranty as to provide true link
   state routing to any protocols running directly over layer 2.  While
   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
   described in
   IS-IS is used. the BSD License.

Table of Contents

   1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  PDU, TLV and sub-TLV Enhancements to IS-IS . . . . . . . . . . . .  4
     2.1.  The MAC-Reachability TLV . . . . . . . . . . . . . . . . .  5  4
     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  9
       2.2.4.  The SPBV MAC Address sub-TLV . . . . . . . . . . . . . 11
     2.3.  Multi Topology aware Port Capability TLV . . . . . . . . . 12 13
       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 15
       2.3.4.  Hop-by-Hop Options (HBHOPT) sub-TLV  . . . . . . . . . 15 17
       2.3.5.  Base VLAN-Identifiers sub-TLV  . . . . . . . . . . . . 16
     2.4.  Sub-TLVs for the Router Capability TLV . . . . . . 18
       2.3.6.  SPB Digest sub-TLV . . . . 18
       2.4.1.  The TRILL Version sub-TLV . . . . . . . . . . . . . . 18
       2.4.2.  The Nickname 19
       2.3.7.  Site Identifier sub-TLV  . . . . . . . . . . . . . . . . . 18
       2.4.3.  The Trees 20
       2.3.8.  Site Group IPv4 sub-TLV  . . . . . . . . . . . . . . . 20
       2.3.9.  Site Group IPv6 sub-TLV  . . . 19
       2.4.4.  The Tree Roots Identifier Sub-TLV . . . . . . . . . . 20
       2.4.5.  The Tree Used Identifier Sub-TLV . . 21
       2.3.10. Adjacency Server IPv4 sub-TLV  . . . . . . . . . 21
       2.4.6.  Interested VLANs and Spanning Tree Roots sub-TLV . . . 22
       2.4.7.  The VLAN Group 21
       2.3.11. Adjacency Server IPv6 sub-TLV  . . . . . . . . . . . . 22
     2.4.  Sub-TLVs for the Router Capability TLV . . . . . 23
       2.4.8.  The Ingress-to-Egress Options (ITEOPT) sub-tlv . . . . 24
     2.5.  Multi Topology Aware Capability TLV . . . . . 22
       2.4.1.  The TRILL Version sub-TLV  . . . . . . 25
       2.5.1.  SPB Instance . . . . . . . . 22
       2.4.2.  The Nickname sub-TLV . . . . . . . . . . . . . . . . . 26
       2.5.2.  Service Identifier and Unicast Address 23
       2.4.3.  The Trees sub-TLV  . . . . 29
     2.6.  SPB Link Metric sub-tlv . . . . . . . . . . . . . . 24
       2.4.4.  The Tree Root Identifiers Sub-TLV  . . . . 30
   3.  The Multicast Group PDU . . . . . . 25
       2.4.5.  The Trees Used Identifiers Sub-TLV . . . . . . . . . . 26
       2.4.6.  Interested VLANs and Spanning Tree Roots sub-TLV . . . 31
     3.1. 26
       2.4.7.  The Multicast VLAN Group Partial Sequence Number PDU sub-TLV . . . . . 32
     3.2. . . . . . . . . . . . 28
       2.4.8.  The Multicast Group Complete Sequence Number PDU Ingress-to-Egress Options (ITEOPT) sub-TLV . . . . 29
       2.4.9.  VLAN Mapping (VMAP) sub-TLV  . 32
     3.3.  Enhancements to the flooding process . . . . . . . . . . . 32
     3.4.  Enhancements to the maximum sequence number reached . 30
     2.5.  Multi Topology Aware Capability TLV  . . 33
   4.  Considerations for Using L2 Information in IS-IS . . . . . . . 33
     4.1.  Building SPF Trees with Layer 2 Information . . 31
       2.5.1.  SPB Instance sub-TLV . . . . . 33
     4.2.  Designated Intermediate Routers . . . . . . . . . . . . 32
       2.5.2.  SPBM Service Identifier and Unicast Address sub-TLV  . 33
   5.  Acknowledgements 34
     2.6.  Sub-TLVs of the Extended Reachability TLV  . . . . . . . . 35
       2.6.1.  SPB Link Metric sub-TLV  . . . . . . . . . . . . . . . 33
   6.  Security Considerations 35
       2.6.2.  MTU sub-TLV  . . . . . . . . . . . . . . . . . . . 34
   7.  IANA Considerations . . 36
     2.7.  TRILL Neighbor TLV . . . . . . . . . . . . . . . . . . . 34
   8.  Contributing Authors . 37
     2.8.  The Group Membership Active Source TLV . . . . . . . . . . 38
       2.8.1.  The Group MAC Active Source sub-TLV  . . . . . . . . . 39
       2.8.2.  The Group IP Active Source sub-TLV . 35
   9.  References . . . . . . . . . 41
       2.8.3.  The Group IPv6 Active Source sub-TLV . . . . . . . . . 42
     2.9.  PDU Extensions to IS-IS  . . . . . . . . 37
     9.1.  Normative References . . . . . . . . . 44
       2.9.1.  The Multicast Group PDU  . . . . . . . . . . 37
     9.2.  Informative References . . . . . 44
       2.9.2.  The TRILL-Hello PDU  . . . . . . . . . . . . . 37
   Author's Address . . . . 46
       2.9.3.  The MTU PDU  . . . . . . . . . . . . . . . . . . . . . 37

1.  Overview

   There are a number of systems (for example, 47
   3.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 48
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 48
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 48
   6.  Contributing Authors . . . . . . . . . . . . . . . . . . . . . 51
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 52
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 52
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 53

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.
   routing.  This document specifies a set of TLVs and sub-TLVs to be
   added to [IS-IS] level 1 PDUs, and three six 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 TRILL and IEEE 802.1aq protocols.

   This document specifies three six new IS-IS PDUs, the 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 PDUs.  The TRILL-Hello PDU packets.
   provides the subnet specific layer of IS-IS for TRILL links.  The
   MTU-probe and MTU-ack PDUs provide a means of testing link MTU.

1.1.  Terminology

   The term "Hello" or "Hello PDU" in this document, when not further
   qualified, includes both the TRILL IIH PDU, the LAN IIH PDU and the 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.  PDU, TLV and sub-TLV Enhancements to IS-IS

   In this section we describe the enhancements that are being proposed
   for the TLV PDUs, TLVs 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.

2.1.  The

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)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Confidence  |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  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
      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.

   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 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:

   +-+-+-+-+-+-+-+-+
   | Type=GMAC-ADDR|                  (1 byte)
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+
   |   Confidence  |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Topology-Id/ Nickname-Id    |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Confidence  |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  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
      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:  RESERVED: 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 is
      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, sub-TLV,
      it is permitted to have the same group address repeated with
      different source addresses repeated in different sub-tlvs. another sub-TLV of another instance
      of the Group Address TLV.

   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:

   +-+-+-+-+-+-+-+-+
   | 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.

   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:  RESERVED: 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 is
      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,
      sub-TLV, it is permitted to have the same group address repeated
      with different source addresses repeated in different sub-tlvs. another sub-TLV of
      another instance of the Group Address TLV.

   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:

   +-+-+-+-+-+-+-+-+
   |Type=GIPv6-ADDR|
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+
   |   Confidence  |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Topology-Id/ Nickname-Id    |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Confidence  |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  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
      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:  RESERVED: 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 is
      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, sub-TLV, it is permitted to have the same group
      address repeated with different source addresses repeated in different
      sub-tlvs.
      another sub-TLV in another instance of the Group Address TLV.

   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

2.2.4.  The Multi Topology aware Port Capability (MT-PORT-CAP) SPBV MAC Address sub-TLV

   The SPBV MAC Address (SPBV-MAC-ADDR) TLV is an IS-IS
   TLV sub-TLV type 143 [TBD], 4 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
      |# MAC Addresses| reserved          |SR |       SPVID           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |T|R| Reserved  |      MAC Address  (6 bytes)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                               | T|R| Reserved |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       MAC Address  (6 bytes)                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               | T|R| Reserved |                            sub-TLVs               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: TLV sub-TLV Type, set to MT-PORT-CAP TLV 143 [TBD]. 4 (SPBV-MAC-ADDR).

   o  Length: Total number of bytes contained in the value field,
      including field.

   o  Number of MAC address (1 byte): Number of MAC address must be set.
      It is the length number of addresses associated with the sub-TLVs carried in this TLV.

   o  O bit: The overload bit SPVID that follows the semantics associated with
      an overloaded intermediate system.

   o  Topology Identifier: MT ID
      follow.  This is a 12-bit field containing the MT ID number of the topology being announced.  This field when set to zero
      implies that it is being used to carry base topology information.

      In TRILL addresses associated with this value is set to ZERO, however, in IEEE SPB and SPBB,
      it may be non-zero.
      SPVID.

   o  sub-TLVs:  SR bits (2-bits) The MT aware Port Capabilities TLV value contains sub-
      TLVs formatted as described in [RFC5305].  They SR bits are defined in the
      next sections. service requirement parameter
      from MMRP.  The MT aware PORT-CAP-TLV MUST be carried only within a LAN IIH PDU,
   or a P2P IIH PDU.  It service requirement parameters have the value 0
      (Forward all Groups) (and 1 (Forward All Unregistered Groups)
      defined.  However this attribute 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 also be missing.  So the following format: SR
      bits are defined as 0 not declared, 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 Forward all Groups and Flags sub-TLV 1 [TBD].

   o  Length: 4 - Number of bytes contained in the value field. 2
      Forward All Unregistered Groups.

   o  SPVID (12-bits) The first SPVID and by association Base VID and second bytes have a copy of the Outer VLAN ID
      associated with ECT-
      ALGORITHM and SPT Set that 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 MAC addresses defined below will
      use.  If the lower VLAN ID bits.

   o  The upper 4 bits of SPVID is not allocated the first byte are flag bits as shown.  The AF
      bit, if one, indicates SPVID Value is 0.  Note
      that if the sending Intermediate System
      believes it ECT-Algorithm in use is Appointed Forwarder for Spanning Tree Algorithm this
      value should be populated with the VLAN Base VID and port on which the Hellos was sent.  The AC bit, if one, indicates that MAC can be
      populated.

   o  T Bit (1-bit) This is the
      sending port Transmit allowed Bit for the following
      group MAC address.  This is configured as an access port.  The VM bit, if a
      one, indicates indication that SPBV Group MAC
      Address with SPVID of source should be populated (for the sending Intermediate System has detected
      VLAN mapping within the link.  The BY bit, if set, indicates
      bypass psuedonode.

   o  The third bridge
      advertising this Group MAC), and forth bytes give the Designated VLAN for installed in the link.
      The lower 4 bits FDB of transit
      bridges, when the third byte give bridge computing the upper ID bits of trees is on the
      Designated VLAN and
      corresponding ECT-ALGORITHM shortest path between the forth byte gives bridge
      advertising this MAC with the lower VLAN ID bits.
      The upper 4 bits T bit set, and any receiver of this
      Group MAC Address.  A bridge that does not advertise this bit set
      for an Group MAC Address should have no forwarding state installed
      for traffic originating from that bridge on other transit bridges
      in the third byte are reserved and MUST be sent
      as zero and ignored on receipt.

   The VLAN and Flags sub-TLV network.

   o  R Bit (1-bit) This is carried within the MT aware PORT-CAP
   TLV and MUST be carried in LAN IIH PDU.  It MUST NOT Receive allowed Bit for the following
      Group MAC Address.  This is an indication that SPBV Group MAC
      Addresses as receiver should be carried
   within a P2P IIH PDU.

2.3.2.  Enabled VLANs sub-TLV

   The Enabled VLAN sub-TLV specifies populated (for bridges advertising
      this Group MAC Address with the VLANs enabled for end station
   service at T bit set) and installed when the port
      bridge computing the trees lies on which the Hello was sent.

   o  Type: sub-TLV Type, corresponding shortest path
      for this ECT-ALGORITHM between this receiver and any transmitter
      on this Group MAC Address.  An entry that does not have this bit
      set to Enabled VLANs sub-TLV 2 [TBD].

   o  Length: variable, depending for a Group MAC Address is prevented from receiving on contents described next. this
      Group MAC Address because transit bridges will not install
      multicast forwarding state towards it in their FDBs or the traffic
      is explicitly filtered.

   o  MAC Address (48-bits) The minimum size of MAC is the value address is 3 bytes.  The third and
      subsequent bytes provide either a bit map of enabled VLANs starting at
      the VLAN ID indicated in group
      address or an individual address.  When the first two bytes.  The lower order
      four bits MAC address is a group
      address declares this bridge as part of the first byte give multicast interest for
      this destination MAC address.  Multicast trees can be efficiently
      constructed for destination by populating multicast FDB entries
      for the upper bits subset of the starting
      VLAN ID and shortest path tree that connects the second byte gives bridges
      supporting the lower bits multicast address.  This replaces the function of that VLAN ID.
      MMRP for SPTs.  The upper four T and R 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 above have meaning 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
      group address.  Individual addresses are populated only as if the complete
      R bit map of these
   VLANs. was not set.

   The Enabled VLAN SPBV-MAC-ADDR sub-TLV is carried within the MT aware PORT-CAP GADDR TLV and MUST be
   carried in LAN IIH PDU.  It MUST NOT be carried within a
   P2P IIH standard Level 1 link state MGROUP PDU.

2.3.3.  Appointed Forwarders sub-TLV

2.3.  Multi Topology aware Port Capability 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 Multi Topology aware Port Capability (MT-PORT-CAP) is an IS-IS
   TLV type 143 [TBD], and has 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 following format:
    0                   1                   2                   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:

   +----------------+-----+-----+---------+-----+----+---------+
   |   byte
    0 1 - 2   |  byte 3   |  byte 4 |   byte 5 |  byte 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  |
   +----------------+-----+-----+---------+-----+----+---------+
   | Appointee Nick | Res | Start VLAN ID | Res
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | End VLAN ID                            sub-TLVs                           |
   +----------------+-----+-----+---------+-----+----+---------+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  The appointed forwarder Intermediate System is specified by its
      nickname  Type: TLV Type, set to MT-PORT-CAP TLV 143 [TBD].

   o  Length: Total number of bytes contained in the first two bytes.

   o  The "Res" fields value field,
      including the length of 4 bits each are reserved and MUST be sent as
      zero and ignored on receipt. the sub-TLVs carried in this TLV.

   o  O bit: The VLAN range given overload bit that follows the semantics associated with
      an overloaded intermediate system.

   o  Topology Identifier: MT ID is inclusive.  To specify a single VLAN, that
   VLAN 12-bit field containing the MT ID appears as both
      of the start and end VLAN.  The Intermediate
   System whose nickname topology being announced.  This field when set to zero
      implies that it is given being used to carry base topology information.
      In TRILL this value is appointed forwarder for those VLANs
   for which it has end station service enabled (see item 2 above) set to ZERO, however, in
   the inclusive range.  For example, assume an Intermediate System with
   end station service enabled on VLANs 100, 101, 199, IEEE SPB and 200 (and
   possibly other VLANs less than 100 or greater than 200), but not
   enabled for VLANs 102 through 198.  It could SPBB,
      it may 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 non-zero.

   o  sub-TLVs: The MT aware Port Capabilities TLV value sequence with start and end VLAN IDs of 100 and 101 contains sub-
      TLVs formatted as described in the
   first part and 199 and 200 [RFC5305].  They are defined in the second part.

   An Intermediate System's nickname
      next sections.

   The MT-PORT-CAP TLV may occur as appointed forwarder
   for multiple VLAN ranges within the same or different Port Capability
   TLVs times, and is carried only
   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. IIH PDU.

2.3.1.  The Appointed Forwarder Special VLANs and Flags sub-TLV is carried within the MT aware PORT-
   CAP TLV

   The Special VLANs and Flags (VLAN and Flags) sub-TLV MUST be carried appear in a LAN IIH PDU.
   MT-PORT-CAP TLV.  This MUST NOT be is carried only once in a P2P every TRILL 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
   It has 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.

   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. following format:

   +-+-+-+-+-+-+-+-+
   | Type = HBHOPT |
   |Type=VLAN Flags|
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+
   +------+-------------------------+
   |    Option    Port ID  (2 bytes)          |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +----+----+----+----+------------+----------+------------+
   |       Option dependent variable length information AF |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AC | VM | BY | Outer.VLAN | Reserved | Desig.VLAN |
   +----+----+----+----+------------+----------+------------+
      0    1    2    3     4 - 15      16 - 19     20 - 31

   o  Type: sub-TLV TLV Type, set to Hop-by-Hop VLAN and Flags sub-TLV 4 1 [TBD].

   o  Length: variable, minimum 1.

   o  Value: The first byte 6 - Number of bytes contained in 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 value field.

   o  Port ID: An ID for the VIDs and the Base VIDs and VIDs or Backbone-VIDs (B-VIDs) are in
   use.  This information should be the same port on all bridges in which the
   topology identified by MT-PORT-CAP TLV it enclosing TRILL IIH PDU
      is being carried.
   Discrepancies between neighbours with respect to sent.  The transmitting RBridge assigns this sub-TLV are
   temporarily allowed but the Base-VID must agree ID such that
      each of its ports has an ID different from all of its other ports.

   o  The first and use second bytes have a spanning
   tree algorithm.

   +-+-+-+-+-+-+-+-+
   |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: copy of the Outer VLAN ID
      associated with the Hello frame when it was sent.  The size lower 4
      bits of the value is VID Tuples*4 + 1 bytes.  Each
      4-byte part first byte give the upper ID bits of the N-VID tuple is formatted as follows:

       0  1 - 3   4 - 15   16 - 19       20 - 31
      +-+----------+-------+-----------+------------+
      |A| Reserved |   VID | Algorithm |    B-VID   |
      +-+----------+-------+-----------+------------+ VLAN ID and
      the second byte gives the lower VLAN ID bits.

   o  The M bit when set upper 4 bits of the first byte are flag bits as shown.  The AF
      bit, if one, indicates that the Mode sending Intermediate System
      believes it is Shortest Path VIDs
      one VID per tree.  When clear this bit Appointed Forwarder for the VLAN and port on which
      the Hello was sent.  The AC bit, if one, indicates that this is
      using single VIDs.  Neighboring bridges must have matching
      configuration or the adjacency
      sending port is rejected.

   o configured as an access port.  The B Bit when set indicates this is Backbone Bridging
      alternatively when clear this bit VM bit, if a
      one, indicates this is Shortest path
      bridging.

   o  Combinations of that the M and B bits are specified in sending Intermediate System has detected
      VLAN mapping within the [IEEE
      802.1aq]. link.  The BY bit, if set, indicates
      bypass psuedonode.

   o  Algorithm: Specifies  The third and forth bytes give the tie breaking algorithm to be used Designated VLAN 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 link.
      The lower 4 bits of the High PATHID algorithm is used.

   o  A bit when set declares this an SPVID with auto allocation.

   o  VID is third byte give the VID for which upper ID bits of the given algorithm applies, see [IEEE
      802.1aq].

   o  B-VID is
      Designated VLAN and the B-VID for which forth byte gives the given algorithm applies, see
      [IEEE 802.1aq].

   o lower VLAN ID bits.
      The "Reserved" fields upper 4 bits of the third byte are reserved and MUST be sent
      as zero and ignored on receipt.

   The Base VLAN-Identifier VLAN and Flags sub-TLV is carried within the MT aware PORT-
   CAP TLV and this is MT-PORT-CAP TLV.  It
   MUST be carried only once in a TRILL 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  It MUST NOT be carried in it.  These sub-TLVs
   announce the capabilities of
   within a LAN or a P2P IIH PDU.

2.3.2.  Enabled VLANs sub-TLV

   The Enabled VLAN sub-TLV specifies the Intermediate System VLANs enabled for end station
   service at 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 port on which 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 Hello was sent.

   +-+-+-+-+-+-+-+-+
   |Type=EnabledVLAN|
   +-+-+-+-+-+-+-+-+
   |   Length      |    Reserved                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Resv |   Max-version   Start Vlan Id         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vlan bit-map....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: sub-TLV Type, set to 5 (TRILL-VER). Enabled VLANs sub-TLV 2 [TBD].

   o  Length: 2 - Total number variable, depending on contents described next.

   o  The minimum size of the value is 3 bytes.  The third and
      subsequent bytes contained provide a bit map of enabled VLANs starting at
      the VLAN ID indicated in the TLV.

   o  Reserved: Set to 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 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 highest order bit of the advertising device, along with information about its priority
      third byte indicates the VLAN equal to hold those nicknames.  The Nickname sub-TLV MUST be carried within the Router CAPABILITY TLV 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 level-1 non-pseudo-node LSP generated
   by Hello and a VLAN is
   enabled for end station service on the originating IS.

   +-+-+-+-+-+-+-+-+
   |Type = NICKNAME|
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                NICKNAME RECORDS (1)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   .................                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                NICKNAME RECORDS (N)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ port where each nickname record the Hellos was sent
   if this is of indicated by any occurrence in the form:

   +-+-+-+-+-+-+-+-+-+
   |    Priority     |    (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Nickname            |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: TLV Type, set to 6 (NICK).

   o  Length: Total number of bytes contained Hello.  For example, a
   receiver could allocate a 512-byte buffer and, with appropriate
   shifting operations, OR 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 enabled bits for each subTLV of this
   type it finds in a one-byte priority set Hello to
   application dependent values, and two bytes derive the complete bit map of device identifier or
   alias (i.e., actual nickname).

2.4.3.  The Trees sub-TLV these
   VLANs.

   The Trees Enabled VLAN sub-TLV MUST occur only once and can be is carried only within the
   Router CAPABILITY TLV MT-PORT-CAP TLV.
   If present, it MUST be carried in a level-1 non-pseudo-node LSP generated by
   the originating IS.  Each device announces four numbers: its own
   priority to TRILL IIH PDU.  It MUST NOT be
   carried within a multi-destination frame distribution tree root; LAN IIH or a P2P IIH PDU.

2.3.3.  Appointed Forwarders sub-TLV

   The Appointed Forwarder sub-TLV provides the
   number of trees it dictates that all mechanism by which the
   Designated Intermediate System can inform other Intermediate Systems in
   the campus compute if it is the highest priority tree root;
   on the
   maximum number of trees it is able to compute; and link that they are 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 designated VLAN-x forwarder for that
   link for one or more ranges of the other nodes in the network, VLAN IDs.

   o  Type: sub-TLV Type, set to determine if it
   is the highest priority root. Appointed Forwarders sub-TLV 3 [TBD].

   o  Length: The node that announced size of the
   numerically highest priority to become a tree root value 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 6*n bytes where there are n
      appointments.  Each 6-byte part of distribution tree roots to be used in the
   network domain and can list those roots in the tree roots identifier
   sub-TLV. value is formatted as
      follows:

   +-+-+-+-+-+-+-+-+
   |Type =  TREE   |
   |Type=App Frwrdr|
   +-+-+-+-+-+-+-+-+
   |   Length      |   (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Tree Root Priority
   +----------------+-----+-----+---------+-----+----+---------+
   |  (2 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   byte 1 - 2   |  Number of trees to compute  byte 3   |  (2 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  byte 4 | Maximum trees able to compute   byte 5 |  (2 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  byte 6 |    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. Appointee Nick | Res | Start VLAN ID | Res | End VLAN ID  |
   +----------------+-----+-----+---------+-----+----+---------+

   o  Tree Root Pri: This  The appointed forwarder Intermediate System 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 specified by its
      nickname in the Layer-2 domain. first two bytes.

   o  Number of trees to compute: This is an unsigned 16-bit integer
      that gives the requested number  The "Res" fields of distribution trees for multi-
      destination frames that will 4 bits each are reserved and MUST 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 sent as
      zero and ignored on receipt.

   The VLAN range given is an unsigned 16-bit
      integer that give the maximum number of threes inclusive.  To specify a single VLAN, that
   VLAN ID appears as both the
      originating IS start and end VLAN.  The Intermediate
   System whose nickname is able to compute given is appointed forwarder for those VLANs
   for which it has end station service enabled (see item 2 above) in
   the campus.

   o  Number of trees to use: This is an unsigned 16-bit integer 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 TRILL Hello.  In the absence of appointed forwarder
   sub-TLVs referring to a VLAN, the Designated Intermediate System acts
   as the appointed forwarder for that
      gives VLAN if end station service is
   enabled.

   The Appointed Forwarder sub-TLV is carried within the number MT-PORT-CAP
   TLV.  If present, it MUST be carried in a TRILL IIH PDU.  This MUST
   NOT be carried in a LAN IIH PDU or 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.

   The bit-encoded options supported are indicated by an HBHOPT sub-TLV
   of length 3: an initial value byte of 0x00 followed by two bytes in
   which each bit indicates that the corresponding bit option is
   implemented; in those two bytes the top two bits (0xC000) are
   critical option summary bits that all RBridges MUST understand;
   therefore support for these bits need not be advertised.  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.

   +-+-+-+-+-+-+-+-+
   |Type = B-VID   |
   +-+-+-+-+-+-+-+-+
   |   Length      |    (1 byte)
   +-+-+-+-+-+-+-+-+--------------------------------
   |      ECT - VID Tuple (1)  (6 bytes)           |
   +-----------------------------------------------+
   |      .........................                |
   +-----------------------------------------------+
   |      ECT - VID Tuples (N)  (6 bytes)          |
   +-----------------------------------------------+

   o  Type: sub-TLV Type, set to Base-VALN-ID sub-TLV 5 [TBD].

   o  Length: The size of the value is ECT-VID Tuples*6 bytes.  Each
      6-byte part of the ECT-VID tuple is formatted as follows:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     ECT - Algorithm (32 bits)                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Base VID (12 bits)    |U|M|RES|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  ECT-ALGORITHM (4 bytes) The ECT-ALGORITHM is advertised when the
      bridge supports a given ECT-ALGORITHM (by OUI/Index) on a given
      Base VID

   o  Base VID (12-bits) The Base-VID that is associate with the SPT
      Set.

   o  Use-Flag (1-bit) The Use-flag is set if this bridge, or any bridge
      that this bridge sees is currently using this ECTALGORITHM and
      Base VID.

   o  M-Bit (1-bit) The M-bit indicates if this is SPBM or SPBV mode.

   The Base VLAN-Identifier sub-TLV is carried within the MT-PORT-CAP
   TLV and this is carried in a IIH PDU.

2.3.6.  SPB Digest 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.

   +-+-+-+-+-+-+-+-+
   |Type =SPBDigest|
   +-+-+-+-+-+-+-+-+
   |   Length      |    (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           MCID (50 Bytes)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Aux   MCID (50 Bytes)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Agreement Digest (32 Bytes)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |RES      | A| D|
   +-+-+-+-+-+-+-+-+

   o  Type: sub-TLV Type, set to SPB Digest sub-TLV 6 [TBD].

   o  Length: The size of the value defined below.

   o  MCID (50-bytes) The complete MCID defined in IEEE 802.1Q which
      identifies an SPT Region.

   o  Aux MCID (50-bytes) The complete MCID defined in IEEE 802.1Q which
      identifies an SPT Region.  The aux MCID allows SP Regions to be
      migrated allocating new VLAN to FID Mappings.

   o  Agreement Digest (32-bytes) This digest is use to determine when
      IS-IS is synchronized between neighbors.

   o  A (2 bits) The agreement number 0-3 which aligns with BPDUs
      agreement number concept.  When the Agreement Digest for this node
      changes this number is updated and sent in the hello.

   o  D (2 bits) The discarded agreement number 0-3 which aligns with
      BPDUs agreement number concept.  When the Agreement Digest for
      this node changes this number is updated.  Once an Agreement has
      been sent it is considered outstanding until a matching or more
      recent Discarded Agreement Number is received.

   The SPB Digest sub-TLV is carried within the MT-PORT-CAP TLV and this
   is carried in a IIH PDU.

2.3.7.  Site Identifier sub-TLV

   The site identifier sub-TLV carries information about the site this
   device belongs to.

      +-+-+-+-+-+-+-+-+
      |Type = SiteCap |
      +-+-+-+-+-+-+-+-+
      |   Length      |                  (1 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                System ID (6 bytes)                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Cluster ID (2 bytes) |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Flags (1 byte)|
      +-+-+-+-+-+-+-+-+

   o  Type: sub-TLV Type, set to Site Identifier sub-TLV 250 [TBD].

   o  Length: The size of the value.

   o  System Id: The system-id of the site.

   o  Cluster Id: The cluster-id within the site.

   o  Flags: Indicates unicast reachability.

2.3.8.  Site Group IPv4 sub-TLV

      +-+-+-+-+-+-+-+-+
      |Type=SiteGrpIP |
      +-+-+-+-+-+-+-+-+
      |   Length      |                  (1 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                IPv4 address (4 bytes)                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                ..................                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                IPv4 address (4 bytes)                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: sub-TLV Type, set to Site Group IP sub-TLV 251 [TBD].

   o  Length: The size of the value.

   o  Value: The list of IPv4 addresses used by the site.

2.3.9.  Site Group IPv6 sub-TLV

      +-+-+-+-+-+-+-+-+
      |Type=SiteGrpIPv6|
      +-+-+-+-+-+-+-+-+
      |   Length      |                  (1 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                IPv6 address (16 bytes)                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                ..................                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                IPv6 address (16 bytes)                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: sub-TLV Type, set to Site Group IPv6 sub-TLV 252 [TBD].

   o  Length: The size of the value.

   o  Value: The list of IPv6 addresses used by the site.

2.3.10.  Adjacency Server IPv4 sub-TLV

      +-+-+-+-+-+-+-+-+
      |Type = ASIPv4  |
      +-+-+-+-+-+-+-+-+
      |   Length      |                  (1 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                IPv4 address (4 bytes)                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                ...................                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                IPv4 address (4 bytes)                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Flags(1 byte)|
      +-+-+-+-+-+-+-+-+

   o  Type: sub-TLV Type, set to Adjacency Server IP sub-TLV 253 [TBD].

   o  Length: The size of the value.

   o  Value: The list of IPv4 addresses used by the site.

   o  Flags: Indicates unicast reachability.

2.3.11.  Adjacency Server IPv6 sub-TLV

      +-+-+-+-+-+-+-+-+
      |Type = ASIPv6  |
      +-+-+-+-+-+-+-+-+
      |   Length      |                  (1 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                IPv6 address (16 bytes)                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                .................                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                IPv6 address (16 bytes)                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Flags(1 byte)|
      +-+-+-+-+-+-+-+-+

   o  Type: sub-TLV Type, set to Adjacency Server IPv6 sub-TLV 254
      [TBD].

   o  Length: The size of the value.

   o  Value: The list of IPv6 addresses used by the site.

   o  Flags: Indicates unicast reachability.

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 vlaue.

   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 (NICKNAME) 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 a Router CAPABILITY TLV in a level-1 LSP generated by
   the originating IS.  Multiple instances of this sub-TLV are allowed
   to be carried.

   +-+-+-+-+-+-+-+-+
   |Type = NICKNAME|
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                NICKNAME RECORDS (1)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   .................                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                NICKNAME RECORDS (N)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where each nickname record is of the form:

   +-+-+-+-+-+-+-+-+-+
   |Nickname Priority|    (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Tree Root Priority        |  (2 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Nickname            |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: TLV Type, set to 6 (NICKNAME).

   o  Length: 5*N, where N is the number of nickname records present.

   o  Nickname Priority: Priority with which this node holds this
      nickname.

   o  Tree Root Priority: This is an unsigned 16-bit integer that gives
      the value of the priority with which this nickname wants to be the
      highest priority root node in the Layer-2 domain.

   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, two bytes of tree root priority 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 is carried within the
   Router CAPABILITY TLV in a level-1 non-pseudo-node LSP generated by
   the originating IS.  Each device announces three numbers: 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 to
   ensure if this node is reachable.  On the reachable set of the nodes,
   independently of the other nodes in the network, it determine if it
   has the nickname that has the highest priority root.  The node that
   announced the numerically highest priority nickname to become a tree
   root is elected 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.  If system IDs also tie, the
   device with the highest nickname value, considered as an unsigned
   integer, wins.  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)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  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  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 trees 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 Root Identifiers Sub-TLV

   The tree root identifiers sub-TLV 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
   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 Router 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 Number: This identifies the starting tree number 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 on which this tree is based.

2.4.5.  The Trees Used Identifiers 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.

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 10 + 6*n where
   n is the number of root bridge IDs.  The TLV layout is 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.  The Appointed Forwarder
      Status Lost Counter is also included here.  It 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.  It has the following format:
     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 or the Appointed Forwarder Status Lost Counter
   are different, the sub-TLV is incorrect and must be split into
   multiple sub-TLVs each indicating only VLANs with the same M4, M6,
   and Appointed Forwarder Status Lost Counter values.  If there are any
   two VLANs in the range indicated for which the set of distribution trees root bridge IDs
   see on all links for which the originating IS wishes 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 able too verbose.

   Wherever possible, an implementation SHOULD advertise the update to use.

2.4.4.  The Tree Roots Identifier Sub-TLV

   The tree root identifier a
   interested vlan and spanning trees sub-TLV in the same LSP fragment
   as the advertisement that it replaces.  Where this is is not possible,
   the two affected LSP fragments should be flooded as an ordered list of nicknames.
   When originated atomic action.

   Systems that receive an update to an existing interested vlan and
   spanning sub-TLV can minimize the potential disruption associated
   with the update by employing a holddown time prior to processing the Intermediate System which is
   update so as to allow for the highest
   priority tree root, this list is receipt of multiple LSP fragments
   associated with the tree roots same update prior to beginning processing.

   Where a receiving system has two copies of a interested vlan and
   spanning sub-TLV from the same system that have different settings
   for a given vlan, the procedure used to choose which other
   Intermediate Systems are required copy shall be
   used is undefined (refer to compute trees.  If this
   information RFC 4971, Section 3).

   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 spread across multiple sub-tlvs, the starting tree
   root identifier
   primary, or may be zero if there is used to figure out the ordered list. no primary.  It is carried within
   the CAPABILITY TLV in a level-1 non-pseudo-node LSP and is given as: structured
   as follows:

   +-+-+-+-+-+-+-+-+
   |Type=TREE-RT-ID|
   |Type=VLAN-GROUP|
   +-+-+-+-+-+-+-+-+
   |   Length      |   (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Starting Tree Root Identifier|    (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Nickname (K-th root)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Primary VLAN ID (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Nickname (K+1 - th root)   |  Secondary VLAN ID (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |   Nickname (...)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   ........   Possibly more Secondary VLAN IDs ..........      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: sub-TLV TLV Type, set to 8 (TREE-RT-IDs). 11 (VLAN-GROUPs).

   o  Length: Total number of bytes contained in the value field. field, 4 +
      2*n, where n may be 0.

   o  Starting Tree Root Identifier:  Primary VLAN-ID: This identifies the starting tree
      root identifier of the nicknames which are roots for the domain. primary VLAN-ID.

   o  Secondary VLAN-ID: This identifies the secondary VLAN-ID, address
      learning is set to 1 for shared at the first Intermediate System that announces this
      sub-TLV.

   This sub-TLV may appear zero, one, or multiple times.

2.4.8.  The starting value and
      the length field gives the number of nicknames being carried Ingress-to-Egress Options (ITEOPT) sub-TLV

   By including this sub-TLV within one or more Router Capability TLVs
   in
      the sub-TLV.  In the event a tree identifier its LSPs, an RBridge can be computed from
      two such sub-TLVs and are different, then advertise the Ingress-to-Egress options
   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 supports.  This sub-TLV 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 appear zero or more times within a discrepancy
   between
   Router Capability TLV.  By default, in the number absence of multi-destination trees the broadcast-root has
   announced, and the number any ITEOPT sub-
   TLVs, no Ingress-to-Egress options are supported.

   There are two types of roots the root-identifier sub-tlv
   carries, nodes MUST compute trees for Ingress-to-Egress option encoding within the additional roots.

2.4.5.
   TRILL Header: bit options and TLV encoded options.

   The Tree Used Identifier Sub-TLV

   This bit-encoded options supported are indicated by an ITEOPT sub-TLV has the same structure as
   of length 3: an initial value byte of 0x00 followed by two bytes in
   which each bit indicates that the Tree Roots Identifier Sub- corresponding bit Ingress-to-Egress
   option is implemented.

   Other Ingress-to-Egress options are TLV specified in encoded within the above section. TRILL
   Header options area.  The only difference implementation of a TLV encoded option is that its
   indicated by an ITEOPT sub-TLV type is set whose value starts with a byte equal
   to 9 TBD (TREE-USE-IDs) and the roots listed are
   only those that first byte of the originating intermediate systems wishes to use.

2.4.6.  Interested VLANs and Spanning Tree Roots sub-TLV

   The option.  Such ITEOPT sub-TLVs may have
   additional value of this sub-TLV consists of a VLAN range, flags, and bytes further indicating how the option is supported
   as specified in the option's definition, for example a
   variable length list of spanning tree root bridge IDs.  This
   supported security algorithms.

   +-+-+-+-+-+-+-+-+
   | Type = ITEOPT |
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+
   |    Option     |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Option dependent variable length information            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: sub-TLV
   may appear zero, one, or many times. Type, set to Ingress-to-Egress option sub-TLV 12
      [TBD].

   o  Length: variable, minimum 1.

   o  Value: The union first byte of the option followed by option dependent
      information.

2.4.9.  VLAN ranges in
   all occurrences MUST be precisely the set of VLANs for which Mapping (VMAP) sub-TLV

   The VLAN Mapping (VMAP) TLV carries information concerning VLAN
   mappings configured at the originating Intermediate System IS.  VLAN mapping is appointed forwarder on at least
   one port and used when
   an RBridge campus is divided into regions such that the same VLAN ranges is
   represented by different VLAN IDs in multiple VLANs sub-TLVs for an
   Intermediate System MUST NOT overlap.  That is, the intersection of
   the different regions or there is a
   VLAN ranges for any pair is one region that has no equivalent in another region.  As
   specified in [VMAP], each port on each of these sub-TLVs originated by an
   Intermediate System must the border RBridges between
   two or more regions MUST be null. configured at to which region each port
   connects with.  The value length is 4 + 6*n where
   n numbering of regions is an arbitrary choice but
   all border RBridges in the campus MUST agree on the number of root bridge IDs.  The initial 4 bytes of value are
   as follows: each
   region.

   +-+-+-+-+-+-+-+-+
   |Type
   |  Type = INT-VLAN| VMAP  |
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +---------------+-----+
   +-+-+-+-+-+-+-+-+----------...+
   |   Nickname-Id      Mapping 1              |    (8 bytes)
   +-+-+-+-+-+-+-+------------...
   |      Mapping N, etc.|
   +--------------------------...

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Count |     From VLAN ID      |    (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Interested VLANS          From Region          |  (8    (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Root Bridges RESV |  (6*n      To VLAN ID        |    (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          To Region            |    (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: sub-TLV Type, set to 10 (INT-VLAN). VLAN Mapping sub-TLV 13 [TBD].

   o  Length: Total number of bytes contained in the value field. variable, 8*N.

   o  Nickname Id:  Value: Specific information on each VLAN mapping as diagrammed
      above and specified below:

      *  Count: If this four bit unsigned integer is set to 0, zero or 1, then the
         mapping of a single VLAN ID is being specified.  If it applies to all device-
      ids generated by is any
         value from 2 through 15, then a block of that many contiguous
         VLAN IDs starting with the node.  It may alternatively be set From VLAN ID is mapped to a
      specific nickname-id, in block of
         that many contiguous VLAN IDS starting with the event To VLAN ID.

      *  From VLAN ID: This is the VLAN ID that, when received on a node wants port
         connect 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 From Region on a link for
      which frame being sent to the originating Intermediate System To
         Region, is appointed forwarder
      for every VLAN in the indicated range.  The M6 bit indicates mapped to the
      same for an IPv6 multicast router.  The R and Reserved bits MUST To VLAN ID.  This must be sent as zero and are ignored on receipt.  The a real VLAN start
         ID, that is, the values 0x000 and
      end IDs 0xFFF are inclusive.  A range of one VLAN ID prohibited.

      *  From Region: This is indicated by
      setting them both the region number, within the campus, such
         that frames received on a port connected to that region and
         destined to a port connected to the To Region have their VLAN
         ID value.  It has mapped as specified by the following
      format:

     0    1    2    3     4 - 15      16 - 19     20 - 31
   +----+----+----+----+------------+----------+------------+
   | M4 | M6 |  R |  R | From VLAN start | Reserved | ID and To VLAN end  |
   +----+----+----+----+------------+----------+------------+
   |       Appointed Forwarder Status Lost Counter          |
   +----+----+----+----+------------+----------+------------+

   o  Root Bridges: The list of ID
         fields.

      *  RESV: MUST be sent as 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. on sub-TLV creation and ignored on
         receipt.

      *  To VLAN ID: This information is learned from BPDUs heard by the
      Intermediate System.  If MSTP is in use VLAN ID to be used on frames sent out a link, the root bridge
      referred
         port connected to is the CIST (common and internal spanning tree) root
      bridge.  (While, of course, only one spanning tree root should be
      seen To Region if they were received on any particular port, there may be multiple ports in the
      same VLAN a port
         connected to differed bridged LANs the From Region with different
      spanning tree roots.)  If no spanning tree roots can be seen on
      any of the links in any of From VLAN ID; except that
         if the VLANs To VLAN ID is 0x000 the frame is dropped.  The value
         invalid VLAN ID 0xFFF is prohibited in this field.

      *  To Region: This is the range indicated for
      which region number, within the Intermediate System is appointed forwarder (for example
      all campus, such links are point-to-point links
         that frames sent on a port connected to other Intermediate
      Systems or this region from a port
         connected 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 From Region have their VLAN ID mapped as
         specified by the range indicated for From VLAN ID and To VLAN ID fields.

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 value
   of entire routing
   domain.  This is different from Router Capability TLV defined in RFC
   4971, in the M4, or M6 bits are different, sense, the sub-TLV capabilities announced here are topology
   scoped.

   The Multi Topology Aware Capability (MT-CAPABILITY) is incorrect and
   must an optional
   IS-IS TLV type 144 [TBD], that may be split into multiple sub-TLVs each indicating only VLANs with generated by the same M4, originating IS
   and M6 values.  If there are any two VLANs in the range
   indicated for which 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 root bridge IDs see on all links for
   which bytes contained in the Intermediate System is appointed forwarder for value field,
      including the VLAN are
   not length of the same, sub-TLVs carried in this TLV.

   o  O bit: The overload bit that follows the sub-TLV is incorrect and must be split into
   multiple subTLVs each indicating only VLANs semantics associated with
      an overloaded intermediate system.

   o  Topology Identifier: MT ID is a 12-bit field containing the same set MT ID
      of DRB
   seen root bridge IDs.  It the topology being announced.  This field when set to zero
      implies that it is always safe being used to use sub-TLVs with a
   "range" of one VLAN ID but carry base topology information.
      In TRILL this value is set to ZERO, however, in IEEE SPB and SPBB,
      it may be too verbose.

   This sub-TLV is 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-CAPABILITY TLV MUST be carried only within the CAPABILITY TLV a LSP PDU.  It may
   occur multiple times in a level-1 non-
   pseudo-node LSP.

2.4.7.  The VLAN Group LSP PDU.

2.5.1.  SPB Instance sub-TLV

   The VLAN Group SPB Instance sub-TLV consists of two or more 16-bit fields each of
   which has a VLAN ID gives the SPSourceID for this node/topology
   instance.  This is the 20 bit value that is used in the low order 12 bits. formation of
   multicast DA addresses for packets originating from this node/
   instance.  The top SPSourceID occupies the upper 20 bits of the multicast
   DA together with 4 other bits MUST be
   sent as zero and ignored on receipt.  The first such VLAN ID is (see the
   primary, or may SPB 802.1ah multicast DA
   address format section).

   This sub-TLV SHOULD be zero if there is no primary.  It is carried within the CAPABILITY MT-Capability TLV in a level-1 non-pseudo-node LSP and is given as:

   +-+-+-+-+-+-+-+-+
   |Type=VLAN-GROUP|
   +-+-+-+-+-+-+-+-+ the
   fragment ZERO LSP.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Length               CIST Root Identifier  (4 bytes)                 |   (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        VLAN-GROUP RECORDS (1)               CIST Root Identifier (cont)  (4 bytes)          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   .................           CIST External ROOT Path Cost     (4 bytes)          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        VLAN-GROUP RECORDS        Bridge Priority        |         (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R|  SPS Flags  |V|              SPSOURCEID               | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    N-VID       Trees   |               (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  VLAN-ID (1) Tuples   (48 bytes)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  VLAN-ID (N) Tuples   (48 bytes)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Opaque ECT Algorithm    (32 bytes)           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Opaque ECT Information (variable )           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where each VLAN group record is of VLAN-ID tuples have the form:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ format as:

       0 1   2- 3     4 - 15   16 - 19       20 - 31
      +-+-+---------+-------+-----------+------------+
      |A|U|Reserved |   Primary VLAN ID (2 bytes)   VID |  Secondary VLAN ID (2 bytes) Algorithm |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    B-VID   |
      +-+-+---------+-------+-----------+------------+

   o  Type: TLV sub-TLV Type, set to 11 (VLAN-GROUPs). SPB Instance sub-TLV 1 [TBD].

   o  Length: Total number of bytes contained in the value field.

   o  Primary VLAN-ID:  CIST Root Identifier (64-bits)The CIST Root Identifier is for SPB
      interworking with RSTO and MSTP at SPT RegionBoundaries.  This identifies the primary VLAN-ID. is
      an imported value from a Spanning tree.

   o  Secondary VLAN-ID: This identifies  CIST External Root Path Cost (32-bits) The CIST External Root Path
      Cost is the secondary VLAN-ID, address
      learning cost from the Spanning tree algorithm to the Root.

   o  Bridge Priority (16-bits) Bridge priority is shared at the Intermediate System 16 bits that announces this
      sub-tlv.
      together with the low 6 bytes of the System ID form the Bridge
      Identifier.  The Bridge Identifier is the Spanning tree compatible
      Bridge identifier.  This sub-TLV may appear zero, one, or multiple times.

2.4.8. is configured exactly as specified in
      IEEE802 [802.1D].  This allows SPB to build a compatible Spanning
      tree using link state by combining the Bridge Priority and the
      System ID to form the 8 byte Bridge Identifier.  The Ingress-to-Egress Options (ITEOPT) sub-tlv

   By including 8 byte Bridge
      Identifier is also the input to the 16 pre defined ECT tie breaker
      algorithms.

   o  V bit (1-Bit) The V bit (SPBM) indicates this sub-TLV within one or more Router Capability TLVs
   in its LSPs, an RBridge can advertise SPSourceID is auto
      allocated(27.11).  If the Ingress-to-Egress options V 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 supports.  This sub-TLV may appear zero or more times within will
      allocate a SPSourceID according to the allocation logic(27.11).

   o  The SPSOURCEID is a
   Router Capability TLV.  By default, in 20 bit value used to construct multicast DA's
      as described below for multicast packets originating from the absence
      origin (SPB node) 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. link state packet (LSP) that contains
      this TLV.  More details are in [IEEE 802.1aq].

   o  Number of Trees (8-bits) The implementation Number of a TLV encoded option Trees is
   indicated by an ITEOPT sub-TLV whose value starts with a byte equal be set to the first byte
      number of [ECT-ALGORITHM, Base-VID plus flags] sub TLV's that
      follow.  Each ECT-ALGORITHM has an Base VID, an SPVID and some
      flags described below.  This must be set to at least one ECT.
      These define the option.  Such ITEOPT sub-TLVs standard ECTs.  In addition proprietary ECTs may have
   additional value bytes further indicating how the option is supported
   as specified
      be defined in the option's definition, for example a list opaque TLV S bit indicates the presence of
   supported security algorithms.

   +-+-+-+-+-+-+-+-+
   | 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]. sub-
      TLVs following this value.

   o  Length: variable, minimum 1.  Each VID Tuple consists of:

   o  Value:

      *  U-Bit (1-bit) The first byte of the option followed by option dependent
      information.

2.5.  Multi Topology Aware Capability TLV Use flag is set if this bridge, is currently
         using this ECT-ALGORITHM for I-SIDs it sources or sinks.  This section defines a new optional Intermediate System to
   Intermediate System (IS-IS) TLV named MT-CAPABILITY, formed of
   multiple sub-TLVs, which allows
         is a router to announce its capabilities bit different than the U-bit found in the Hello, which
         will set the Use-Flag if it sees other nodal Use-Flags are set
         OR it sources or sinks itself.

      *  M-Bit (1-bit) The M-bit indicates if this is SPBM or SPBV mode.

      *  A bit, The A bit (SPB) when set declares this is an SPVID with
         auto allocation(27.11).  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 particular topology within
         bridge that has an SPVID of 0.  When the bridge allocating is
         synchronized with the IS-IS level adjacency, it will allocate one or
         more SPVIDs according to the entire routing
   domain.  This allocation logic.

   o  ECT-ALGORITHM (4-bytes) ECT-ALGORITHM is different advertised when the
      bridge supports a given ECT-ALGORITHM (by OUI/Index) on a given
      VID.  This declaration must match the declaration in the Hello PDU
      originating from Capability TLV defined the same bridge.  The ECT-ALGORITHM, BASE-VID
      should match what is generated in RFC 4971, the Hellos of the same node.
      The ECT-ALGORITHM, BASE-VIDs pairs can come in any order however.

   o  Base VID (12-bits) The Base-VID that associated the sense, SPT Set via
      the capabilities announced here are topology scoped. ECT-ALGORITHM.

   o  SPVID (12-bits) The Multi Topology Aware Capability (MT-CAPABILITY) SPVID is the Shortest Path VID when using SPBV
      mode.  It is not defined for SPBM Mode and should be 0 in SPBM
      mode.

   o  an optional
   IS-IS opaque ECT Data TLV type 144 [TBD], that may be generated by (type TBD) whose first 32 bits are the originating IS ECT-
      ALGORITHM which this data applies to.

2.5.2.  SPBM Service Identifier and has Unicast Address sub-TLV

   The SPBM Service Identifier and Unicast Address sub-TLV is used to
   introduce service group membership on the following format: 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Type=MTCAPABTLV| Length        |O|R|R|R|  Topology Identifier
      |                          B-MAC ADDRESS                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            sub-TLVs   B-MAC ADDRESS (cont)        |  Res. |    Base-VID           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |T|R| Reserved  |                  ISID  #1                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |T|R| Reserved  |                  ISID  #2                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |T|R| Reserved  |                  ISID  #n                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: TLV sub-TLV Type, set to MT-CAPABILITY TLV 144 SPBM Service Identifier and Unicast
      Address sub-TLV 2 [TBD].

   o  Length: Total number of bytes contained in the value field,
      including field.

   o  B-MAC ADDRESS is a unicast address of this node.  It may be either
      the length single nodal address, or may address a port or any other level
      of granularity relative to the sub-TLVs carried in node.  In the case where the node
      only has one B-MAC address this TLV. 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  O bit: The overload  ISID #1 .. #N are 24 bit that follows the semantics associated with service group membership identifiers.  If
      two nodes have an overloaded ISID in common, intermediate system.

   o  Topology Identifier: MT ID is a 12-bit field containing nodes on the MT ID
      of unique
      shortest path between them will create forwarding state for the topology being announced.  This field when set to zero
      implies that it is being used to carry base topology information.
      In TRILL this value is set
      related B-MAC addresses and will also construct multicast
      forwarding state using the ISID and the node's SPSOURCEID to ZERO, however,
      construct a multicast DA as described in IEEE SPB 802.1aq LSB.  Each
      ISID has a Transmit(T) and SPBB,
      it may be non-zero.

   o  sub-tlvs: The MT aware Capabilities TLV value contains sub-TLVs
      formatted Receive(R) bit which indicates if the
      membership is as described in [RFC5305].  They a Transmitter/Receiver or both (with both bits
      set).  In the case where the Transmit(T) and Receive(R) bits are defined in
      both zero, the next
      sections.

   The MT-aware CAPABILITY ISID is ignored.  If more ISIDs are associated with
      a particular B-MAC than can fit in a single TLV, this TLV MUST can be carried
      repeated with the same B-MAC but with different ISID values.

2.6.  Sub-TLVs of the Extended Reachability TLV

   This section specifies two new sub-TLVs that appear only within a LSP PDU.
   It may occur multiple times in a LSP PDU.

2.5.1. the
   Extended Reachability TLV (type 22).

2.6.1.  SPB Instance Link Metric sub-TLV

   The SPB Instance Link Metric sub-TLV gives occurs nested as within the SPSourceID for this node/topology
   instance.  This is Extended
   Reachability TLV (type 22), or the 20 bit value that Multi Topology Intermediate System
   TLV (type 222).  If this sub TLV is used in the formation of
   multicast DA addresses not present 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 an ISIS adjacency
   then that adjacency MUST NOT carry SPB 802.1ah multicast DA
   address format section).

   This TLV SHOULD be carried within traffic for the fragment ZERO LSP. 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |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) (must be 0)                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        CIST Root Identifier                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       SPB-LINK-METRIC                         |                        CIST Root Identifier (cont) Num port ID   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 CIST External ROOT Path Cost     Port  Identifier          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where VLAN-ID tuples have the format as:

       0 1   2- 3     4 - 15   16 - 19       20 - 31
      +-+-+---------+-------+-----------+------------+
      |A|U|Reserved |   VID
      |                  Opaque ECT Algorithm    (32 bytes)           |    B-VID
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |
      +-+-+---------+-------+-----------+------------+                  Opaque ECT Information (variable )           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: TLV Type, set to SPB Instance Link Metric sub-TLV 1 5 [TBD].

   o  Length: Total number of bytes contained in the value field.

   o  S bit  SPB-LINK-METRIC indicates the presence administrative cost or weight of sub-TLVs following
      using this value.

   o  The N-VID must be set 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 VIDs tuples that follow.
      This allows ports associated with this link.

   o  Port Identifier is the sub-TLV starting point standard IEEE port identifier used to be found.  Note N-VID
      here does not include the Base VID.

   o  Each VID Tuple consists of: build
      a spanning tree associated with this link.

   o  ALG specifies  an opaque ECT Data TLV (type TBD) whose first 32 bits are the tie breaking algorithm to be used for ECT-
      ALGORITHM which this VID.
      Currently only data applies to.

2.6.2.  MTU sub-TLV

   The MTU sub-TLV is used to optionally announce the following values are supported:

      *  ALG = 0 MTU of a spanning tree.

      *  ALG link.  It
   occurs nested as within the Extended Reachability TLV (type 22).

   +-+-+-+-+-+-+-+-+
   | Type = 1 MTU    |
   +-+-+-+-+-+-+-+-+
   |   Length      |                       (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |F|         Reserved            |       (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               MTU             |       (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: TLV Type, set to MTU sub-TLV 6 [TBD].

   o  Length: Total number of bytes contained in the Low PATHID algorithm value field.

   o  Failed: This bit is used for a one if MTU testing on this VID.

      *  ALG = 2 link failed at
      the High PATHID algorithm is used. required campus-wide MTU.

   o  VID  MTU: This field is set to the VID largest successfully tested MTU size
      for which the given algorithm applies.  This
      structure this link or zero if it has not been tested.

2.7.  TRILL Neighbor TLV

   The TRILL Neighbor TLV is used to indicate both shortest path VIDs and Single
      VIDs in the Case TRILL-Hello PDU in place of SPBB.  Note the VID represents the SPVID
      associated with SPT Set. More details are
   IS Neighbor TLV.  It differs 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 MTU information is an SPVID with auto
      allocation.  If the VID value provided per
   neighbor and provision 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) made for traffic from a bridge fragmentation, so 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 not all
   neighbors need be reported in each TRILL-Hello, to support the allocation logic.  It will then re-advertise this LSP with hard
   limit on the
      allocated value.  If bridges detect a collision size of TRILL-Hellos.  The structure of allocated
      SPVIDs the loosing bridge will have its forwarding removed just as
      if it was unallocated.  When the originating bridge detects it TRILL
   Neighbor TLV is
      a loosing bridge in a collision it reallocates and simply re-
      advertises a new SPVID.  A bridge SHOULD remember SPVID
      allocations through restarts as follows:

   +-+-+-+-+-+-+-+-+
   | Type = TNeigh |
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |S|L|  Reserved                 |     (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   sender nickname             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Neighbor RECORDS (1)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   .................                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Neighbor RECORDS (N)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The list of neighbors MUST be ordered by storing them in non volatile
      memory and therefore reuse MAC address, considering
   each 6-byte MAC address to be an unsigned integer, starting with the SPVID value.

   o
   smallest.  The SPSOURCEID information present for each neighbor is a 20 bit value used to construct multicast DA's as described below for multicast packets originating from the
      origin (SPB node) follows:

   +-+-------------------+
   |F|   Reserved        |     (2 bytes)
   +-+-------------------+
   |       MTU           |     (2 bytes)
   +--------------------------------------------------------+
   |   MAC Address                                          | (6 bytes)
   +--------------------------------------------------------+

   o  Type: TLV Type, set to TRILL-Neighbor TLV XX [TBD].

   o  Length: Total number of the link state packet (LSP) that contains
      this TLV.  More details are bytes contained in [REF]. the value field, 4
      +10*n, where n is the number of neighbor records.

   o  The Auto Allocation Tie Breaker  S: smallest flag.  If this bit is a reserved field that would
      allow collisions in SPSOURCEID to be resolved.  If these fields
      are equal one, then the Bridge Priority takes precedence and if Bridge
      Priority is equal then list of
      neighbors includes the numerically higher Bridge ID wins.  The
      V bit indicates neighbor with the smallest MAC address.

   o  L: largest flag.  If this SPSOURCEID bit is auto allocated.  Note
      SPSOURCEIDs are only used in a one, then the case list of Backbone Brides neighbors
      includes the neighbor with
      single VIDs ( Base-VID TLV B bit = 1 and M bit = 0).  Single VIDS the largest MAC address.

   o  Reserved: These bits are not auto allocated. reserved for future use and MUST be set
      to zero on transmission and ignored on receipt.

   o  Sender nickname: If the A bit sending intermediate system is clear the SPSOURCEID has
      been configured and must holding any
      nicknames, one MUST be unique.  When included here.  Otherwise, the bridge allocating
      receives field is set
      to zero.  This field is to support intelligent end stations that
      determine the complete LSP from egress RBridge for unicast data through a directory
      service or the IS-IS adjacency it will
      allocate like and need a SPSOURCEID according nickname for their first hop to
      insert as the allocation logic.  It will
      then re-advertise this LSP with the allocated value.  If bridges
      detect ingress nickname to correctly format a collision of allocated SPSOURCEIDs TRILL
      encapsulated data frame.

   o  F: failed.  This bit is a one if MTU testing to their neighbor
      (see Section 3.3) failed at the loosing bridge
      (determined by required campus-wide MTU

   o  MTU: This field is set to the tie breaking algorithm) will have its
      forwarding removed just as largest successfully tested MTU size
      for this neighbor or zero if it was unallocated.  When has not been tested.

   o  MAC Address: The MAC address of 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 neighbor as in non volatile memory the IS Neighbor
      RLV (#6).

2.8.  The Group Membership Active Source TLV

   The Group Active Source (GMAS) TLV is IS-IS TLV type 146 [TBD] and reuse
   has the SPSOURCEID
      value. 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 = GMAS    | Length        |              sub-TLVs         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   o  Bridge Identifier is  Type: TLV Type, set to GMAS-TLV 146 [TBD].

   o  Length: Total number of bytes contained in the Spanning tree compatible Bridge
      identifier.  This is configured exactly value field, which
      includes the length of the sub-TLVs carried in this TLV.

   o  sub-TLVs: The Group Active Source TLV value contains sub-TLVs
      formatted as described in [RFC5305].  The sub-TLVs for this TLV
      are specified in IEEE802
      [802.1D].  This allows SPB to build a compatible Spanning tree
      using the following subsections.

   The GMAS TLV is carried within Multicast Group Level 1 link state.

   o state
   PDU.

2.8.1.  The Group MAC Active Source sub-TLV

   The four most significant bits of Group MAC Source (GMAS-MAC) sub-TLV is IS-IS sub-TLV type 1
   within the most significant byte GMAS TLV and has the following format:

   +-+-+-+-+-+-+-+-+
   | Type=GMAS-MAC |                  (1 byte)
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+
   |   Confidence  |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Topology-Id/ Nickname-Id    |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |G|S|R|R|      VLAN-ID          |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Num Group Recs |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   GROUP RECORDS (1)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   .................                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   GROUP RECORDS (N)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where each group record is of a
      Bridge Identifier comprise a settable priority component that
      permits the relative priority form:

   +-+-+-+-+-+-+-+-+
   |    RESERVED   |    (1 byte)
   +-+-+-+-+-+-+-+-+
   | Num of Bridges 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 be managed.  The next
      most significant twelve bits 1 (GMAS-MAC) of a Bridge Identifier (the four
      least significant bits length 1 byte.

   o  Length: Total number of bytes contained in the most significant byte, plus value field.

   o  Confidence: This carries an 8-bit quantity indicating the
      second most significant byte) comprise a locally assigned system
      ID extension.  The six least significant bytes ensure
      confidence level in the
      uniqueness of MAC addresses being transported.  Whether
      this field is used, and its semantics if used, are further defined
      by the Bridge identifier; they shall specific protocol using Layer-2-IS-IS.  If not used, it
      MUST be derived from
      the globally unique Bridge Address according set to zero on transmission and be ignored on receipt.

   o  Topology-Id/Nickname-Id: Depending on the following
      procedure.  The third most significant byte technology in which it
      is derived from used, this carries the
      initial byte of topology-id or nickname-id.  When this
      field is set to zero this implies that the MAC Address; the least significant bit addresses are
      reachable across all topologies or across all nicknames of the
      byte (Bit 1)
      originating IS.

   o  RESERVED: Must be sent as zero on transmission and is assigned ignored on
      receipt.

   o  G: Delivery Group is set

   o  S: Delivery Source is set

   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 the first bit Group Records: This is of length 1 byte and lists the Bridge
      Address, the next most significant bit
      number of group records in this TLV.

   o  Group Record: Each group record has a reserved space and is assigned
      followed by the value 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 second multicast bit of in the Bridge Address, and so on.  The fourth
      through eighth bytes are similarly assigned
      address.  If the values number of the
      second sources do not fit in a single sub-TLV,
      it is permitted to have the sixth bytes same group address repeated with
      different source addresses in another sub-TLV of another instance
      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 Group Active Source TLV.

   The GMAS-MAC sub-TLV is carried within the cost from the Spanning tree
      algorithm to the Root.

2.5.2.  Service Identifier GMAS TLV and Unicast Address MUST be
   carried in a standard Level 1 link state MGROUP PDU.

2.8.2.  The Group IP Active Source sub-TLV

   The SPB Service Identifier and Unicast Group IP Address TLV (GMAS-IP) sub-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 IS-IS TLV type 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and has
   the following format:

   +-+-+-+-+-+-+-+-+
   |                          B-MAC ADDRESS Type=GMAS-IP  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+
   |   B-MAC ADDRESS (cont)   Length      |  Res.                  (1 byte)
   +-+-+-+-+-+-+-+-+
   |         VID   Confidence  |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Topology-Id/ Nickname-Id    |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |G|S|R|R|      VLAN-ID          |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Num Group Recs |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |T|R| Reserved
   |                  ISID  #1                   GROUP RECORDS (1)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |T|R| Reserved
   |                  ISID  #2                   .................                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |T|R| Reserved
   |                  ISID  #n                   GROUP RECORDS (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

   where each group record is a unicast address of this node.  It may be either the single nodal address, or may address a port or any other level form:

   +-+-+-+-+-+-+-+-+
   |    RESERVED   |    (1 byte)
   +-+-+-+-+-+-+-+-+
   | Num of granularity relative to the node.  In the case where the node
      only has one B-MAC address this should be the same as 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 SYS-ID value field of the node.  To add multiple B-MACs this TLV must be repeated per
      additional B-MAC.
      TLV.

   o  ISID #1 .. #N are 24 bit service group membership identifiers.  If
      two nodes have  Confidence: This carries an ISID in common, intermediate nodes on 8-bit quantity indicating the unique
      shortest path between them will create forwarding state for
      confidence level in the
      related B-MAC IP addresses being transported.  Whether
      this field is used, and will also construct multicast
      forwarding state using its semantics if used, are further defined
      by the ISID 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 node's SPSOURCEID to
      construct a multicast DA as described technology in IEEE 802.1aq LSB.  Each
      ISID has a Transmit(T) and Receive(R) bit which indicates if it
      is used, this carries the
      membership 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  RESERVED: Must be sent as zero on transmission and is ignored on
      receipt.

   o  G: Delivery Group is set

   o  S: Delivery Source is set

   o  VLAN-ID: This carries a Transmitter/Receiver 12 bit VLAN identifier that is valid for
      all subsequent MAC addresses in this TLV, or both (with both bits
      set).  In the case where value zero if no
      VLAN is specified.

   o  Number of Group Records: This is of length 1 byte and lists the Transmit(T)
      number of group records in this TLV.

   o  Group Record: Each group record has a reserved space and Receive(R) bits are
      both zero, is
      followed by the ISID number of sources, each of length 1 byte.  It is ignored.  If more ISIDs are associated with
      followed by a particular B-MAC than can 32-bit IPv4 Group Address followed by 32-bit source
      IPv4 addresses.  If the number of sources do not fit in a single TLV, this TLV can be
      repeated with
      sub-TLV, it is permitted to have the same B-MAC but group address repeated
      with different ISID values.

2.6.  SPB Link Metric sub-tlv source addresses repeated in another sub-TLV of
      another instance of the Group Active Source TLV.

   The SPB Link Metric Sub GMAS-IP TLV occurs nested as is carried within the Extended
   Reachability TLV (type 22), or the Multi Topology Intermediate System
   TLV (type 222).  If this sub GMAS TLV is not present for an ISIS adjacency
   then that adjacency and 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 be carried in
   a standard Level 1 2 link state MGROUP PDU.

2.8.3.  The Group IPv6 Active Source sub-TLV

   The Group IPv6 Active Source (GMAS-IPv6) TLV is IS-IS sub-TLV type 3 4 5 6 7 8 9 0 1
   and has the following format:

   +-+-+-+-+-+-+-+-+
   |Type=GMAS-IPv6 |
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+
   |   Confidence  |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Topology-Id/ Nickname-Id    |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |G|S|R|R|      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)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved (must be 0)                   Group Address        (16 bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       SPB-LINK-METRIC                   Source 1 Address     (16 bytes)             | Num port ID
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Source 2 Address     (16 bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Port  Identifier                   Source M Address     (16 bytes)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: TLV sub-TLV Type, set to SPB Link Metric sub-TLV 5 [TBD]. 3 (GIPV6-ADDR).

   o  Length: Total number of bytes contained in the value field.

   o  SPB-LINK-METRIC indicates  Confidence: This carries an 8-bit quantity indicating the administrative cost or weight of
      using
      confidence level in the IPv6 addresses being transported.  Whether
      this link as a 24 bit unsigned number.  Smaller numbers
      indicate lower weights field is used, and its semantics if used, are more likely to carry SPB traffic.
      Only one metric is allowed per SPB instance per link. further defined
      by the specific protocol using Layer-2-IS-IS.  If multiple
      metrics are required multiple SPB instances are required, either
      within IS-IS or within several independent IS-IS instances. not used, it
      must be set to zero on transmission and be ignored on receipt.

   o  Num of Ports  Topology-Id/Nickname-Id: Depending on the technology in which it
      is used, this carries the number of ports associated with topology-id or nickname-id.  When this link.

   o  Port Identifier
      field is the standard IEEE port identifier used set to build
      a spanning tree associated with zero this link.

   SPB routes follow implies that the minimum sum MAC addresses are
      reachable across all topologies or across all nicknames of link metrics from the source to the destination.  If any SPB link metric
      originating IS.

   o  RESERVED: Must be sent as zero on transmission and is ignored on
      receipt.

   o  G: Delivery Group is set

   o  S: Delivery Source is set

   o  VLAN-ID: This carries a 12 bit VLAN identifier that is not the same as its
   reverse direction metric the metric valid for both directions of
      all subsequent MAC addresses in this TLV, or the above
   calculation value zero if no
      VLAN is considered to be the maximum specified.

   o  Number of the two differing
   metrics.  If an SPB metric TLV is missing from one or both directions Group Records: This of an adjacency no SPB traffic may flow between those nodes for length 1 byte and lists the
   corresponding SPB topology instance (MT-ID).  In
      number of group records in this TLV.

   o  Group Record: Each group record has a reserved space and is
      followed by the event number of two or
   more equal minimum sum sources, each of link metrics paths, the unique shortest
   path length 1 byte.  It is chosen according to
      followed by a 128-bit multicast IPv6 Group Address followed by
      128-bit source IPv6 addresses.  If the symmetric tie breaking algorithm Low-
   PATHID and/or High-PATHID as described number of sources do not
      fit in IEEE 802.1aq LSB.  When a single SPB instance sub-TLV, it is used this TLV occurs as a permitted to have the same group
      address repeated with different source addresses repeated in
      another sub-TLV in another instance of the Group Address TLV.

   The GMAS-IPv6 sub-TLV is carried within the GMAS TLV 22
   but when multiple instances are used it must and MUST be present as
   carried in 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 standard Level 1 link state MGROUP PDU.

2.9.  PDU Extensions to specify the SPB topology instance in question.

3. IS-IS

2.9.1.  The Multicast Group PDU

   The systems that this dcoument document is concerned with want to carry not
   only layer-2 unicast information in the link state protocols, but
   also multicast information.  This document section 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. rather than unicast
   reachability information.

   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,
   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.

2.9.1.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.

2.9.1.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.

2.9.1.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,
   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
   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.

2.9.1.4.  Enhancements to the maximum sequence number reached

   In the flooding of event, LSPs reach the MGROUP-PDU in tandem with maximum sequence number, ISO/IEC 10589
   states the MGROUP-
   PSNP rules for the process to shut down and MGROUP-CSNP PDUs uses its duration.  With
   the introduction of the MGROUP-PDU, the same update procedures as defined
   for process now applies when
   LSPs from either database reach the regular LSP, PSNP, and CSNP PDUs.

   For example, on P2P maximum sequence number.

2.9.2.  The TRILL-Hello PDU

   A different Hello PDU is required for TRILL links CSNP because it is exchanged on the formation of an
   adjacency.  In a similar fashion
   necessary that a MGROUP-CSNP MUST also single Designated RBridge (DIS) be exchanged
   between the neighbors at elected on each
   link based just on priority and MAC address regardless of two-way
   connectivity.  However, RBridge reachability is reported by RBridges
   in their LSP on the same time.  This gets basis as layer 3 Intermediate Systems report
   reachability, that is, if and only if two-way connectivity exists.

   The TRILL-Hello PDU has the initial
   MGROUP-database synchronization going.  After same general structure as an IS-IS LAN
   PDU.  An RBridge (an Intermediate System supporting TRILL) sends this similar actions of
   the base protocol specifications for
   PDU, with the regular database
   synchronization will be maintained to keep same timing as the MGROUP-database
   synchronized.

   Similarly, on IS-IS LAN links the DIS is responsible for sending periodic
   CSNP transmissions.  The DIS Hello PDU.  More
   specifically, in a TRILL-Hello PDU the L2 IS-IS network domain will also
   be responsible for sending periodic MGROUP-CSNP transmissions.  The
   update Common Header and flooding process will work the
   fixed PDU Header are the same as a Level 1 IS-IS LAN Hello except
   that a new PDU Type number is used as listed in parallel Section 7.  The
   circuit type field, of course, is always equal to one.  A TRILL-Hello
   PDU SHOULD not be padded and MUST NOT exceed a length limit equal to
   42 bytes shorter than the reasonable lower bound for the two
   databases and there is no further synchronization between them.

   In general, link MTU.
   For example, for an 802.3 Ethernet link, the database synchronization is performed in parallel
   with no interactions between MTU SHOULD be assumed to
   be 1512 bytes for the messages.  However, purpose of determining the initial
   triggers maximum size of
   TRILL-Hello PDUs on that start link.  Thus, for such a CSNP exchange are correlated, link, TRILL-Hellos
   MUST NOT exceed 1470 bytes.

   The following MUST appear in the sense it
   also triggers every TRILL-Hello PDU: a MGROUP-CSNP exchange.  For example, during graceful
   restart [RFC 5306], Port Capability
   TLV (see Section 2.3) containing a Special VLANs and Flags sub-TLV.

   Additional TLVs/sub-TLVs MAY appear in a TRILL-Hello including the normal hello operations as described
   TRILL Hello TLV specified in Section 2.7 and the
   RFC will be followed.  The enhancements will take place such that
   CSNP following sub-TLVs
   specified in Section 2.3: Enabled VLANs sub-TLV, Appointed Forwarders
   sub-TLV, and PSNP triggers will necessitate Hop-by-Hop Options sub-TLV.

   The Padding TLV (#8) SHOULD NOT appear in a parallel MGROUP-CSNP and
   MGROUP-PSNP exchange and update process will be triggered TRILL-Hello.

   The IS-IS Neighbor TLV (#6) MUST NOT appear in parallel
   for the MGROUP-PDUs.  After both databases containing a TRILL-Hello.
   Instead, it uses the regular
   PDUs TRILL Neighbor TLV (see Section 2.7).

2.9.3.  The MTU PDU

   The MTU-probe and MGROUP-PDUs have been obtained, the restart process is
   deemed complete.

3.4.  Enhancements MTU-ack PDUs are used to determine the maximum sequence number reached

   In the event, LSPs reach the maximum sequence number, ISO/IEC 10589
   states MTU on a
   link between intermediate systems.  An MTU-probe MUST be padded to
   the rules for size being tested with the process Padding TLV (#8).  The ability to shut down send
   an MTU-probe PDU is optional but an Intermediate System that supports
   TRILL MUST send an MTU-ack in response to an MTU-probe and its duration.  With that MTU-
   ack MUST be padded to the introduction size of the MGROUP-PDU, the same process now applies when
   LSPs from either database reach MTU-probe.

   The MTU PDUs have the maximum sequence number.

4.  Considerations for Using L2 Information standard IS-IS common header with two new PDU
   Type numbers, one each, as listed in Section 7.  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

   While this document does not specify PDUs, the way in which addresses
   carried in these TLVs are used in IS-IS, two general areas PDU length contains length of concern
   are considered in this section: building the SPF tree when using this
   information,
   entire IS-IS packet starting with and including the election of designated intermediate systems
   (DIS) in IS-IS common
   header.

   The Probe ID field is an environment using arbitrary 48-bit quantity set by the
   Intermediate System issuing an MTU-probe and copied by the responding
   system into the corresponding MTU-ack.  For example, an Intermediate
   System creating an MTU-probe could compose this information.

4.1.  Building SPF Trees with Layer 2 Information

   Each IS which is part of a single broadcast domain quantity from a layer 2
   perspective will build multiple SPF trees (SPT) for every IS port
   identifier and probe sequence number relative to that port.

   The Probe Source ID is
   announced set 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 an 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 system issuing an MTU-
   probe to flood its System ID and
   maintain synchronized databases over copied by the underlying media on which
   IS-IS responding system into the
   corresponding MTU-ack.

   The Ack Source ID is running set to zero in MTU-probe PDUs.  An Intermediate
   System issuing an MTU-ack set this field to its System ID.

   The TLV area follows the MTU PDU header area.  This area MAY contain
   an Authentication TLV and providing layer 2 forwarding information for.

5. MUST be padded to the size being tested
   with the Padding TLV.

3.  Acknowledgements

   The authors would like to thank Les Ginsberg and Mike Shand for his their
   useful comments.

6.

4.  Security Considerations

   This document adds no additional security risks to IS-IS, nor does it
   provide any additional security for IS-IS.

7.

5.  IANA Considerations

   This document creates three six new PDU types, namely the MCAST PDU,
   MCAST-CSNP MCAST-
   CSNP PDU, and the MCAST-PSNP PDU. PDU, TRILL-HELLO-PDU, MTU-PROBE-PDU, and
   MTU-ACK-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
      TRILL-HELLO-PDU  Level-1 PDU Type: 21
      MTU-PROBE-PDU    Level-1 PDU Type: 23
      MTU-ACK-PDU      Level-1 PDU Type: 28

   This document requires specifies the definition a set of new ISIS IS-IS TLVs, the
   MAC-Reachability TLV (type 141), the Group Address TLV (type 142),
   and
   the Link-Capability Port-Capability TLV (type 143), the MT-Capability TLV (type 144),
   and the Trill-Neighbor TLV (type 145), and Group Member Active Source
   TLV (type 146) that needs to be reflected in the ISIS IS-IS TLV code-point
   registry.

   This document creates a number of new sub-TLV sub-TLVs 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.

                                          IIH  LSP  SNP MCAST MCAST TRILL/
                                                         LSP   SNP  IEEE
   MAC-RI TLV  (141)                       -    X    -    -     -    T/I

   GADDR-TLV   (142)                       -    -    -    X     -    T/I    -/I
   GADDR-TLV.GMAC-ADDR      sub-tlv     sub-TLV  1      -    -    -    X     -    T/I
   GADDR-TLV.GMAC-IP        sub-tlv       sub-TLV  2      -    -    -    X     -    T/I
   GADDR-TLV.GMAC-IPV6      sub-tlv     sub-TLV  3      -    -    -    X     -    T/I
   GADDR-TLV.SPBV-MAC-ADDR sub-TLV  4      -    -    -    X     -    -/I

   MT-Port-Cap-TLV (143)                   X    -    -    -     -    T/-
   PortCap.VLAN and Flags   sub-tlv  sub-TLV   1     X    -    -    -     -    T/-
   PortCap.Enabled-VLANs    sub-tlv   sub-TLV   2     X    -    -    -     -    T/-
   PortCap.AppointedFwrdrs  sub-tlv sub-TLV   3     X    -    -    -     -    T/-
   PortCap.HopbyHopOptions  sub-tlv
   PortCap.HBHOPT          sub-TLV   4     X    -    -    -     -    T/-
   PortCap.BaseVLANID       sub-tlv      sub-TLV   5     X    -    -    -     -    -/I
   PortCap.SPBDigest       sub-TLV   6     X    -    -    -     -    -/I
   PortCap.SiteIdentifier  sub-TLV 250     X    -    -    -     -    -/-
   PortCap.SiteGroupIP     sub-TLV 251     X    -    -    -     -    -/-
   PortCap.SiteGroupIPv6   sub-TLV 252     X    -    -    -     -    -/-
   PortCap.AdjServerIP     sub-TLV 253     X    -    -    -     -    -/-
   PortCap.AdjServerIPv6   sub-TLV 254     X    -    -    -     -    -/-

   CAPABILITY.Trill-Version sub-tlv sub-TLV  5     -    X    -    -     -    T/-
   CAPABILITY.Nickname      sub-tlv      sub-TLV  6     -    X    -    X    -     -    T/-
   CAPABILITY.Tree          sub-tlv          sub-TLV  7     -    X    -    -     -    T/-
   CAPABILITY.Tree Roots Id sub-tlv sub-TLV  8     -    X    -    -     -    T/-
   CAPABILITY.TreeUseRootId sub-tlv sub-TLV  9     -    X    -    -     -    T/-
   CAPABILITY.Int-VLANs     sub-tlv     sub-TLV 10     -    X    -    X     -    T/-
   CAPABILITY.VLAN-Groups   sub-tlv   sub-TLV 11     -    X    -    -     -    T/-
   CAPABILITY.ITEOPT        sub-tlv        sub-TLV 12     -    X    -    -     -    T/-
   CAPABILITY.VMAP          sub-TLV 13     -    X    -    -     -    T/-

   MT-Capability-TLV (144)                 X                 -    X    -    -     -    -/I
   MT-Cap.SPB Instance      sub-tlv      sub-TLV  1     X     -    X    -    -     -    -/I
   MT-Cap.Service Id.       sub-tlv       sub-TLV  2     X     -    X    -    -     -    -/I

   TRILL-Nieghbor TLV (145)                X    -    -    -     -    T/-

   EXT-IS.SPB Link Metric   sub-tlv   sub-TLV  5     -    X    -    -     -    -/I
   EXT-IS.MTU               sub-TLV  6     -    X    -    -     -    -/I
   MT-EXT-IS.SPB LinkMetric sub-tlv sub-TLV  5     X     -    X    -    -     -    -/I

   Group Mem Active Source TLV (146)       -    -    -    X     -    -/-
   GMAS-TLV.GMAS-MAC      sub-TLV  1       -    -    -    X     -    -/-
   GMAS-TLV.GMAS-IP       sub-TLV  2       -    -    -    X     -    -/-
   GMAS-TLV.GMAS-IPV6     sub-TLV  3       -    -    -    X     -    -/-
   IANA SHOULD manage the remaining space using the consensus method.

8. IETF Review method
   [RFC 5226].

6.  Contributing Authors

      David Ward
      Cisco Systems
      170 W Tasman Drive
      San Jose, CA  95138
      US
      Juniper Networks
      1194 N. Mathilda Ave.
      Sunnyvale, California 94089-1206 USA
      Phone: +1-408-745-2000
      Email: wardd@cisco.com dward@juniper.net

      Russ White
      Cisco Systems
      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 Radia@alum.mit.edu

      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

      Email: Donald.Fedyk@alcatel-lucent.com

9.

7.  References

9.1.

7.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.

7.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.

Author's Address

   Ayan Banerjee (editor)
   Cisco Systems
   170 W Tasman Drive
   San Jose, CA  95138
   US

   Email: ayabaner@cisco.com