[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 RFC 6165

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


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

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 12, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document specifies the IS-IS extensions necessary to support
   multi-link IPv4 and IPv6 networks, as well as to provide true link
   state routing to any protocols running directly over layer 2.  While



Banerjee, et al.        Expires January 12, 2010                [Page 1]

Internet-Draft                Layer-2-IS-IS                    July 2009


   supporting this concept involves several pieces, this document only
   describes extensions to IS-IS.  We leave it to the systems using
   these IS-IS extensions to explain how the information carried in
   IS-IS is used.















































Banerjee, et al.        Expires January 12, 2010                [Page 2]

Internet-Draft                Layer-2-IS-IS                    July 2009


Table of Contents

   1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  TLV and sub-TLV Enhancements to IS-IS  . . . . . . . . . . . .  4
     2.1.  The MAC-Reachability TLV . . . . . . . . . . . . . . . . .  5
     2.2.  The Group Address TLV  . . . . . . . . . . . . . . . . . .  6
       2.2.1.  The Group MAC Address sub-TLV  . . . . . . . . . . . .  6
       2.2.2.  The Group IP Address sub-TLV . . . . . . . . . . . . .  8
       2.2.3.  The Group IPv6 Address sub-TLV . . . . . . . . . . . . 10
     2.3.  Multi Topology aware Port Capability TLV . . . . . . . . . 12
       2.3.1.  The Special VLANs and Flags sub-TLV  . . . . . . . . . 13
       2.3.2.  Enabled VLANs sub-TLV  . . . . . . . . . . . . . . . . 14
       2.3.3.  Appointed Forwarders sub-TLV . . . . . . . . . . . . . 14
       2.3.4.  Hop-by-Hop Options (HBHOPT) sub-TLV  . . . . . . . . . 15
       2.3.5.  Base VLAN-Identifiers sub-TLV  . . . . . . . . . . . . 16
     2.4.  Sub-TLVs for the Router Capability TLV . . . . . . . . . . 18
       2.4.1.  The TRILL Version sub-TLV  . . . . . . . . . . . . . . 18
       2.4.2.  The Nickname sub-TLV . . . . . . . . . . . . . . . . . 18
       2.4.3.  The Trees sub-TLV  . . . . . . . . . . . . . . . . . . 19
       2.4.4.  The Tree Roots Identifier Sub-TLV  . . . . . . . . . . 20
       2.4.5.  The Tree Used Identifier Sub-TLV . . . . . . . . . . . 21
       2.4.6.  Interested VLANs and Spanning Tree Roots sub-TLV . . . 22
       2.4.7.  The VLAN Group sub-TLV . . . . . . . . . . . . . . . . 23
       2.4.8.  The Ingress-to-Egress Options (ITEOPT) sub-tlv . . . . 24
     2.5.  Multi Topology Aware Capability TLV  . . . . . . . . . . . 25
       2.5.1.  SPB Instance sub-TLV . . . . . . . . . . . . . . . . . 26
       2.5.2.  Service Identifier and Unicast Address sub-TLV . . . . 29
     2.6.  SPB Link Metric sub-tlv  . . . . . . . . . . . . . . . . . 30
   3.  The Multicast Group PDU  . . . . . . . . . . . . . . . . . . . 31
     3.1.  The Multicast Group Partial Sequence Number PDU  . . . . . 32
     3.2.  The Multicast Group Complete Sequence Number PDU . . . . . 32
     3.3.  Enhancements to the flooding process . . . . . . . . . . . 32
     3.4.  Enhancements to the maximum sequence number reached  . . . 33
   4.  Considerations for Using L2 Information in IS-IS . . . . . . . 33
     4.1.  Building SPF Trees with Layer 2 Information  . . . . . . . 33
     4.2.  Designated Intermediate Routers  . . . . . . . . . . . . . 33
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 34
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 34
   8.  Contributing Authors . . . . . . . . . . . . . . . . . . . . . 35
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 37
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 37
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37






Banerjee, et al.        Expires January 12, 2010                [Page 3]

Internet-Draft                Layer-2-IS-IS                    July 2009


1.  Overview

   There are a number of systems (for example, [RBRIDGES], [802.1aq])
   that use layer 2 addresses carried in a link state routing protocol,
   specifically IS-IS [IS-IS] [RFC1195], to provide true layer 2 routing
   in specific environments.  This document specifies a set of TLVs and
   sub-TLVs to be added to [IS-IS] level 1 PDUs, and three new PDU
   types, to support these proposed systems.  Some of these TLVs are
   generic layer 2 additions and some are specific to [RBRIDGES] or to
   [802.1aq].  This draft does not propose any new forwarding mechanisms
   using this additional information carried within IS-IS.

   This document specifies additional TLVs and sub-TLVs, to carry
   unicast and multicast attached address information.  It also proposes
   additional TLVs and sub-TLVs to carry information as required by the
   IETF RBridge and IEEE 802.1aq protocols.

   This document specifies three new IS-IS PDUs, the Multicast Group
   (MGROUP) PDU, for carrying a list of attached or joined multicast
   groups.  The Multicast Group Complete Sequence Number (MGROUP-CSNP)
   PDU and the Multicast Group Partial Sequence Number (MGROUP-PSNP) PDU
   packets are also defined to be used with the new MGROUP-PDU to
   perform database exchange on the MGROUP PDU packets.

1.1.  Terminology

   The term "Hello" or "Hello PDU" in this document, when not further
   qualified, includes both LAN IIH PDU and P2P IIH PDU.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.


2.  TLV and sub-TLV Enhancements to IS-IS

   In this section we describe the enhancements that are being proposed
   for the TLV and sub-TLVs as needed by Layer-2 technologies.

   In particular, Sections 2.1 specifies the MAC-Reachability TLV;
   Section 2.2 specifies the Group Address TLV and its sub-TLVs; Section
   2.3 specifies the Port Capabilities TLV.  These are expected to be of
   generic use in current and future Layer-2 uses of IS-IS.  We propose
   enhancements to the Capability TLV in Section 2.4 and in Section 2.5
   we propose a Multi Topology aware Capability TLV with its sub-TLVs.






Banerjee, et al.        Expires January 12, 2010                [Page 4]

Internet-Draft                Layer-2-IS-IS                    July 2009


2.1.  The MAC-Reachability TLV

   The MAC-Reachability (MAC-RI) TLV is IS-IS TLV type 141 and has the
   following format:

   +-+-+-+-+-+-+-+-+
   | Type= MAC-RI  |                  (1 byte)
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+
   |   Confidence  |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Topology-Id/ Nickname-Id    |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  RESV |      VLAN-ID          |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MAC (1)    (6 bytes)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   .................                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MAC (N)    (6 bytes)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: TLV Type, set to 141 (MAC-RI).

   o  Length: Total number of bytes contained in the value field given
      by 5 + 6*n bytes.

   o  Confidence: This carries an 8-bit quantity indicating the
      confidence level in the MAC addresses being transported.  Whether
      this field is used, and its semantics if used, are further defined
      by the specific protocol using Layer-2-IS-IS.  If not used, it
      must be set to zero on transmission and be ignored on receipt.

   o  Topology-Id/Nickname-Id: Depending on the technology in which it
      is used, this carries the topology-id or nickname-id.  When this
      field is set to zero this implies that the MAC addresses are
      reachable across all topologies or across all nicknames of the
      originating IS.

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

   o  VLAN-ID: This carries a 12 bit VLAN identifier that is valid for
      all subsequent MAC addresses in this TLV, or the value zero if no
      VLAN is specified.





Banerjee, et al.        Expires January 12, 2010                [Page 5]

Internet-Draft                Layer-2-IS-IS                    July 2009


   o  MAC(i): This is the 48-bit MAC address reachable from the IS that
      is announcing this TLV.

   The MAC-RI TLV is carried in a standard Level 1 link state PDU.  It
   MUST contain only unicast addresses.

2.2.  The Group Address TLV

   The Group Address (GADDR) TLV is IS-IS TLV type 142 [TBD] and has the
   following format:
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Type = GADDRTLV| Length        |              sub-TLVs         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: TLV Type, set to GADDR-TLV 142 [TBD].

   o  Length: Total number of bytes contained in the value field, which
      includes the length of the sub-tlvs carried in this TLV.

   o  sub-TLVs: The Group Address TLV value contains sub-TLVs formatted
      as described in [RFC5305].  The sub-TLVs for this TLV are
      specified in the following subsections.

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

2.2.1.  The Group MAC Address sub-TLV

   The Group MAC Address (GMAC-ADDR) sub-TLV is IS-IS sub-TLV type 1
   within the GADDR TLV and has the following format:



















Banerjee, et al.        Expires January 12, 2010                [Page 6]

Internet-Draft                Layer-2-IS-IS                    July 2009


   +-+-+-+-+-+-+-+-+
   | Type=GMAC-ADDR|                  (1 byte)
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+
   |   Confidence  |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Topology-Id/ Nickname-Id    |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  RESV |      VLAN-ID          |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Num Group Recs |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   GROUP RECORDS (1)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   .................                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   GROUP RECORDS (N)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where each group record is of the form:


   +-+-+-+-+-+-+-+-+
   |    RESERVED   |    (1 byte)
   +-+-+-+-+-+-+-+-+
   | Num of Sources|    (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Group Address         (6 bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Source 1 Address      (6 bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Source 2 Address      (6 bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Source M Address      (6 bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: sub-TLV Type, set to 1 (GMAC-ADDR) of length 1 byte.

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

   o  Confidence: This carries an 8-bit quantity indicating the
      confidence level in the MAC addresses being transported.  Whether
      this field is used, and its semantics if used, are further defined
      by the specific protocol using Layer-2-IS-IS.  If not used, it
      must be set to zero on transmission and be ignored on receipt.





Banerjee, et al.        Expires January 12, 2010                [Page 7]

Internet-Draft                Layer-2-IS-IS                    July 2009


   o  Topology-Id/Nickname-Id: Depending on the technology in which it
      is used, this carries the topology-id or nickname-id.  When this
      field is set to zero this implies that the MAC addresses are
      reachable across all topologies or across all nicknames of the
      originating IS.

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

   o  VLAN-ID: This carries a 12 bit VLAN identifier that is valid for
      all subsequent MAC addresses in this TLV, or the value zero if no
      VLAN is specified.

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

   o  Group Record: Each group record has a reserved space and followed
      by the number of sources, each of length 1 byte.  It then has a
      48-bit multicast Group Address followed by 48-bit source MAC
      addresses.  An address being a group multicast address or unicast
      source address can be checked using the multicast bit in the
      address.  If the number of sources do not fit in a single sub-tlv,
      it is permitted to have the same group address repeated with
      different source addresses repeated in different sub-tlvs.

   The GMAC-ADDR sub-TLV is carried within the GADDR TLV and MUST be
   carried in a standard Level 1 link state MGROUP PDU.

2.2.2.  The Group IP Address sub-TLV

   The Group IP Address (GIP-ADDR) sub-TLV is IS-IS TLV type 2 and has
   the following format:



















Banerjee, et al.        Expires January 12, 2010                [Page 8]

Internet-Draft                Layer-2-IS-IS                    July 2009


   +-+-+-+-+-+-+-+-+
   | Type=GIP-ADDR |
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+
   |   Confidence  |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Topology-Id/ Nickname-Id    |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  RESV |      VLAN-ID          |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Num Group Recs |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   GROUP RECORDS (1)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   .................                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   GROUP RECORDS (N)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where each group record is of the form:

   +-+-+-+-+-+-+-+-+
   |    RESERVED   |    (1 byte)
   +-+-+-+-+-+-+-+-+
   | Num of Sources|    (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Group Address         (4 bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Source 1 Address      (4 bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Source 2 Address      (4 bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Source M Address      (4 bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: sub-TLV Type, set to 2 (GIP-ADDR).

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

   o  Confidence: This carries an 8-bit quantity indicating the
      confidence level in the IP addresses being transported.  Whether
      this field is used, and its semantics if used, are further defined
      by the specific protocol using Layer-2-IS-IS.  If not used, it
      must be set to zero on transmission and be ignored on receipt.





Banerjee, et al.        Expires January 12, 2010                [Page 9]

Internet-Draft                Layer-2-IS-IS                    July 2009


   o  Topology-Id/Nickname-Id: Depending on the technology in which it
      is used, this carries the topology-id or nickname-id.  When this
      field is set to zero this implies that the MAC addresses are
      reachable across all topologies or across all nicknames of the
      originating IS.

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

   o  VLAN-ID: This carries a 12 bit VLAN identifier that is valid for
      all subsequent MAC addresses in this TLV, or the value zero if no
      VLAN is specified.

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

   o  Group Record: Each group record has a reserved space and followed
      by the number of sources, each of length 1 byte.  It is followed
      by a 32-bit IPv4 Group Address followed by 32-bit source IPv4
      addresses.  If the number of sources do not fit in a single sub-
      tlv, it is permitted to have the same group address repeated with
      different source addresses repeated in different sub-tlvs.

   The GIP-ADDR TLV is carried within the GADDR TLV and MUST be carried
   in a standard Level 1 link state MGROUP PDU.

2.2.3.  The Group IPv6 Address sub-TLV

   The Group IPv6 Address (GIPV6-ADDR) TLV is IS-IS sub-TLV type 3 and
   has the following format:





















Banerjee, et al.        Expires January 12, 2010               [Page 10]

Internet-Draft                Layer-2-IS-IS                    July 2009


   +-+-+-+-+-+-+-+-+
   |Type=GIPv6-ADDR|
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+
   |   Confidence  |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Topology-Id/ Nickname-Id    |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  RESV |      VLAN-ID          |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Num Group Recs |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   GROUP RECORDS (1)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   .................                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   GROUP RECORDS (N)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where each group record is of the form:

   +-+-+-+-+-+-+-+-+
   |    RESERVED   |    (1 byte)
   +-+-+-+-+-+-+-+-+
   | Num of Sources|    (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Group Address        (16 bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Source 1 Address     (16 bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Source 2 Address     (16 bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Source M Address     (16 bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: sub-TLV Type, set to 3 (GIPV6-ADDR).

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

   o  Confidence: This carries an 8-bit quantity indicating the
      confidence level in the IPv6 addresses being transported.  Whether
      this field is used, and its semantics if used, are further defined
      by the specific protocol using Layer-2-IS-IS.  If not used, it
      must be set to zero on transmission and be ignored on receipt.

   o  Topology-Id/Nickname-Id: Depending on the technology in which it
      is used, this carries the topology-id or nickname-id.  When this



Banerjee, et al.        Expires January 12, 2010               [Page 11]

Internet-Draft                Layer-2-IS-IS                    July 2009


      field is set to zero this implies that the MAC addresses are
      reachable across all topologies or across all nicknames of the
      originating IS.

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

   o  VLAN-ID: This carries a 12 bit VLAN identifier that is valid for
      all subsequent MAC addresses in this TLV, or the value zero if no
      VLAN is specified.

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

   o  Group Record: Each group record has a reserved space and followed
      by the number of sources, each of length 1 byte.  It is followed
      by a 128-bit multicast IPv6 Group Address followed by 128-bit
      source IPv6 addresses.  If the number of sources do not fit in a
      single sub-tlv, it is permitted to have the same group address
      repeated with different source addresses repeated in different
      sub-tlvs.

   The GIPV6-ADDR sub-TLV is carried within the GADDR TLV and MUST be
   carried in a standard Level 1 link state MGROUP PDU.

2.3.  Multi Topology aware Port Capability TLV

   The Multi Topology aware Port Capability (MT-PORT-CAP) is an IS-IS
   TLV type 143 [TBD], and has the following format:
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Type=MT PORTCAP| Length        |O|R|R|R|  Topology Identifier  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            sub-TLVs                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: TLV Type, set to MT-PORT-CAP TLV 143 [TBD].

   o  Length: Total number of bytes contained in the value field,
      including the length of the sub-TLVs carried in this TLV.

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

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



Banerjee, et al.        Expires January 12, 2010               [Page 12]

Internet-Draft                Layer-2-IS-IS                    July 2009


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

   o  sub-TLVs: The MT aware Port Capabilities TLV value contains sub-
      TLVs formatted as described in [RFC5305].  They are defined in the
      next sections.

   The MT aware PORT-CAP-TLV MUST be carried only within a LAN IIH PDU,
   or a P2P IIH PDU.  It may occur multiple times in a Hello PDU.

2.3.1.  The Special VLANs and Flags sub-TLV

   The Special VLANs and Flags (VLAN and Flags) sub-TLV MUST appear
   exactly once in a MT aware Port Capability TLV in every LAN IIH PDU.
   It has the following format:
     0    1    2    3     4 - 15      16 - 19     20 - 31
   +----+----+----+----+------------+----------+------------+
   | AF | AC | VM | BY | Outer.VLAN | Reserved | Desig.VLAN |
   +----+----+----+----+------------+----------+------------+

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

   o  Length: 4 - Number of bytes contained in the value field.

   o  The first and second bytes have a copy of the Outer VLAN ID
      associated with the Hello frame when it was sent.  The lower 4
      bits of the first byte give the upper ID bits of the VLAN ID and
      the second byte gives the lower VLAN ID bits.

   o  The upper 4 bits of the first byte are flag bits as shown.  The AF
      bit, if one, indicates that the sending Intermediate System
      believes it is Appointed Forwarder for the VLAN and port on which
      the Hellos was sent.  The AC bit, if one, indicates that the
      sending port is configured as an access port.  The VM bit, if a
      one, indicates that the sending Intermediate System has detected
      VLAN mapping within the link.  The BY bit, if set, indicates
      bypass psuedonode.

   o  The third and forth bytes give the Designated VLAN for the link.
      The lower 4 bits of the third byte give the upper ID bits of the
      Designated VLAN and the forth byte gives the lower VLAN ID bits.
      The upper 4 bits of the third byte are reserved and MUST be sent
      as zero and ignored on receipt.

   The VLAN and Flags sub-TLV is carried within the MT aware PORT-CAP
   TLV and MUST be carried in LAN IIH PDU.  It MUST NOT be carried
   within a P2P IIH PDU.




Banerjee, et al.        Expires January 12, 2010               [Page 13]

Internet-Draft                Layer-2-IS-IS                    July 2009


2.3.2.  Enabled VLANs sub-TLV

   The Enabled VLAN sub-TLV specifies the VLANs enabled for end station
   service at the port on which the Hello was sent.

   o  Type: sub-TLV Type, set to Enabled VLANs sub-TLV 2 [TBD].

   o  Length: variable, depending on contents described next.

   o  The minimum size of the value is 3 bytes.  The third and
      subsequent bytes provide a bit map of enabled VLANs starting at
      the VLAN ID indicated in the first two bytes.  The lower order
      four bits of the first byte give the upper bits of the starting
      VLAN ID and the second byte gives the lower bits of that VLAN ID.
      The upper four bits of the first byte are reserved and MUST be
      sent as zero and ignored on receipt.  The highest order bit of the
      third byte indicates the VLAN equal to the starting ID while the
      lowest order bit of the third byte indicated that ID plus 7.  For
      example, VLANs 1 and 14 being enabled for end station service
      could be encoded in 4-bytes value 0x00 0x01 0x80 0x04 or,
      alternatively, as 0x00 0x00 0x40 0x02.

   This sub-TLV may occur more than once in a Hello and a VLAN is
   enabled for end station service on the port where the Hellos was sent
   if this is indicated by any occurrence in the Hello.  For example, a
   receiver could allocate a 512-byte buffer and, with appropriate
   shifting operations, OR in the enabled bits for each subTLV of this
   type it finds in a Hello to derive the complete bit map of these
   VLANs.

   The Enabled VLAN sub-TLV is carried within the MT aware PORT-CAP TLV
   and MUST be carried in LAN IIH PDU.  It MUST NOT be carried within a
   P2P IIH PDU.

2.3.3.  Appointed Forwarders sub-TLV

   The Appointed Forwarder sub-TLV provides the mechanism by which the
   Designated Intermediate System can inform other Intermediate Systems
   on the link that they are the designated VLAN-x forwarder for that
   link for one or more ranges of VLAN IDs.

   o  Type: sub-TLV Type, set to Enabled VLANs sub-TLV 3 [TBD].

   o  Length: The size of the value is 6*n bytes where there are n
      appointments.  Each 6-byte part of the value is formatted as
      follows:





Banerjee, et al.        Expires January 12, 2010               [Page 14]

Internet-Draft                Layer-2-IS-IS                    July 2009


   +----------------+-----+-----+---------+-----+----+---------+
   |   byte 1 - 2   |  byte 3   |  byte 4 |   byte 5 |  byte 6 |
   +----------------+-----+-----+---------+-----+----+---------+
   | Appointee Nick | Res | Start VLAN ID | Res | End VLAN ID  |
   +----------------+-----+-----+---------+-----+----+---------+

   o  The appointed forwarder Intermediate System is specified by its
      nickname in the first two bytes.

   o  The "Res" fields of 4 bits each are reserved and MUST be sent as
      zero and ignored on receipt.

   The VLAN range given is inclusive.  To specify a single VLAN, that
   VLAN ID appears as both the start and end VLAN.  The Intermediate
   System whose nickname is given is appointed forwarder for those VLANs
   for which it has end station service enabled (see item 2 above) in
   the inclusive range.  For example, assume an Intermediate System with
   end station service enabled on VLANs 100, 101, 199, and 200 (and
   possibly other VLANs less than 100 or greater than 200), but not
   enabled for VLANs 102 through 198.  It could be appointed forwarder
   for these four VLANs through either (1) a single 6-byte value
   sequence with start and end VLAN IDs of 100 and 200, or (2) a 12-byte
   value sequence with start and end VLAN IDs of 100 and 101 in the
   first part and 199 and 200 in the second part.

   An Intermediate System's nickname may occur as appointed forwarder
   for multiple VLAN ranges within the same or different Port Capability
   TLVs within a Designated Intermediate Systems's Hello.  In the
   absence of appointed forwarder sub-TLVs referring to a VLAN, the
   Designated Intermediate System acts as the appointed forwarder for
   that VLAN if end station service is enabled.

   The Appointed Forwarder sub-TLV is carried within the MT aware PORT-
   CAP TLV and MUST be carried in a LAN IIH PDU.  This MUST NOT be
   carried in a P2P IIH PDU.

2.3.4.  Hop-by-Hop Options (HBHOPT) sub-TLV

   By including this sub-TLV within one or more MT aware Port Capability
   TLVs in its Hellos, an Intermediate System can advertise the Hop-by-
   Hop options it supports on the port through which it sends the Hello.
   This sub-TLV may appear zero or more times within a MT aware Port
   Capability TLV.  By default, in the absence of any HBHOPT sub-TLVs,
   no Hop-by-Hop options are supported.

   There are two types of Hop-by-Hop option encoding within the TRILL
   Header: bit options and TLV encoded options.




Banerjee, et al.        Expires January 12, 2010               [Page 15]

Internet-Draft                Layer-2-IS-IS                    July 2009


   The bit-encoded options supported are indicated by an HBHOPT sub-TLV
   of length 3: an initial value byte of 0xFF followed by four bytes in
   which each bit indicates that the corresponding bit option is
   implemented; in those four bytes the top two bits (0xC0000000) are
   critical option summary bits that all RBridges MUST understand.
   Those two bits are reserved in the HBHOPT sub-TLV and must be sent as
   zero are ignored on receipt.

   The implementation of a TLV encoded option is indicated by an HBHOPT
   sub-TLV whose value starts with a byte equal to the first byte of the
   option.  Such HBHOPT sub-TLVs may have additional value bytes further
   indicating how the option is supported as specified with the option's
   definition, for example a list of supported security algorithms.

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

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

   o  Length: variable, minimum 1.

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

2.3.5.  Base VLAN-Identifiers sub-TLV

   This sub-TLV is added to an IIH PDU to indicate the algorithms for
   the VIDs and the Base VIDs and VIDs or Backbone-VIDs (B-VIDs) are in
   use.  This information should be the same on all bridges in the
   topology identified by MT-PORT-CAP TLV it is being carried.
   Discrepancies between neighbours with respect to this sub-TLV are
   temporarily allowed but the Base-VID must agree and use a spanning
   tree algorithm.











Banerjee, et al.        Expires January 12, 2010               [Page 16]

Internet-Draft                Layer-2-IS-IS                    July 2009


   +-+-+-+-+-+-+-+-+
   |Type = B-VID   |
   +-+-+-+-+-+-+-+-+
   |   Length      |    (1 byte)
   +-+-+-+-+-+-+-+-+
   |M|B|  RESERVED |    (1 byte)
   +-+-+-+-+-+-+-+-+--------------------------------
   |      VID Tuple (1)  (4 bytes)                 |
   +-----------------------------------------------+
   |      .........................                |
   +-----------------------------------------------+
   |      VID Tuples (N)  (4 bytes)                |
   +-----------------------------------------------+

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

   o  Length: The size of the value is VID Tuples*4 + 1 bytes.  Each
      4-byte part of the N-VID tuple is formatted as follows:

       0  1 - 3   4 - 15   16 - 19       20 - 31
      +-+----------+-------+-----------+------------+
      |A| Reserved |   VID | Algorithm |    B-VID   |
      +-+----------+-------+-----------+------------+

   o  The M bit when set indicates that the Mode is Shortest Path VIDs
      one VID per tree.  When clear this bit indicates that this is
      using single VIDs.  Neighboring bridges must have matching
      configuration or the adjacency is rejected.

   o  The B Bit when set indicates this is Backbone Bridging
      alternatively when clear this bit indicates this is Shortest path
      bridging.

   o  Combinations of the M and B bits are specified in the [IEEE
      802.1aq].

   o  Algorithm: Specifies the tie breaking algorithm to be used for
      this VID.  Currently only the following values are supported:

      *  ALG = 0 a spanning tree.

      *  ALG = 1 the Low PATHID algorithm is used for this VID.

      *  ALG = 2 the High PATHID algorithm is used.

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





Banerjee, et al.        Expires January 12, 2010               [Page 17]

Internet-Draft                Layer-2-IS-IS                    July 2009


   o  VID is the VID for which the given algorithm applies, see [IEEE
      802.1aq].

   o  B-VID is the B-VID for which the given algorithm applies, see
      [IEEE 802.1aq].

   o  The "Reserved" fields MUST be sent as zero and ignored on receipt.

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

2.4.  Sub-TLVs for the Router Capability TLV

   The Router Capability TLV is an optional TLV [RFC 4971] that may be
   generated by the originating Intermediate System.  We specify these
   additional sub-TLVs that can be carried in it.  These sub-TLVs
   announce the capabilities of the Intermediate System for the entire
   IS-IS routing domain.

2.4.1.  The TRILL Version sub-TLV

   The TRILL Version (TRILL-VER) sub-TLV indicates support of TRILL
   Versions.  The device announces the maximum version of TRILL, it is
   capable of supporting, including lower versions.  In the event, this
   sub-TLV is missing, this implies that the node can only support the
   base version of the protocol.
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type          | Length        |    Reserved   |   Max-version |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: sub-TLV Type, set to 5 (TRILL-VER).

   o  Length: 2 - Total number of bytes contained in the TLV.

   o  Reserved: Set to zero on transmission and ignored on receipt.

   o  Max-version: Set to application dependent values.

2.4.2.  The Nickname sub-TLV

   The Nickname (NICK) sub-TLV carries information about the nicknames
   of the advertising device, along with information about its priority
   to hold those nicknames.  The Nickname sub-TLV MUST be carried within
   the Router CAPABILITY TLV in a level-1 non-pseudo-node LSP generated
   by the originating IS.




Banerjee, et al.        Expires January 12, 2010               [Page 18]

Internet-Draft                Layer-2-IS-IS                    July 2009


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

   where each nickname record is of the form:

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

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

   o  Length: Total number of bytes contained in the TLV.

   o  Priority: Set to application dependent values.

   o  Nickname: This is an unsigned 16-bit integer that gives device
      identifier or alias.

   Each nickname record consists of a one-byte priority set to
   application dependent values, and two bytes of device identifier or
   alias (i.e., actual nickname).

2.4.3.  The Trees sub-TLV

   The Trees sub-TLV MUST occur only once and can be carried within the
   Router CAPABILITY TLV in a level-1 non-pseudo-node LSP generated by
   the originating IS.  Each device announces four numbers: its own
   priority to be a multi-destination frame distribution tree root; the
   number of trees it dictates that all other Intermediate Systems in
   the campus compute if it is the highest priority tree root; the
   maximum number of trees it is able to compute; and the number of
   distribution trees it wishes to be able to use in forwarding multi-
   destination traffic.

   Once a node receives a new LSP, it runs an election algorithm,
   independently of the other nodes in the network, to determine if it
   is the highest priority root.  The node that announced the



Banerjee, et al.        Expires January 12, 2010               [Page 19]

Internet-Draft                Layer-2-IS-IS                    July 2009


   numerically highest priority to become a tree root is elected the to
   be the highest priority tree root.  If two devices advertise the same
   priority, the device with the higher system ID has the higher
   priority to be a tree root.  The elected highest priority tree root
   dictates the number of distribution tree roots to be used in the
   network domain and can list those roots in the tree roots identifier
   sub-TLV.

   +-+-+-+-+-+-+-+-+
   |Type =  TREE   |
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Tree Root Priority        |  (2 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Number of trees to compute   |  (2 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Maximum trees able to compute |  (2 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Number of trees to use     |  (2 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: sub-TLV Type, set to 7 (TREE).

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

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

   o  Number of trees to compute: This is an unsigned 16-bit integer
      that gives the requested number of distribution trees for multi-
      destination frames that will be in use in the Layer-2 domain, if
      this device becomes the highest priority tree root in the domain.

   o  Maximum number of tree able to compute: This is an unsigned 16-bit
      integer that give the maximum number of threes that the
      originating IS is able to compute for the campus.

   o  Number of trees to use: This is an unsigned 16-bit integer that
      gives the number of distribution trees the originating IS wishes
      to be able to use.

2.4.4.  The Tree Roots Identifier Sub-TLV

   The tree root identifier sub-TLV is is an ordered list of nicknames.
   When originated by the Intermediate System which is the highest
   priority tree root, this list is the tree roots for which other



Banerjee, et al.        Expires January 12, 2010               [Page 20]

Internet-Draft                Layer-2-IS-IS                    July 2009


   Intermediate Systems are required to compute trees.  If this
   information is spread across multiple sub-tlvs, the starting tree
   root identifier is used to figure out the ordered list.  It is
   carried within the CAPABILITY TLV in a level-1 non-pseudo-node LSP
   and is given as:

   +-+-+-+-+-+-+-+-+
   |Type=TREE-RT-ID|
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Starting Tree Root Identifier|    (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Nickname (K-th root)      |    (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Nickname (K+1 - th root)  |    (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Nickname (...)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

   o  Starting Tree Root Identifier: This identifies the starting tree
      root identifier of the nicknames which are roots for the domain.
      This is set to 1 for the first sub-TLV.  The starting value and
      the length field gives the number of nicknames being carried in
      the sub-TLV.  In the event a tree identifier can be computed from
      two such sub-TLVs and are different, then it is assumed that this
      is a transient condition which will get cleared.

   o  Nickname: The nickname associated with a Intermediate System id on
      which this tree is based.

   A locally significant hash may be used by edge devices to determine
   which multicast root (or set of multicast roots) is used to send
   traffic for a specific multicast group.  If there is a discrepancy
   between the number of multi-destination trees the broadcast-root has
   announced, and the number of roots the root-identifier sub-tlv
   carries, nodes MUST compute trees for the additional roots.

2.4.5.  The Tree Used Identifier Sub-TLV

   This sub-TLV has the same structure as the Tree Roots Identifier Sub-
   TLV specified in the above section.  The only difference is that its
   sub-TLV type is set to 9 TBD (TREE-USE-IDs) and the roots listed are
   only those that the originating intermediate systems wishes to use.



Banerjee, et al.        Expires January 12, 2010               [Page 21]

Internet-Draft                Layer-2-IS-IS                    July 2009


2.4.6.  Interested VLANs and Spanning Tree Roots sub-TLV

   The value of this sub-TLV consists of a VLAN range, flags, and a
   variable length list of spanning tree root bridge IDs.  This sub-TLV
   may appear zero, one, or many times.  The union of the VLAN ranges in
   all occurrences MUST be precisely the set of VLANs for which the
   originating Intermediate System is appointed forwarder on at least
   one port and the VLAN ranges in multiple VLANs sub-TLVs for an
   Intermediate System MUST NOT overlap.  That is, the intersection of
   the VLAN ranges for any pair of these sub-TLVs originated by an
   Intermediate System must be null.  The value length is 4 + 6*n where
   n is the number of root bridge IDs.  The initial 4 bytes of value are
   as follows:

   +-+-+-+-+-+-+-+-+
   |Type = INT-VLAN|
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +---------------+-----+
   |   Nickname-Id       |            (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Interested VLANS           |  (8 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Root Bridges          |  (6*n bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: sub-TLV Type, set to 10 (INT-VLAN).

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

   o  Nickname Id: If this is set to 0, then it applies to all device-
      ids generated by the node.  It may alternatively be set to a
      specific nickname-id, in the event a node wants to segregate
      traffic using multiple device-ids.

   o  Interested VLANS: In the Interested VLANs, as shown below, the M4
      bit indicates that there is an IPv4 multicast router on a link for
      which the originating Intermediate System is appointed forwarder
      for every VLAN in the indicated range.  The M6 bit indicates the
      same for an IPv6 multicast router.  The R and Reserved bits MUST
      be sent as zero and are ignored on receipt.  The VLAN start and
      end IDs are inclusive.  A range of one VLAN ID is indicated by
      setting them both to that VLAN ID value.  It has the following
      format:







Banerjee, et al.        Expires January 12, 2010               [Page 22]

Internet-Draft                Layer-2-IS-IS                    July 2009


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

   o  Root Bridges: The list of zero or more spanning tree root bridge
      IDs is the set of root bridge IDs seen for all ports for which the
      Intermediate System is appointed forwarder for the VLANs in the
      range.  This information is learned from BPDUs heard by the
      Intermediate System.  If MSTP is in use on a link, the root bridge
      referred to is the CIST (common and internal spanning tree) root
      bridge.  (While, of course, only one spanning tree root should be
      seen on any particular port, there may be multiple ports in the
      same VLAN connected to differed bridged LANs with different
      spanning tree roots.)  If no spanning tree roots can be seen on
      any of the links in any of the VLANs in the range indicated for
      which the Intermediate System is appointed forwarder (for example
      all such links are point-to-point links to other Intermediate
      Systems or to end stations so no BPDUs are received) then the
      listed set of spanning tree root IDs will be null.

   If there are any two VLANs in the range indicated for which the value
   of the M4, or M6 bits are different, the sub-TLV is incorrect and
   must be split into multiple sub-TLVs each indicating only VLANs with
   the same M4, and M6 values.  If there are any two VLANs in the range
   indicated for which the set of root bridge IDs see on all links for
   which the Intermediate System is appointed forwarder for the VLAN are
   not the same, the sub-TLV is incorrect and must be split into
   multiple subTLVs each indicating only VLANs with the same set of DRB
   seen root bridge IDs.  It is always safe to use sub-TLVs with a
   "range" of one VLAN ID but this may be too verbose.

   This sub-TLV is carried within the CAPABILITY TLV in a level-1 non-
   pseudo-node LSP.

2.4.7.  The VLAN Group sub-TLV

   The VLAN Group sub-TLV consists of two or more 16-bit fields each of
   which has a VLAN ID in the low order 12 bits.  The top 4 bits MUST be
   sent as zero and ignored on receipt.  The first such VLAN ID is the
   primary, or may be zero if there is no primary.  It is carried within
   the CAPABILITY TLV in a level-1 non-pseudo-node LSP and is given as:







Banerjee, et al.        Expires January 12, 2010               [Page 23]

Internet-Draft                Layer-2-IS-IS                    July 2009


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

   where each VLAN group record is of the form:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Primary VLAN ID (2 bytes)   |  Secondary VLAN ID (2 bytes)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: TLV Type, set to 11 (VLAN-GROUPs).

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

   o  Primary VLAN-ID: This identifies the primary VLAN-ID.

   o  Secondary VLAN-ID: This identifies the secondary VLAN-ID, address
      learning is shared at the Intermediate System that announces this
      sub-tlv.

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

2.4.8.  The Ingress-to-Egress Options (ITEOPT) sub-tlv

   By including this sub-TLV within one or more Router Capability TLVs
   in its LSPs, an RBridge can advertise the Ingress-to-Egress options
   it supports.  This sub-TLV may appear zero or more times within a
   Router Capability TLV.  By default, in the absence of any ITEOPT sub-
   TLVs, no Ingress-to-Egress options are supported.

   All Ingress-to-Egress options are TLV encoded within the TRILL Header
   options area.  The implementation of a TLV encoded option is
   indicated by an ITEOPT sub-TLV whose value starts with a byte equal
   to the first byte of the option.  Such ITEOPT sub-TLVs may have
   additional value bytes further indicating how the option is supported
   as specified in the option's definition, for example a list of
   supported security algorithms.






Banerjee, et al.        Expires January 12, 2010               [Page 24]

Internet-Draft                Layer-2-IS-IS                    July 2009


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

   o  Type: sub-TLV Type, set to Ingress-to-Egress option sub-TLV 12
      [TBD].

   o  Length: variable, minimum 1.

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

2.5.  Multi Topology Aware Capability TLV

   This section defines a new optional Intermediate System to
   Intermediate System (IS-IS) TLV named MT-CAPABILITY, formed of
   multiple sub-TLVs, which allows a router to announce its capabilities
   for a particular topology within an IS-IS level or the entire routing
   domain.  This is different from Capability TLV defined in RFC 4971,
   in the sense, the capabilities announced here are topology scoped.

   The Multi Topology Aware Capability (MT-CAPABILITY) is an optional
   IS-IS TLV type 144 [TBD], that may be generated by the originating IS
   and has the following format:
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Type=MTCAPABTLV| Length        |O|R|R|R|  Topology Identifier  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            sub-TLVs                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: TLV Type, set to MT-CAPABILITY TLV 144 [TBD].

   o  Length: Total number of bytes contained in the value field,
      including the length of the sub-TLVs carried in this TLV.

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

   o  Topology Identifier: MT ID is a 12-bit field containing the MT ID
      of the topology being announced.  This field when set to zero



Banerjee, et al.        Expires January 12, 2010               [Page 25]

Internet-Draft                Layer-2-IS-IS                    July 2009


      implies that it is being used to carry base topology information.
      In TRILL this value is set to ZERO, however, in IEEE SPB and SPBB,
      it may be non-zero.

   o  sub-tlvs: The MT aware Capabilities TLV value contains sub-TLVs
      formatted as described in [RFC5305].  They are defined in the next
      sections.

   The MT-aware CAPABILITY TLV MUST be carried only within a LSP PDU.
   It may occur multiple times in a LSP PDU.

2.5.1.  SPB Instance sub-TLV

   The SPB Instance sub-TLV gives the SPSourceID for this node/topology
   instance.  This is the 20 bit value that is used in the formation of
   multicast DA addresses for packets originating from this node/
   instance.  The SPSourceID occupies the upper 20 bits of the multicast
   DA together with 4 other bits (see the SPB 802.1ah multicast DA
   address format section).

   This TLV SHOULD be carried within the fragment ZERO LSP.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |S|  reserved   |    N-VID      | (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  VLAN-ID (1) Tuples                           | (4 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  VLAN-ID (N) Tuples                           | (4 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |R R R R|  SPS Flags  |V|              SPSOURCEID               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Reserved (Auto Allocation Tiebreaker)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Bridge Identifier                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Bridge Identifier (cont)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        CIST Root Identifier                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        CIST Root Identifier (cont)            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 CIST External ROOT Path Cost                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where VLAN-ID tuples have the format as:




Banerjee, et al.        Expires January 12, 2010               [Page 26]

Internet-Draft                Layer-2-IS-IS                    July 2009


       0 1   2- 3     4 - 15   16 - 19       20 - 31
      +-+-+---------+-------+-----------+------------+
      |A|U|Reserved |   VID | Algorithm |    B-VID   |
      +-+-+---------+-------+-----------+------------+

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

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

   o  S bit indicates the presence of sub-TLVs following this value.

   o  The N-VID must be set to the number of VIDs tuples that follow.
      This allows the sub-TLV starting point to be found.  Note N-VID
      here does not include the Base VID.

   o  Each VID Tuple consists of:

   o  ALG specifies the tie breaking algorithm to be used for this VID.
      Currently only the following values are supported:

      *  ALG = 0 a spanning tree.

      *  ALG = 1 the Low PATHID algorithm is used for this VID.

      *  ALG = 2 the High PATHID algorithm is used.

   o  VID is the VID for which the given algorithm applies.  This
      structure is used to indicate both shortest path VIDs and Single
      VIDs in the Case of SPBB.  Note the VID represents the SPVID
      associated with SPT Set. More details are in [REF].

   o  U bit, when set indicates that there are I-SIDs that locally use
      the VID associated with this SPT SET.  This U bit is used to avoid
      taking actions that would adversely affect traffic network wide.

   o  A bit, A bit when set declares this is an SPVID with auto
      allocation.  If the VID value is zero.  A VID will be allocated
      once the bridge has synchronized the IS-IS LSPs.  Neighbor bridges
      can distribute the LSPs but MUST not populate filtering databases
      (forwarding) for traffic from a bridge that has an SPVID of 0.
      When the bridge allocating receives the complete LSPs from the
      IS-IS adjacency it will allocate one or more SPVIDs according to
      the allocation logic.  It will then re-advertise this LSP with the
      allocated value.  If bridges detect a collision of allocated
      SPVIDs the loosing bridge will have its forwarding removed just as
      if it was unallocated.  When the originating bridge detects it is
      a loosing bridge in a collision it reallocates and simply re-
      advertises a new SPVID.  A bridge SHOULD remember SPVID



Banerjee, et al.        Expires January 12, 2010               [Page 27]

Internet-Draft                Layer-2-IS-IS                    July 2009


      allocations through restarts by storing them in non volatile
      memory and therefore reuse the SPVID value.

   o  The SPSOURCEID is a 20 bit value used to construct multicast DA's
      as described below for multicast packets originating from the
      origin (SPB node) of the link state packet (LSP) that contains
      this TLV.  More details are in [REF].

   o  The Auto Allocation Tie Breaker is a reserved field that would
      allow collisions in SPSOURCEID to be resolved.  If these fields
      are equal then the Bridge Priority takes precedence and if Bridge
      Priority is equal then the numerically higher Bridge ID wins.  The
      V bit indicates this SPSOURCEID is auto allocated.  Note
      SPSOURCEIDs are only used in the case of Backbone Brides with
      single VIDs ( Base-VID TLV B bit = 1 and M bit = 0).  Single VIDS
      are not auto allocated.  If the A bit is clear the SPSOURCEID has
      been configured and must be unique.  When the bridge allocating
      receives the complete LSP from the IS-IS adjacency it will
      allocate a SPSOURCEID according to the allocation logic.  It will
      then re-advertise this LSP with the allocated value.  If bridges
      detect a collision of allocated SPSOURCEIDs the loosing bridge
      (determined by the tie breaking algorithm) will have its
      forwarding removed just as if it was unallocated.  When the
      originating bridge detects it is a loosing bridge in a collision
      it reallocates and simple re-advertises a new SPSOURCEID.  A
      bridge SHOULD remember SPSOURCEID allocations through restarts by
      storing them in non volatile memory and reuse the SPSOURCEID
      value.

   o  Bridge Identifier is the Spanning tree compatible Bridge
      identifier.  This is configured exactly as specified in IEEE802
      [802.1D].  This allows SPB to build a compatible Spanning tree
      using link state.

   o  The four most significant bits of the most significant byte of a
      Bridge Identifier comprise a settable priority component that
      permits the relative priority of Bridges to be managed.  The next
      most significant twelve bits of a Bridge Identifier (the four
      least significant bits of the most significant byte, plus the
      second most significant byte) comprise a locally assigned system
      ID extension.  The six least significant bytes ensure the
      uniqueness of the Bridge identifier; they shall be derived from
      the globally unique Bridge Address according to the following
      procedure.  The third most significant byte is derived from the
      initial byte of the MAC Address; the least significant bit of the
      byte (Bit 1) is assigned the value of the first bit of the Bridge
      Address, the next most significant bit is assigned the value of
      the second bit of the Bridge Address, and so on.  The fourth



Banerjee, et al.        Expires January 12, 2010               [Page 28]

Internet-Draft                Layer-2-IS-IS                    July 2009


      through eighth bytes are similarly assigned the values of the
      second to the sixth bytes of the Bridge Address.

   o  CIST Root Identifier is for SPB interworking with RSTO and MSTP at
      SPT Region Boundaries.  This is an imported value from a Spanning
      tree.

   o  CIST External Root Path Cost is the cost from the Spanning tree
      algorithm to the Root.

2.5.2.  Service Identifier and Unicast Address sub-TLV

   The SPB Service Identifier and Unicast Address TLV is used to
   introduce service group membership on the originating node and/or to
   advertise an additional B-MAC unicast address present on, or
   reachable by the node.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          B-MAC ADDRESS                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   B-MAC ADDRESS (cont)        |  Res. |         VID           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |T|R| Reserved  |                  ISID  #1                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |T|R| Reserved  |                  ISID  #2                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |T|R| Reserved  |                  ISID  #n                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

   o  B-MAC ADDRESS is a unicast address of this node.  It may be either
      the single nodal address, or may address a port or any other level
      of granularity relative to the node.  In the case where the node
      only has one B-MAC address this should be the same as the SYS-ID
      of the node.  To add multiple B-MACs this TLV must be repeated per
      additional B-MAC.

   o  ISID #1 .. #N are 24 bit service group membership identifiers.  If
      two nodes have an ISID in common, intermediate nodes on the unique
      shortest path between them will create forwarding state for the
      related B-MAC addresses and will also construct multicast
      forwarding state using the ISID and the node's SPSOURCEID to



Banerjee, et al.        Expires January 12, 2010               [Page 29]

Internet-Draft                Layer-2-IS-IS                    July 2009


      construct a multicast DA as described in IEEE 802.1aq LSB.  Each
      ISID has a Transmit(T) and Receive(R) bit which indicates if the
      membership is as a Transmitter/Receiver or both (with both bits
      set).  In the case where the Transmit(T) and Receive(R) bits are
      both zero, the ISID is ignored.  If more ISIDs are associated with
      a particular B-MAC than can fit in a single TLV, this TLV can be
      repeated with the same B-MAC but with different ISID values.

2.6.  SPB Link Metric sub-tlv

   The SPB Link Metric Sub TLV occurs nested as within the Extended
   Reachability TLV (type 22), or the Multi Topology Intermediate System
   TLV (type 222).  If this sub TLV is not present for an ISIS adjacency
   then that adjacency MUST NOT carry SPB traffic for the given topology
   instance.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Reserved (must be 0)                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       SPB-LINK-METRIC                         | Num port ID   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Port  Identifier          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

   o  SPB-LINK-METRIC indicates the administrative cost or weight of
      using this link as a 24 bit unsigned number.  Smaller numbers
      indicate lower weights and are more likely to carry SPB traffic.
      Only one metric is allowed per SPB instance per link.  If multiple
      metrics are required multiple SPB instances are required, either
      within IS-IS or within several independent IS-IS instances.

   o  Num of Ports is the number of ports associated with this link.

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

   SPB routes follow the minimum sum of link metrics from the source to
   the destination.  If any SPB link metric is not the same as its
   reverse direction metric the metric for both directions of the above
   calculation is considered to be the maximum of the two differing
   metrics.  If an SPB metric TLV is missing from one or both directions
   of an adjacency no SPB traffic may flow between those nodes for the



Banerjee, et al.        Expires January 12, 2010               [Page 30]

Internet-Draft                Layer-2-IS-IS                    July 2009


   corresponding SPB topology instance (MT-ID).  In the event of two or
   more equal minimum sum of link metrics paths, the unique shortest
   path is chosen according to the symmetric tie breaking algorithm Low-
   PATHID and/or High-PATHID as described in IEEE 802.1aq LSB.  When a
   single SPB instance is used this TLV occurs as a sub-TLV of TLV 22
   but when multiple instances are used it must be present as a sub-TLV
   of the Multi Topology Intermediate System Tlv (type 222) with the
   appropriate MT-ID to correlate it with the other top level TLV's used
   to specify the SPB topology instance in question.


3.  The Multicast Group PDU

   The systems that this dcoument is concerned with want to carry not
   only layer-2 unicast information in the link state protocols, but
   also multicast information.  This document specifies three new IS-IS
   PDUs, the Multicast Group (MGROUP) PDU, for carrying a list of
   attached or joined multicast groups.  The Multicast Group Complete
   Sequence Number (MGROUP-CSNP) PDU and the Multicast Group Partial
   Sequence Number (MGROUP-PSNP) PDU packets are also defined to be used
   with the new MGROUP-PDU to perform database exchange on the MGROUP
   PDU packets.

   In the Layer-2 environment, it is expected the join/leave frequency
   of the multicast members will be much higher than unicast topology
   changes.  It is efficient to separate the updates for the group
   membership change information from the remainder of the information
   by placing this information in a separate PDU.  This enables
   reachability information, that would trigger an SPF, to be not
   impacted at all.  Furthermore, during SPF runs, TLVs being on
   different PDUs which do not affect SPF need not be inspected during
   processing.

   The choice of a different PDU also opens the LSP-space to another 256
   fragments to carry a large number of groups.  This additional space
   can be used judiciously to carry only multicast information.

   The Multicast Group (MGROUP) PDU can be used to advertise a set of
   attached, or joined, multicast groups.  The MGROUP PDU is formatted
   identical to a Level 1 Link State PDU, as described in Section 9.3 of
   [IS-IS].  One field, PDU Type, is changed to 19 [TBD], to signify
   this PDU is carrying multicast group information, rather than unicast
   reachability information.  The PDU MUST NOT carry Area Address TLV or
   Protocol Support TLV in the zeroth fragment.

   The Multicast Group PDU carries TLVs indicating multicast membership
   information.  There are three sub-TLVs of the GADDR TLV defined in
   this document, that MAY be present in this PDU, namely, GMAC-ADDR,



Banerjee, et al.        Expires January 12, 2010               [Page 31]

Internet-Draft                Layer-2-IS-IS                    July 2009


   GIP-ADDR, and GIPV6-ADDR TLVs.

   One or more TLVs MAY be carried in a single MGROUP PDU.  Future
   multicast address TLVs MAY be defined using other type codes, and be
   carried in an MGROUP PDU.

   The information carried in this PDU is processed in a similar fashion
   as described in [RFC 1584].

3.1.  The Multicast Group Partial Sequence Number PDU

   The Multicast Group Partial Sequence Number (MGROUP-PSNP) PDU is used
   to reliably flood the MGROUP PDU following the base protocol
   specifications.

3.2.  The Multicast Group Complete Sequence Number PDU

   The Multicast Group Complete Sequence Number PDU (MGROUP-CSNP) PDU is
   used to reliably flood the MGROUP PDU following the base protocol
   specifications.

3.3.  Enhancements to the flooding process

   This document proposes that the information contained in the MGROUP-
   PDU is in a parallel database and its update mechanisms mimic that of
   the regular database.  Nodes running IS-IS in an L2 domain MUST
   support these additional MGROUP PDUs defined in this document.  In
   general, the flooding of the MGROUP-PDU in tandem with the MGROUP-
   PSNP and MGROUP-CSNP PDUs uses the same update procedures as defined
   for the regular LSP, PSNP, and CSNP PDUs.

   For example, on P2P links CSNP is exchanged on the formation of an
   adjacency.  In a similar fashion a MGROUP-CSNP MUST also be exchanged
   between the neighbors at the same time.  This gets the initial
   MGROUP-database synchronization going.  After this similar actions of
   the base protocol specifications for the regular database
   synchronization will be maintained to keep the MGROUP-database
   synchronized.

   Similarly, on LAN links the DIS is responsible for sending periodic
   CSNP transmissions.  The DIS in the L2 IS-IS network domain will also
   be responsible for sending periodic MGROUP-CSNP transmissions.  The
   update and flooding process will work in parallel for the two
   databases and there is no further synchronization between them.

   In general, the database synchronization is performed in parallel
   with no interactions between the messages.  However, the initial
   triggers that start a CSNP exchange are correlated, in the sense it



Banerjee, et al.        Expires January 12, 2010               [Page 32]

Internet-Draft                Layer-2-IS-IS                    July 2009


   also triggers a MGROUP-CSNP exchange.  For example, during graceful
   restart [RFC 5306], the normal hello operations as described in the
   RFC will be followed.  The enhancements will take place such that
   CSNP and PSNP triggers will necessitate a parallel MGROUP-CSNP and
   MGROUP-PSNP exchange and update process will be triggered in parallel
   for the MGROUP-PDUs.  After both databases containing the regular
   PDUs and MGROUP-PDUs have been obtained, the restart process is
   deemed complete.

3.4.  Enhancements to the maximum sequence number reached

   In the event, LSPs reach the maximum sequence number, ISO/IEC 10589
   states the rules for the process to shut down and its duration.  With
   the introduction of the MGROUP-PDU, the same process now applies when
   LSPs from either database reach the maximum sequence number.


4.  Considerations for Using L2 Information in IS-IS

   While this document does not specify the way in which addresses
   carried in these TLVs are used in IS-IS, two general areas of concern
   are considered in this section: building the SPF tree when using this
   information, and the election of designated intermediate systems
   (DIS) in an environment using this information.

4.1.  Building SPF Trees with Layer 2 Information

   Each IS which is part of a single broadcast domain from a layer 2
   perspective will build multiple SPF trees (SPT) for every IS that is
   announced by the IS deemed to be the broadcast root.

   We assume some mechanism for forwarding traffic to these attached
   addresses added to the SPT is provided for in the mechanism proposing
   the use of these extension TLVs.

4.2.  Designated Intermediate Routers

   A single DIS SHOULD be elected as described in [IS-IS] for each layer
   2 broadcast domain (VLAN) for which information is being carried in
   IS-IS.  This reduces the amount of work required to flood and
   maintain synchronized databases over the underlying media on which
   IS-IS is running and providing layer 2 forwarding information for.


5.  Acknowledgements

   The authors would like to thank Les Ginsberg for his useful comments.




Banerjee, et al.        Expires January 12, 2010               [Page 33]

Internet-Draft                Layer-2-IS-IS                    July 2009


6.  Security Considerations

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


7.  IANA Considerations

   This document creates three new PDU types, namely the MCAST PDU,
   MCAST-CSNP PDU, and the MCAST-PSNP PDU.  IANA SHOULD assign a new PDU
   type to the level-1 PDUs described above and reflect it in the PDU
   registry.

      MCAST-PDU        Level-1 PDU Type: 19
      MCAST-CSNP-PDU   Level-1 PDU Type: 22
      MCAST-PSNP-PDU   Level-1 PDU Type: 29

   This document requires the definition a set of new ISIS TLVs, the
   MAC-Reachability TLV (type 141), the Group Address TLV (type 142),
   and the Link-Capability TLV (type 143), that needs to be reflected in
   the ISIS TLV code-point registry.

   This document creates a number of new sub-TLV in the numbering space
   for the Group Address TLV, the Link Capability TLV, and the
   Capability TLV.  The TLV and sub-TLVs are given below along with
   technologies that use them.

























Banerjee, et al.        Expires January 12, 2010               [Page 34]

Internet-Draft                Layer-2-IS-IS                    July 2009


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

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

   MT-Port-Cap-TLV (143)                   X    -    -    -     -    T/-
   PortCap.VLAN and Flags   sub-tlv  1     X    -    -    -     -    T/-
   PortCap.Enabled-VLANs    sub-tlv  2     X    -    -    -     -    T/-
   PortCap.AppointedFwrdrs  sub-tlv  3     X    -    -    -     -    T/-
   PortCap.HopbyHopOptions  sub-tlv  4     X    -    -    -     -    T/-
   PortCap.BaseVLANID       sub-tlv  5     X    -    -    -     -    -/I

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

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

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

   IANA SHOULD manage the remaining space using the consensus method.


8.  Contributing Authors

      David Ward
      Cisco Systems
      170 W Tasman Drive
      San Jose, CA  95138
      US

      Email: wardd@cisco.com


      Russ White
      Cisco Systems



Banerjee, et al.        Expires January 12, 2010               [Page 35]

Internet-Draft                Layer-2-IS-IS                    July 2009


      170 W Tasman Drive
      San Jose, CA  95138
      US

      Email: riw@cisco.com


      Dino Farinacci
      Cisco Systems
      170 W Tasman Drive
      San Jose, CA  95138
      US

      Email: dino@cisco.com

      Radia Perlman
      Sun Microsystems
      16 Network Circle
      Menlo Park, CA  94025
      US

      Email: Radia.Perlman@Sun.com


      Donald E. Eastlake 3rd
      Stellar Switches
      155 Beaver Street
      Milford, MA  07157
      US

      Email: d3e3e3@gmail.com


      Peter Ashwood-Smith
      Huawei Technologies Canada Co. Ltd.
      411 Legget Drive, Suite 503
      Kanta, Ontario  K2K 3C9
      CANADA

      Email: Peter.AshwoodSmith@huawei.com


      Don Fedyk
      Alcatel-Lucent
      220 Hayden Road
      Groton, MA  01450
      US




Banerjee, et al.        Expires January 12, 2010               [Page 36]

Internet-Draft                Layer-2-IS-IS                    July 2009


      Email: Donald.Fedyk@alcatel-lucent.com


9.  References

9.1.  Normative References

   [IS-IS]    ISO/IEC 10589, "Intermediate System to Intermediate System
              Intra-Domain Routing Exchange Protocol for use in
              Conjunction with the Protocol for Providing the
              Connectionless-mode Network Service (ISO 8473)", 2005.

   [RFC 1195]
              Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and
              Dual Environments", 1990.

   [RFC 4971]
              Vasseur, JP. and N. Shen, "Intermediate System to
              Intermediate System (IS-IS) Extensions for Advertising
              Router Information", 2007.

   [RFC 5305]
              Li, T. and H. Smit, "IS-IS Extensions for Traffic
              Engineering", 2008.

   [RFC 5306]
              Shand, M. and L. Ginsberg, "Restart Signaling for
              Intermediate System to Intermediate System (IS-IS)", 2004.

9.2.  Informative References

   [IEEE 802.1aq]
              "Standard for Local and Metropolitan Area Networks /
              Virtual Bridged Local Area Networks / Amendment 9:
              Shortest Path Bridging, Draft IEEE P802.1aq/D1.5", 2008.

   [RBRIDGES]
              Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A.
              Ghanwani, "RBridges: Base Protocol Specification", 2009.

   [RFC 1584]
              Moy, J., "Multicast Extensions to OSPF", March 1994.









Banerjee, et al.        Expires January 12, 2010               [Page 37]

Internet-Draft                Layer-2-IS-IS                    July 2009


Author's Address

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

   Email: ayabaner@cisco.com










































Banerjee, et al.        Expires January 12, 2010               [Page 38]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/