[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                                 D. Ward
Expires: November 1, 2010                               Juniper Networks
                                                                R. White
                                                            D. Farinacci
                                                           Cisco Systems
                                                              R. Perlman
                                                              Intel Labs
                                                             D. Eastlake
                                                        Stellar Switches
                                                        P. Ashwood-Smith
                                                                  Huawei
                                                                D. Fedyk
                                                          Alcatel-Lucent
                                                          April 30, 2010


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

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 in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on November 1, 2010.




Banerjee, et al.        Expires November 1, 2010                [Page 1]


Internet-Draft                Layer-2-IS-IS                   April 2010


Copyright Notice

   Copyright (c) 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.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  PDU, TLV and sub-TLV Enhancements to IS-IS . . . . . . . . . .  5
     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 . . . . . . . . . . . . . 15
       2.3.4.  Hop-by-Hop Options (HBHOPT) sub-TLV  . . . . . . . . . 16
       2.3.5.  Base VLAN-Identifiers sub-TLV  . . . . . . . . . . . . 17
       2.3.6.  SPB Digest sub-TLV . . . . . . . . . . . . . . . . . . 18
       2.3.7.  Site Identifier sub-TLV  . . . . . . . . . . . . . . . 20
       2.3.8.  Site Group IPv4 sub-TLV  . . . . . . . . . . . . . . . 20
       2.3.9.  Site Group IPv6 sub-TLV  . . . . . . . . . . . . . . . 21
       2.3.10. Adjacency Server IPv4 sub-TLV  . . . . . . . . . . . . 22
       2.3.11. Adjacency Server IPv6 sub-TLV  . . . . . . . . . . . . 22
     2.4.  Sub-TLVs for the Router Capability TLV . . . . . . . . . . 23
       2.4.1.  The TRILL Version sub-TLV  . . . . . . . . . . . . . . 23
       2.4.2.  The Nickname sub-TLV . . . . . . . . . . . . . . . . . 24
       2.4.3.  The Trees sub-TLV  . . . . . . . . . . . . . . . . . . 25
       2.4.4.  The Tree Identifiers Sub-TLV . . . . . . . . . . . . . 26
       2.4.5.  The Trees Used Identifiers Sub-TLV . . . . . . . . . . 27
       2.4.6.  Interested VLANs and Spanning Tree Roots sub-TLV . . . 27
       2.4.7.  The VLAN Group sub-TLV . . . . . . . . . . . . . . . . 29
       2.4.8.  The Ingress-to-Egress Options (ITEOPT) sub-TLV . . . . 30
       2.4.9.  VLAN Mapping (VMAP) sub-TLV  . . . . . . . . . . . . . 31



Banerjee, et al.        Expires November 1, 2010                [Page 2]


Internet-Draft                Layer-2-IS-IS                   April 2010


     2.5.  Multi Topology Aware Capability TLV  . . . . . . . . . . . 32
       2.5.1.  SPB Instance sub-TLV . . . . . . . . . . . . . . . . . 33
       2.5.2.  SPB Opaque ECT Algorithm sub-TLV . . . . . . . . . . . 36
       2.5.3.  SPBM Service Identifier and Unicast Address sub-TLV  . 37
       2.5.4.  The SPBV MAC Address sub-TLV . . . . . . . . . . . . . 38
     2.6.  Sub-TLVs of the Extended Reachability TLV  . . . . . . . . 39
       2.6.1.  SPB Link Metric sub-TLV  . . . . . . . . . . . . . . . 39
       2.6.2.  SPB Opaque ECT Algorithm sub-TLV . . . . . . . . . . . 40
       2.6.3.  MTU sub-TLV  . . . . . . . . . . . . . . . . . . . . . 40
     2.7.  TRILL Neighbor TLV . . . . . . . . . . . . . . . . . . . . 41
     2.8.  The Group Membership Active Source TLV . . . . . . . . . . 42
       2.8.1.  The Group MAC Active Source sub-TLV  . . . . . . . . . 43
       2.8.2.  The Group IP Active Source sub-TLV . . . . . . . . . . 45
       2.8.3.  The Group IPv6 Active Source sub-TLV . . . . . . . . . 47
     2.9.  PDU Extensions to IS-IS  . . . . . . . . . . . . . . . . . 49
       2.9.1.  The Multicast Group PDU  . . . . . . . . . . . . . . . 49
       2.9.2.  The Multicast Group Partial Sequence Number PDU  . . . 50
       2.9.3.  The Multicast Group Complete Sequence Number PDU . . . 50
       2.9.4.  MGROUP PDU related changes to Base protocol  . . . . . 50
         2.9.4.1.  Enhancements to the flooding process . . . . . . . 50
         2.9.4.2.  Enhancements to Graceful Restart . . . . . . . . . 51
         2.9.4.3.  Enhancements to the maximum sequence number
                   reached  . . . . . . . . . . . . . . . . . . . . . 51
         2.9.4.4.  Enhancements to the SPF  . . . . . . . . . . . . . 51
       2.9.5.  The TRILL-Hello PDU  . . . . . . . . . . . . . . . . . 51
       2.9.6.  The MTU PDU  . . . . . . . . . . . . . . . . . . . . . 52
   3.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 54
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 55
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 56
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 58
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 58
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 58
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59


















Banerjee, et al.        Expires November 1, 2010                [Page 3]


Internet-Draft                Layer-2-IS-IS                   April 2010


1.  Overview

   There are a number of systems (for example, [RBRIDGES], [802.1aq],
   [OTV]) that use layer 2 addresses carried in a link state routing
   protocol, specifically IS-IS [IS-IS] [RFC1195], to provide true layer
   2 routing.  This document specifies a set of TLVs and sub-TLVs to be
   added to [IS-IS] level 1 PDUs, and 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 [802.1aq] or [OTV].
   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
   specifies additional TLVs and sub-TLVs to carry information as
   required by the IETF TRILL, IEEE 802.1aq and OTV protocols.

   This document specifies six 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 PDUs.  The TRILL-Hello PDU
   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 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.
















Banerjee, et al.        Expires November 1, 2010                [Page 4]


Internet-Draft                Layer-2-IS-IS                   April 2010


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

   In this section we specify the enhancements for the PDUs, TLVs and
   sub-TLVs as needed by Layer-2 technologies.

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)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Topology-Id/ Nickname       |  (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  Topology-Id/Nickname : Depending on the technology in which it is
      used, this carries the topology-id or nickname.  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  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  RESV: Must be sent as zero on transmission and is ignored on
      receipt.




Banerjee, et al.        Expires November 1, 2010                [Page 5]


Internet-Draft                Layer-2-IS-IS                   April 2010


   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:

   +-+-+-+-+-+-+-+-+
   | Type=GADDRTLV |                  (1 byte)
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   sub-TLVs   (variable bytes) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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 only within a 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 November 1, 2010                [Page 6]


Internet-Draft                Layer-2-IS-IS                   April 2010


   +-+-+-+-+-+-+-+-+
   | Type=GMAC-ADDR|                  (1 byte)
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Topology-Id/ Nickname       |  (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  Topology-Id/Nickname : Depending on the technology in which it is
      used, this carries the topology-id or nickname.  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.





Banerjee, et al.        Expires November 1, 2010                [Page 7]


Internet-Draft                Layer-2-IS-IS                   April 2010


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

   o  Group Record: Each group record has a one byte reserved space and
      the next byte carries the number of sources.  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 in another sub-TLV of another instance of the
      Group Address TLV.

   The GMAC-ADDR sub-TLV is carried only within a 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 sub-TLV type 2 within
   the GADDR TLV and has the following format:


















Banerjee, et al.        Expires November 1, 2010                [Page 8]


Internet-Draft                Layer-2-IS-IS                   April 2010


   +-+-+-+-+-+-+-+-+
   | Type=GIP-ADDR |
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Topology-Id/ Nickname       |  (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         (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
      sub-TLV.

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





Banerjee, et al.        Expires November 1, 2010                [Page 9]


Internet-Draft                Layer-2-IS-IS                   April 2010


   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  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 addresses in this sub-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 sub-TLV.

   o  Group Record: Each group record has a one byte reserved space and
      the next byte carries the number of sources.  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 another sub-TLV of another
      instance of the Group Address TLV.

   The GIP-ADDR sub-TLV is carried only within a 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) sub-TLV is IS-IS sub-TLV type 3
   and has the following format:




















Banerjee, et al.        Expires November 1, 2010               [Page 10]


Internet-Draft                Layer-2-IS-IS                   April 2010


   +-+-+-+-+-+-+-+-+
   |Type=GIPv6-ADDR|
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Topology-Id/ Nickname       |  (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 : Depending on the technology in which it is
      used, this carries the topology-id or nickname.  When this field



Banerjee, et al.        Expires November 1, 2010               [Page 11]


Internet-Draft                Layer-2-IS-IS                   April 2010


      is set to zero this implies that the 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  VLAN-ID: This carries a 12-bit VLAN identifier that is valid for
      all subsequent addresses in this sub-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 sub-TLV.

   o  Group Record: Each group record has a one byte reserved space and
      the next byte carries the number of sources.  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 another sub-TLV in
      another instance of the Group Address TLV.

   The GIPV6-ADDR sub-TLV is carried only within a 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 November 1, 2010               [Page 12]


Internet-Draft                Layer-2-IS-IS                   April 2010


      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-PORT-CAP TLV may occur multiple times, and is carried only
   within a Hello PDU.

2.3.1.  The Special VLANs and Flags sub-TLV

   The Special VLANs and Flags (VLAN and Flags) sub-TLV MUST only appear
   in a MT-PORT-CAP TLV.  It is carried exactly once in every TRILL IIH
   PDU.  It has the following format:

   +-+-+-+-+-+-+-+-+
   |Type=VLAN Flags|     (1 byte)
   +-+-+-+-+-+-+-+-+
   |   Length      |     (1 byte)
   +--------------------------------+
   |    Port ID                     |   (2 bytes)
   +--------------------------------+
   |     Sender Nickname            |   (2 bytes)
   +--+--+--+--+--------------------+
   |AF|AC|VM|BY|    Outer.VLAN      |   (2 bytes)
   +-----------+--------------------+
   |Reserved   |    Desig.VLAN      |   (2 bytes)
   +-----------+--------------------+

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

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

   o  Port ID: An ID for the port on which the enclosing TRILL IIH PDU
      is being sent.  The transmitting RBridge assigns this ID such that
      each of its ports has an ID different from all of its other ports.

   o  Sender nickname: If the sending intermediate system is holding any
      nicknames, one MUST be included here.  Otherwise, the field is set
      to zero.  This field is to support intelligent end stations that
      determine the egress RBridge for unicast data through a directory
      service or the like and need a nickname for their first hop to
      insert as the ingress nickname to correctly format a TRILL
      encapsulated data frame.

   o  The fifth and sixth bytes have a copy of the Outer VLAN ID
      associated with the Hello frame when it was sent.  The lower 4



Banerjee, et al.        Expires November 1, 2010               [Page 13]


Internet-Draft                Layer-2-IS-IS                   April 2010


      bits of the fifth byte give the upper ID bits of the VLAN ID and
      the sixth byte gives the lower VLAN ID bits.

   o  The upper 4 bits of the fifth 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 Hello 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 seventh and eighth bytes give the Designated VLAN for the
      link.  The lower 4 bits of the seventh byte give the upper ID bits
      of the Designated VLAN and the eighth byte gives the lower VLAN ID
      bits.  The upper 4 bits of the seventh byte are reserved and MUST
      be sent as zero and ignored on receipt.

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

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

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

   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



Banerjee, et al.        Expires November 1, 2010               [Page 14]


Internet-Draft                Layer-2-IS-IS                   April 2010


      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 indicates 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 Hello 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 sub-TLV of this
   type it finds in a Hello to derive the complete bit map of these
   VLANs.

   The Enabled VLAN sub-TLV is carried only within the MT-PORT-CAP TLV.
   If present, it MUST be carried in TRILL IIH PDU.  It MUST NOT be
   carried within a LAN IIH or 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.  It has the following
   format:

   +-+-+-+-+-+-+-+-+
   |Type=App Frwrdr|
   +-+-+-+-+-+-+-+-+
   |   Length      |   (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Appointment Information (1)         | (6 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   .................                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Appointment Information (N)         | (6 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where each appointment information is of the form:

   +---------------------------+
   |    Appointee Nick         |  (2 bytes)
   +---------------------------+
   | Res |    Start VLAN ID    |  (2 bytes)
   +---------------------------+
   | Res |     End VLAN ID     |  (2 bytes)
   +---------------------------+



Banerjee, et al.        Expires November 1, 2010               [Page 15]


Internet-Draft                Layer-2-IS-IS                   April 2010


   o  Type: sub-TLV Type, set to Appointed Forwarders sub-TLV 3 [TBD].

   o  Length: The size of the value is 6*n bytes where there are n
      appointments.

   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 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 VLAN if end station service is
   enabled.

   The Appointed Forwarder sub-TLV is carried within the 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 encodings within the TRILL
   Header: bit options and TLV encoded options.

   The bit-encoded options supported are indicated by an HBHOPT sub-TLV



Banerjee, et al.        Expires November 1, 2010               [Page 16]


Internet-Draft                Layer-2-IS-IS                   April 2010


   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 and
   are ignored on receipt.

   The implementation of the type of option encoded in a TRILL Header as
   a TLV 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: Either 0x00 followed by implementation information for bit
      encoded options or a non-zero option type byte followed by option
      dependent information for that option.

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) that
   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 neighbors with respect to this sub-TLV are
   temporarily allowed but at least the active the Base-VID must agree
   and use the same ECT-ALGORITHM.









Banerjee, et al.        Expires November 1, 2010               [Page 17]


Internet-Draft                Layer-2-IS-IS                   April 2010


   +-+-+-+-+-+-+-+-+
   |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-VLAN-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 associated 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 ECT-ALGORITHM 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 digest for
   Multiple spanning tree configuration Digests (MCID) and the IS-IS
   agreement Digest.  This information should be the same on all bridges
   in the topology identified by MT-PORT-CAP TLV it is being carried.
   These digests indicate when the configuration and the topology are
   synchronized and are used to control the updating of forwarding
   information.  The MCID is controlled solely by configuration and is a



Banerjee, et al.        Expires November 1, 2010               [Page 18]


Internet-Draft                Layer-2-IS-IS                   April 2010


   digest of the allocated VIDs to various protocols.  Two MCIDs are
   carried to allow transitions when the configuration changes are non-
   critical.  During the propagation of LSPs the agreement digest will
   vary between neighbors until the LSPs are common.  The digest is a
   summarized means of determining agreement between nodes on the
   distance to all multicast roots, hence is essential for loop
   prevention.  During the propagation of LSPs the agreement digest will
   vary between neighbors until the required portions of LSPs are
   common.  For each shortest path tree where it has been determined the
   distance to the root has changed, multicast forwarding is blocked
   until the exchanged digests match.  Discrepancies between neighbors
   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



Banerjee, et al.        Expires November 1, 2010               [Page 19]


Internet-Draft                Layer-2-IS-IS                   April 2010


      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.  This is used in OTV [OTV] to aid in Authoritative
   Edge Device election.  It has the following format:

      +-+-+-+-+-+-+-+-+
      |Type = SiteCap |
      +-+-+-+-+-+-+-+-+
      |   Length      |                  (1 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                System ID (6 bytes)                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Cluster ID (2 bytes) |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Resv (7bits) |U|      (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  Reserved: Must be sent as zero on transmission and is ignored on
      receipt.

   o  U bit: Denotes if the site is a unicast only site.

   The Site Capability sub-TLV is carried only within the MT-PORT-CAP
   TLV and this is carried in a Hello PDU.  There must be only one
   occurrence of this sub-TLV in the Hello PDU.

2.3.8.  Site Group IPv4 sub-TLV

   The Site Group IPv4 sub-TLV carries information about the overlays
   active on this device.  This is used in OTV [OTV] to aid in
   Authoritative Edge Device election.  It has the following format:




Banerjee, et al.        Expires November 1, 2010               [Page 20]


Internet-Draft                Layer-2-IS-IS                   April 2010


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

   The Site Group IPv4 sub-TLV is carried within the MT-PORT-CAP TLV and
   this is carried in a Hello PDU.  There may be more than one
   occurrence of this sub-TLV in the Hello PDU.

2.3.9.  Site Group IPv6 sub-TLV

   The Site Group IPv6 sub-TLV carries information about the overlays
   active on this device.  This is used in OTV [OTV] to aid in
   Authoritative Edge Device election.  It has the following format:

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

   The Site Group IPv6 sub-TLV is carried within the MT-PORT-CAP TLV and
   this is carried in a Hello PDU.  There may be more than one



Banerjee, et al.        Expires November 1, 2010               [Page 21]


Internet-Draft                Layer-2-IS-IS                   April 2010


   occurrence of this sub-TLV in the Hello PDU.

2.3.10.  Adjacency Server IPv4 sub-TLV

   The Adjacency Server IPv4 sub-TLV carries information about the
   capability of the sites in OTV [OTV].  It has the following format:

   +-+-+-+-+-+-+-+-+
   |Type = ASIPv4  |
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Adjacency IPv4 Information (1)      | (5 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   .................                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Adjacency IPv4 Information (N)      | (5 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where each adjacency IPv4 information is of the form:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                IPv4 address (4 bytes)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Resv (7bits) |U|      (1 byte)
    +-+-+-+-+-+-+-+-+

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

   o  Length: The size of the value, 5*n, where there are n adjacency
      server information blocks.

   o  IPv4 Address: The IPv4 addresses used by the sites.

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

   o  U bit: Denotes if the site is a unicast only site.

   The Adjacency Server IPv4 sub-TLV is carried within the MT-PORT-CAP
   TLV and this is carried in a Hello PDU.

2.3.11.  Adjacency Server IPv6 sub-TLV

   The Adjacency Server IPv6 sub-TLV carries information about the
   capability of the sites in OTV [OTV].  It has the following format:





Banerjee, et al.        Expires November 1, 2010               [Page 22]


Internet-Draft                Layer-2-IS-IS                   April 2010


   +-+-+-+-+-+-+-+-+
   |Type = ASIPv6  |
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Adjacency IPv6 Information (1)      | (17 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   .................                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Adjacency IPv6 Information (N)      | (17 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where each adjacency IPv6 information is of the form:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                IPv6 address (16 bytes)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Resv (7bits) |U|      (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 IPv6 addresses used by the sites.

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

   o  U bit: Denotes if the site is a unicast only site.

   The Adjacency Server IPv6 sub-TLV is carried within the MT-PORT-CAP
   TLV and this is carried in a Hello PDU.  Multiple such TLVs may be
   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 to 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



Banerjee, et al.        Expires November 1, 2010               [Page 23]


Internet-Draft                Layer-2-IS-IS                   April 2010


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

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




Banerjee, et al.        Expires November 1, 2010               [Page 24]


Internet-Draft                Layer-2-IS-IS                   April 2010


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

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

   o  Nickname Priority: This is an unsigned 8-bit integer that gives
      the priority with which this node holds this nickname.

   o  Tree Root Priority: This is an unsigned 16-bit integer that gives
      the priority of this nickname to become a distribution tree root.

   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.

   All nodes run the same algorithm as described in [RBRIDGES] and the
   elected highest priority tree root dictates the number of
   distribution tree roots to be used in the network domain and can
   additionally 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).





Banerjee, et al.        Expires November 1, 2010               [Page 25]


Internet-Draft                Layer-2-IS-IS                   April 2010


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

2.4.4.  The Tree Identifiers Sub-TLV

   The tree 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 trees which the other Intermediate
   Systems are required to compute.  If this information is spread
   across multiple sub-TLVs, the starting tree number is used to to
   allow the ordered lists to be correctly concatenated.  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 Number         |    (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 that are trees for the domain.  This is set to 1 for
      the first sub-TLV.  Subsequent sub-TLVs will have the starting
      number of the ordered list.  In the event a tree identifier can be



Banerjee, et al.        Expires November 1, 2010               [Page 26]


Internet-Draft                Layer-2-IS-IS                   April 2010


      computed from two such sub-TLVs and are different, then it is
      assumed that this is a transient condition that will get cleared.
      During this transient time, such trees cannot be computed.

   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 Identifiers 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 trees 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          |            (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: If this is set to 0, then it applies to all nicknames
      generated by the node.  It may alternatively be set to a specific
      nickname, in the event a node wants to segregate traffic using
      multiple nicknames.





Banerjee, et al.        Expires November 1, 2010               [Page 27]


Internet-Draft                Layer-2-IS-IS                   April 2010


   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 set 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 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 sub-TLVs 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.

   Wherever possible, an implementation SHOULD advertise the update to a



Banerjee, et al.        Expires November 1, 2010               [Page 28]


Internet-Draft                Layer-2-IS-IS                   April 2010


   interested vlan and spanning tree roots sub-TLV in the same LSP
   fragment as the advertisement that it replaces.  Where this is not
   possible, the two affected LSP fragments should be flooded as an
   atomic action.

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

   Where a receiving system has two copies of a interested vlan and
   spanning tree roots sub-TLV from the same system that have different
   settings for a given vlan, the procedure used to choose which copy
   shall be used is undefined (refer to RFC 4971, Section 3).

   This sub-TLV is carried within the CAPABILITY TLV in a level-1
   multicast group PDU.

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
   set 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 structured
   as follows:

   +-+-+-+-+-+-+-+-+
   |Type=VLAN-GROUP|
   +-+-+-+-+-+-+-+-+
   |   Length      |   (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Primary VLAN ID (2 bytes)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Secondary VLAN ID (2 bytes)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  more Secondary VLAN IDs ...  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

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




Banerjee, et al.        Expires November 1, 2010               [Page 29]


Internet-Draft                Layer-2-IS-IS                   April 2010


   o  Secondary VLAN-ID: This identifies a secondary VLAN in the VLAN
      Group.

   This sub-TLV indicates that shared VLAN learning is occurring at the
   announcing Intermediate System between the listed VLANs.  This sub-
   TLV may appear zero, one, or multiple times.  It should be noted that
   all VLAN ID values described above have a 4 bit reserved section
   followed by a 12-bit value.  It is carried within the CAPABILITY TLV.

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.

   There are two types of Ingress-to-Egress option encoding within the
   TRILL Header: bit options and TLV encoded options.

   The bit-encoded options supported are indicated by an ITEOPT TLV of
   length 3: an initial value byte of 0x00 followed by two bytes in
   which each bit indicates that the corresponding bit Ingress-to-Egress
   option is implemented.

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

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




Banerjee, et al.        Expires November 1, 2010               [Page 30]


Internet-Draft                Layer-2-IS-IS                   April 2010


   o  Value: Either 0x00 followed by implementation information for bit
      encoded options or a non-zero option type byte followed by option
      dependent information for that option.

2.4.9.  VLAN Mapping (VMAP) sub-TLV

   The VLAN Mapping (VMAP) sub-TLV carries information concerning VLAN
   mappings configured at the originating IS.  VLAN mapping is used when
   an RBridge campus is divided into regions such that the same VLAN is
   represented by different VLAN IDs in different regions or there is a
   VLAN is one region that has no equivalent in another region.  Each
   port on each of the border RBridges between two or more regions MUST
   be configured as to which region each port connects with.  The
   numbering of regions is an arbitrary choice but all border RBridges
   in the campus MUST agree on the number of each region.

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

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Count |     From VLAN ID      |    (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          From Region          |    (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | RESV |      To VLAN ID        |    (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          To Region            |    (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   o  Length: variable, 8*N.

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

      *  Count: If this four bit unsigned integer is zero or 1, then the
         mapping of a single VLAN ID is being specified.  If it is any
         value from 2 through 15, then a block of that many contiguous
         VLAN IDs starting with the From VLAN ID is mapped to a block of
         that many contiguous VLAN IDs starting with the To VLAN ID.



Banerjee, et al.        Expires November 1, 2010               [Page 31]


Internet-Draft                Layer-2-IS-IS                   April 2010


      *  From VLAN ID: This is the VLAN ID that, when received on a port
         connect to the From Region on a frame being sent to the To
         Region, is mapped to the To VLAN ID.  This must be a real VLAN
         ID, that is, the values 0x000 and 0xFFF are prohibited and
         mappings in which they occur are ignored.

      *  From Region: This is 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 mapped as specified by the From VLAN ID and To VLAN ID
         fields.

      *  RESV: MUST be sent as zero and ignored on receipt.

      *  To VLAN ID: This is the VLAN ID to be used on frames sent out a
         port connected to the To Region if they were received on a port
         connected to the From Region with the From VLAN ID; except that
         if the To VLAN ID is 0x000 the frame is dropped.  The value
         invalid VLAN ID 0xFFF is prohibited in this field and if it
         occurs the mapping is ignored.

      *  To Region: This is the region number, within the campus, such
         that frames sent on a port connected to this region from a port
         connected to the From Region have their VLAN ID mapped as
         specified by the 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 entire routing
   domain.  This is different from Router Capability TLV defined in RFC
   4971, in the sense that 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                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Banerjee, et al.        Expires November 1, 2010               [Page 32]


Internet-Draft                Layer-2-IS-IS                   April 2010


   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  Reserved (3 bits): Must be sent as zero on transmission and is
      ignored on receipt.

   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.
      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-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 sub-TLV MUST be carried within the MT-Capability TLV in the
   fragment ZERO LSP.  If there was an additional SPB instance it MUST
   be declared under a separate MT-Topology and also carried in the
   fragment ZERO LSP.














Banerjee, et al.        Expires November 1, 2010               [Page 33]


Internet-Draft                Layer-2-IS-IS                   April 2010


+-+-+-+-+-+-+-+-+
|Type = SPB-Inst|
+-+-+-+-+-+-+-+-+
|   Length      |     (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               CIST Root Identifier  (4 bytes)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               CIST Root Identifier (cont)  (4 bytes)          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           CIST External ROOT Path Cost     (4 bytes)          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Bridge Priority        |         (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R|  SPS Flags  |V|              SPSOURCEID               | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of Trees  |       (1 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  VLAN-ID (1) Tuples    (8 bytes)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  VLAN-ID (N) Tuples    (8 bytes)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where VLAN-ID tuples have the format as:

   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
   +-+-+-+-+-+-+-+-+
   |U|M|A|  Res    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     ECT - Algorithm (32 bits)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Base VID (12 bits)    |   SPVID (12 bits)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

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

   o  CIST External Root Path Cost (32-bits) The CIST External Root Path
      Cost is the cost from the Spanning tree algorithm to the Root.

   o  Bridge Priority (16-bits) Bridge priority is the 16 bits that
      together with the low 6 bytes of the System ID form the Bridge
      Identifier.  The Bridge Identifier is the Spanning tree compatible



Banerjee, et al.        Expires November 1, 2010               [Page 34]


Internet-Draft                Layer-2-IS-IS                   April 2010


      Bridge identifier.  This 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 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 SPSourceID is auto
      allocated(27.11).  If the V bit is clear the SPSourceID has been
      configured and must be unique.  Allocation of SPSourceID is
      defined in [IEEE 802.1aq].  Bridges running SPBM will allocate an
      SPSourceID if they are not configured with an explicit SPSourceID.
      The V Bit allows neighbor bridges to determine if the auto
      allocation was enabled.  In the rare chance of a collision of
      SPsourceID the bridge with the highest priority Bridge Identifier
      will win conflicts and the lower priority Bridge will be re-
      allocated or if the lower priority Bridge is configured it will
      not be allowed to joint the SPT Region.

   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 [IEEE 802.1aq].

   o  Number of Trees (8-bits) The Number of Trees is be set to the
      number of [ECT-ALGORITHM, Base-VID plus flags] sub TLV's that
      follow.  Each ECT-ALGORITHM has a Base VID, an SPVID and some
      flags described below.  This must be set to at least one ECT.
      These define the standard ECTs.

   o  Each VID Tuple consists of:

      *  U-Bit (1-bit) The Use flag is set if this bridge is currently
         using this ECT-ALGORITHM for I-SIDs it sources or sinks.  This
         is a 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.  The VID allocation logic details are in [IEEE
         802.1aq].  Since SPVIDs are from a small pool of resources
         (1000 or less) the chances of collision are high.  To allow
         auto allocation LSPs are exchanged with the allocated bridge
         setting the SPVID to 0.





Banerjee, et al.        Expires November 1, 2010               [Page 35]


Internet-Draft                Layer-2-IS-IS                   April 2010


      *  ECT-ALGORITHM (4-bytes) ECT-ALGORITHM is 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 the same bridge.  The ECT-ALGORITHM, BASE-
         VID should match what is generated in the Hellos of the same
         node.  The ECT-ALGORITHM, BASE-VIDs pairs can come in any order
         however.

      *  Base VID (12-bits) The Base-VID that associated the SPT Set via
         the ECT-ALGORITHM.

      *  SPVID (12-bits) The SPVID is the Shortest Path VID when using
         SPBV mode.  It is not defined for SPBM Mode and should be 0 in
         SPBM mode.

2.5.2.  SPB Opaque ECT Algorithm sub-TLV

   There are multiple ECT algorithms defined for SPB, however for the
   future additional algorithms may be defined.  These algorithms would
   use this optional TLV to define new algorithm tie breaking data.
   There are two broad classes of algorithm, one which uses nodal data
   to break ties and one which uses link data to break ties, as a result
   this TLV can associate opaque data with a node or an adjacency or
   both.

   This sub-TLV SHOULD be carried within the MT-Capability TLV. (along
   with a valid SPB Instance sub-TLV (2.5.1)) and/or this sub-TLV SHOULD
   be carried within the Extended Reachability TLV (type 22).  Multiple
   copies of this sub-TLV may be carried for different ECT-ALGORITHMs
   both for a node and for an adjacency.

   +-+-+-+-+-+-+-+-+
   |Type = SPB-OALG|
   +-+-+-+-+-+-+-+-+
   |   Length      |     (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Opaque ECT Algorithm    (4 bytes)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Opaque ECT Information (variable)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: sub-TLV Type, set to SPB OALG sub-TLV 2 [TBD].

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

   o  ECT-ALGORITHM: ECT-ALGORITHM is advertised when the bridge
      supports a given ECT-ALGORITHM (by OUI/Index) on a given VID.




Banerjee, et al.        Expires November 1, 2010               [Page 36]


Internet-Draft                Layer-2-IS-IS                   April 2010


   o  ECT Information: ECT-ALGORITHM Information of variable length.

2.5.3.  SPBM Service Identifier and Unicast Address sub-TLV

   The SPBM Service Identifier and Unicast Address 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.

   +-+-+-+-+-+-+-+-+
   |Type = SPBM-SI |
   +-+-+-+-+-+-+-+-+
   |   Length      |     (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              B-MAC ADDRESS          (6 bytes)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Res. |    Base-VID           |  ( 2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |T|R| Reserved  |                  ISID  #1                     | (1+3 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |T|R| Reserved  |                  ISID  #2                     | (1+3 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |T|R| Reserved  |                  ISID  #n                     | (1+3 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: sub-TLV Type, set to SPBM Service Identifier and Unicast
      Address sub-TLV 3 [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
      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 sub-TLV, this sub-TLV



Banerjee, et al.        Expires November 1, 2010               [Page 37]


Internet-Draft                Layer-2-IS-IS                   April 2010


      can be repeated with the same B-MAC but with different ISID
      values.

   The SPBM Service Identifier sub-TLV SHOULD be carried within the MT-
   Capability TLV and can occur multiple times in any LSP fragment.

2.5.4.  The SPBV MAC Address sub-TLV

   The SPBV MAC Address (SPBV-MAC-ADDR) sub-TLV is IS-IS sub-TLV type 4
   and has the following format:

   +-+-+-+-+-+-+-+-+
   | Type=SPBV-ADDR|                  (1 byte)
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|R|S|R|       SPVID           |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |T|R| Reserved  |      MAC 1 Address              |  (1+6 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    ...                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |T|R| Reserved  |      MAC N Address              |  (1+6 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: sub-TLV Type, set to 4 (SPBV-MAC-ADDR).

   o  Length: Total number of bytes contained in the value field.  The
      number of MAC address associated with the SPVID is computed by
      (Length - 2)/7.

   o  SR bits (2-bits) The SR bits are the service requirement parameter
      from MMRP.  The service requirement parameters have the value 0
      (Forward all Groups) and 1 (Forward All Unregistered Groups)
      defined.  However this attribute may also be missing.  So the SR
      bits are defined as 0 not declared, 1 Forward all Groups and 2
      Forward All Unregistered Groups.  These bits have two Reserved
      bits set before them.

   o  SPVID (12-bits) The SPVID and by association Base VID and the ECT-
      ALGORITHM and SPT Set that the MAC addresses defined below will
      use.  If the SPVID is not allocated the SPVID Value is 0.  Note
      that if the ECT-Algorithm in use is Spanning Tree Algorithm this
      value should be populated with the Base VID and the MAC can be
      populated.

   o  T Bit (1-bit) This is the Transmit allowed Bit for the following
      group MAC address.  This is an indication that SPBV Group MAC



Banerjee, et al.        Expires November 1, 2010               [Page 38]


Internet-Draft                Layer-2-IS-IS                   April 2010


      Address with SPVID of source should be populated (for the bridge
      advertising this Group MAC), and installed in the FDB of transit
      bridges, when the bridge computing the trees is on the
      corresponding ECT-ALGORITHM shortest path between the bridge
      advertising this MAC with the 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 network.

   o  R Bit (1-bit) This is the Receive allowed Bit for the following
      Group MAC Address.  This is an indication that SPBV Group MAC
      Addresses as receiver should be populated (for bridges advertising
      this Group MAC Address with the T bit set) and installed when the
      bridge computing the trees lies on the 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 for a Group MAC Address is prevented from receiving on 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 MAC is address is either a group address
      or an individual address.  Individual addresses are optional and
      normal MAC learning can be used.  When the MAC address is a group
      address it declares this bridge as part of the multicast interest
      for this destination MAC address.  Multicast trees can be
      efficiently constructed for destination by populating multicast
      FDB entries for the subset of the shortest path tree that connects
      the bridges supporting the multicast address.  This replaces the
      function of MMRP for SPTs.  The T and R bits above have meaning if
      this is a group address.  Individual addresses are populated only
      as if the R bit was not set.

   The SPBV-MAC-ADDR sub-TLV SHOULD be carried within the MT-Capability
   TLV and can occur multiple times in any LSP fragment.

2.6.  Sub-TLVs of the Extended Reachability TLV

   This section specifies three new sub-TLVs that appear only within the
   Extended Reachability TLV (type 22).

2.6.1.  SPB Link Metric sub-TLV

   The SPB Link Metric sub-TLV occurs 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.



Banerjee, et al.        Expires November 1, 2010               [Page 39]


Internet-Draft                Layer-2-IS-IS                   April 2010


   +-+-+-+-+-+-+-+-+
   |Type=SPB-Metric|
   +-+-+-+-+-+-+-+-+
   |   Length      |     (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       SPB-LINK-METRIC                         |   (3 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Num of ports    |     (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Port  Identifier          |   ( 2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: sub-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.

   o  an opaque ECT Data sub-TLV (type TBD) whose first 32 bits are the
      ECT-ALGORITHM to which this data applies.

2.6.2.  SPB Opaque ECT Algorithm sub-TLV

   This sub-TLV is identical in format and type as the 2.5.2 SPB Opaque
   ECT Algorithm sub-TLV and carries future opaque data for the purpose
   of extending ECT behavior.  Multiple copies of the sub-TLV may occur
   for different ECT-ALGORITHMs.

2.6.3.  MTU sub-TLV

   The MTU sub-TLV is used to optionally announce the MTU of a link.  It
   occurs nested as within the Extended Reachability TLV (type 22).









Banerjee, et al.        Expires November 1, 2010               [Page 40]


Internet-Draft                Layer-2-IS-IS                   April 2010


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

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

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

   o  F: Failed.  This bit is a one if MTU testing on this link failed
      at the required campus-wide MTU.

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

2.7.  TRILL Neighbor TLV

   The TRILL Neighbor TLV is used in the TRILL-Hello PDU in place of the
   IS Neighbor TLV.  It differs in that MTU information is provided per
   neighbor and provision is made for fragmentation, so that not all
   neighbors need be reported in each TRILL-Hello, to support the hard
   limit on the size of TRILL-Hellos.  This TLV can occur zero, one, or
   multiple times in a TRILL-Hello PDU.  The structure of the TRILL
   Neighbor TLV is as follows:

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

   The list of neighbors MUST be ordered by MAC address, considering
   each 6-byte MAC address to be an unsigned integer, starting with the
   smallest.  The information present for each neighbor is as follows:




Banerjee, et al.        Expires November 1, 2010               [Page 41]


Internet-Draft                Layer-2-IS-IS                   April 2010


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

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

   o  Length: Total number of bytes contained in the value field, 2 +
      10*n, where n is the number of neighbor records.

   o  S: smallest flag.  If this bit is a one, then the list of
      neighbors includes the neighbor with the smallest MAC address.

   o  L: largest flag.  If this bit is a one, then the list of neighbors
      includes the neighbor with the largest MAC address.

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

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

   o  MTU: This field is set to the largest successfully tested MTU size
      for this neighbor or zero if it has not been tested.

   o  MAC Address: The MAC address of the neighbor as in 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
   has the following format:

   +-+-+-+-+-+-+-+-+
   |  Type = GMAS  |                  (1 byte)
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   sub-TLVs   (variable bytes) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: TLV Type, set to GMAS-TLV 146 [TBD].

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



Banerjee, et al.        Expires November 1, 2010               [Page 42]


Internet-Draft                Layer-2-IS-IS                   April 2010


   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 the following subsections.

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

2.8.1.  The Group MAC Active Source sub-TLV

   The Group MAC Source (GMAS-MAC) sub-TLV is IS-IS sub-TLV type 1
   within the GMAS TLV.  It is used in OTV [OTV] to create multicast
   distribution trees and has the following format:

   +-+-+-+-+-+-+-+-+
   | Type=GMAS-MAC |                 (1 byte)
   +-+-+-+-+-+-+-+-+
   |   Length      |                 (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |G|S| R |         Vlan ID       |  (2 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Address family              |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Length      |                 (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Delivery group  (afi scoped number of bytes) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Delivery Source (afi scoped number of bytes) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Num Group Recs |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   GROUP RECORDS (1)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   .................                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   GROUP RECORDS (N)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where each group record is of the form:













Banerjee, et al.        Expires November 1, 2010               [Page 43]


Internet-Draft                Layer-2-IS-IS                   April 2010


   +-+-+-+-+-+-+-+-+
   |    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 (GMAS-MAC) of length 1 byte.

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

   o  G (1 bit): Delivery Group is set

   o  S (1 bit): Delivery Source is set

   o  RESERVED (2 bits) : 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 sub-TLV, or the value zero if
      no VLAN is specified.

   o  Address Family: Describes the Address family of the Delivery
      Source/Group information.

   o  Length: Gives the length of the Delivery Source and Delivery Group
      field.

   o  Delivery Group: Describes the group used to deliver packets.

   o  Delivery Source: Describes the source address used to deliver
      packets.

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

   o  Group Record: Each group record has a one byte reserved space and
      the next byte carries the number of sources.  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



Banerjee, et al.        Expires November 1, 2010               [Page 44]


Internet-Draft                Layer-2-IS-IS                   April 2010


      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 in another sub-TLV of another instance of the
      Group Active Source TLV.

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

2.8.2.  The Group IP Active Source sub-TLV

   The Group IP Address (GMAS-IP) sub-TLV is IS-IS TLV type 2.  It is
   used in OTV [OTV] to create multicast distribution trees and has the
   following format:

   +-+-+-+-+-+-+-+-+
   | Type=GMAS-IP  |                 (1 byte)
   +-+-+-+-+-+-+-+-+
   |   Length      |                 (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |G|S| R |         Vlan ID       |  (2 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Address family              |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Length      |                 (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Delivery group  (afi scoped number of bytes) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Delivery Source (afi scoped number of bytes) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Num Group Recs |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   GROUP RECORDS (1)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   .................                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   GROUP RECORDS (N)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where each group record is of the form:












Banerjee, et al.        Expires November 1, 2010               [Page 45]


Internet-Draft                Layer-2-IS-IS                   April 2010


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

   o  G (1 bit): Delivery Group is set

   o  S (1 bit): Delivery Source is set

   o  RESERVED (2 bits) : 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 sub-TLV, or the value zero if
      no VLAN is specified.

   o  Address Family: Describes the Address family of the Delivery
      Source/Group information.

   o  Length: Gives the length of the Delivery Source and Delivery Group
      field.

   o  Delivery Group: Describes the group used to deliver packets.

   o  Delivery Source: Describes the source address used to deliver
      packets.

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

   o  Group Record: Each group record has a one byte reserved space and
      the next byte carries the number of sources.  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-



Banerjee, et al.        Expires November 1, 2010               [Page 46]


Internet-Draft                Layer-2-IS-IS                   April 2010


      TLV, it is permitted to have the same group address repeated with
      different source addresses repeated in another sub-TLV of another
      instance of the Group Active Source TLV.

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

2.8.3.  The Group IPv6 Active Source sub-TLV

   The Group IPv6 Active Source (GMAS-IPv6) sub-TLV is IS-IS sub-TLV
   type 3.  It is used in OTV [OTV] to create multicast distribution
   trees and has the following format:

   +-+-+-+-+-+-+-+-+
   | Type=GMAS-IP  |                 (1 byte)
   +-+-+-+-+-+-+-+-+
   |   Length      |                 (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |G|S| R |         Vlan ID       |  (2 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Address family              |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Length      |                 (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Delivery group  (afi scoped number of bytes) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Delivery Source (afi scoped number of bytes) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Num Group Recs |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   GROUP RECORDS (1)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   .................                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   GROUP RECORDS (N)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where each group record is of the form:













Banerjee, et al.        Expires November 1, 2010               [Page 47]


Internet-Draft                Layer-2-IS-IS                   April 2010


   +-+-+-+-+-+-+-+-+
   |    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  G (1 bit): Delivery Group is set

   o  S (1 bit): Delivery Source is set

   o  RESERVED (2 bits) : 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 sub-TLV, or the value zero if
      no VLAN is specified.

   o  Address Family: Describes the Address family of the Delivery
      Source/Group information.

   o  Length: Gives the length of the Delivery Source and Delivery Group
      field.

   o  Delivery Group: Describes the group used to deliver packets.

   o  Delivery Source: Describes the source address used to deliver
      packets.

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

   o  Group Record: Each group record has a one byte reserved space and
      the next byte carries the number of sources.  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



Banerjee, et al.        Expires November 1, 2010               [Page 48]


Internet-Draft                Layer-2-IS-IS                   April 2010


      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 and MUST be
   carried in a standard Level 1 link state MGROUP PDU.

2.9.  PDU Extensions to IS-IS

2.9.1.  The Multicast Group PDU

   The systems that this document is concerned with want to carry not
   only layer-2 unicast information in the link state protocols, but
   also multicast information.  This 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 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 sub-TLVs.  Furthermore, it MAY carry the
   interested vlan sub-TLV of the Capability TLV.

   One or more TLVs MAY be carried in a single MGROUP PDU.  Future



Banerjee, et al.        Expires November 1, 2010               [Page 49]


Internet-Draft                Layer-2-IS-IS                   April 2010


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

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

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

2.9.4.  MGROUP PDU related changes to Base protocol

   In this section, we describe the changes to the base protocol due to
   the introduction of the MGROUP, MGROUP-PSNP, MGROUP-CNSP PDUs.

2.9.4.1.  Enhancements to the flooding process

   This document specifies 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.  There need not be any more correlation between the
   updates of the regular PDU and the MGROUP-PDU.

   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.




Banerjee, et al.        Expires November 1, 2010               [Page 50]


Internet-Draft                Layer-2-IS-IS                   April 2010


   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.

2.9.4.2.  Enhancements to Graceful Restart

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

2.9.4.4.  Enhancements to the SPF

   The MGROUP-PDU advertises a set of attached, or joined, multicast
   groups.  These groups act as leaves of the advertising nodes.  As a
   result, there are no new requirements of running a SPF if only
   information within the MGROUP-PDU changes.

2.9.5.  The TRILL-Hello PDU

   A different Hello PDU is required for TRILL links because it is
   necessary that a single Designated RBridge (DIS) be 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 basis as layer 3 Intermediate Systems report
   reachability, that is, if and only if two-way connectivity exists.

   The TRILL-Hello PDU has the same general structure as an IS-IS LAN
   PDU.  An RBridge (an Intermediate System supporting TRILL) sends this
   PDU, with the same timing as the IS-IS LAN Hello PDU.  More
   specifically, in a TRILL-Hello PDU the IS-IS Common Header and 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 Section 5.  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 link MTU.
   For example, for an 802.3 Ethernet link, the MTU SHOULD be assumed to



Banerjee, et al.        Expires November 1, 2010               [Page 51]


Internet-Draft                Layer-2-IS-IS                   April 2010


   be 1512 bytes for the purpose of determining the maximum size of
   TRILL-Hello PDUs on that link.  Thus, for such a link, TRILL-Hellos
   MUST NOT exceed 1470 bytes.

   The following MUST appear in every TRILL-Hello PDU: a 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
   TRILL Neighbor TLV specified in Section 2.7 and the following sub-
   TLVs specified in Section 2.3: Enabled VLANs sub-TLV, Appointed
   Forwarders sub-TLV, and Hop-by-Hop Options sub-TLV.

   The Padding TLV (#8) SHOULD NOT appear in a TRILL-Hello.

   The IS-IS Neighbor TLV (#6) MUST NOT appear in a TRILL-Hello.
   Instead, it uses the TRILL Neighbor TLV (see Section 2.7).

2.9.6.  The MTU PDU

   The MTU-probe and MTU-ack PDUs are used to determine the MTU on a
   link between intermediate systems.  An MTU-probe MUST be padded to
   the size being tested with the Padding TLV (#8).  The ability to 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 that MTU-
   ack MUST be padded to the size of the MTU-probe.

   The MTU PDUs have the standard IS-IS common header with two new PDU
   Type numbers, one each, as listed in Section 5.  They also have a 20-
   byte common fixed MTU PDU header as shown below.

      +------------+
      | PDU Length |  (2 bytes)
      +------------+-------------------------+
      |   Probe ID                           |  (6 bytes)
      +--------------------------------------+
      |   Probe Source ID                    |  (6 bytes)
      +--------------------------------------+
      |   Ack Source ID                      |  (6 bytes)
      +--------------------------------------+

   As with other IS-IS PDUs, the PDU length contains length of the
   entire IS-IS packet starting with and including the IS-IS common
   header.

   The Probe ID field is an arbitrary 48-bit quantity set by the
   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 quantity from a port



Banerjee, et al.        Expires November 1, 2010               [Page 52]


Internet-Draft                Layer-2-IS-IS                   April 2010


   identifier and probe sequence number relative to that port.

   The Probe Source ID is set by an Intermediate system issuing an MTU-
   probe to its System ID and copied by the responding system into the
   corresponding MTU-ack.

   The Ack Source ID is 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 MUST be padded to the size being tested
   with the Padding TLV.







































Banerjee, et al.        Expires November 1, 2010               [Page 53]


Internet-Draft                Layer-2-IS-IS                   April 2010


3.  Acknowledgements

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















































Banerjee, et al.        Expires November 1, 2010               [Page 54]


Internet-Draft                Layer-2-IS-IS                   April 2010


4.  Security Considerations

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















































Banerjee, et al.        Expires November 1, 2010               [Page 55]


Internet-Draft                Layer-2-IS-IS                   April 2010


5.  IANA Considerations

   This document creates six new PDU types, namely the MGROUP PDU,
   MGROUP-CSNP PDU, the MGROUP-PSNP 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.

      MGROUP-PDU        Level-1 PDU Type: 19
      MGROUP-CSNP-PDU   Level-1 PDU Type: 22
      MGROUP-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 specifies the definition of a set of new IS-IS TLVs,
   the MAC-Reachability TLV (type 141), the Group Address TLV (type
   142), the 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 need to be reflected in the IS-IS TLV
   code-point registry.

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

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

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

MT-Port-Cap-TLV (143)                  X    -    -    -     -    T/I/O
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.HBHOPT          sub-TLV   4    X    -    -    -     -    T/-/-
PortCap.BaseVLANID      sub-TLV   5    X    -    -    -     -    -/I/-
PortCap.SPBDigest       sub-TLV   6    X    -    -    -     -    -/I/-
PortCap.SiteIdentifier  sub-TLV 250    X    -    -    -     -    -/-/O
PortCap.SiteGroupIP     sub-TLV 251    X    -    -    -     -    -/-/O
PortCap.SiteGroupIPv6   sub-TLV 252    X    -    -    -     -    -/-/O
PortCap.AdjServerIP     sub-TLV 253    X    -    -    -     -    -/-/O
PortCap.AdjServerIPv6   sub-TLV 254    X    -    -    -     -    -/-/O



Banerjee, et al.        Expires November 1, 2010               [Page 56]


Internet-Draft                Layer-2-IS-IS                   April 2010


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

MT-Capability-TLV (144)                -    X    -    -     -    -/I/-
MT-Cap.SPB Instance      sub-TLV  1    -    X    -    -     -    -/I/-
MT-Cap.Opaque Algorithm  sub-TLV  2    -    X    -    -     -    -/I/-
MT-Cap.Service Id.       sub-TLV  3    -    X    -    -     -    -/I/-
MT-Cap.SPBV-MAC-ADDR     sub-TLV  4    -    X    -    -     -    -/I/-

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

EXT-IS.SPB Link Metric   sub-TLV  5    -    X    -    -     -    -/I/-
EXT-IS.MTU               sub-TLV  6    -    X    -    -     -    T/-/-

MT-EXT-IS.SPB LinkMetric sub-TLV  5    -    X    -    -     -    -/I/-

Group Mem Active Source TLV (146)      -    -    -    X     -    -/-/O
GMAS-TLV.GMAS-MAC      sub-TLV  1      -    -    -    X     -    -/-/O
GMAS-TLV.GMAS-IP       sub-TLV  2      -    -    -    X     -    -/-/O
GMAS-TLV.GMAS-IPV6     sub-TLV  3      -    -    -    X     -    -/-/O

   IANA SHOULD manage the remaining space using the IETF Review method
   [RFC 5226].





















Banerjee, et al.        Expires November 1, 2010               [Page 57]


Internet-Draft                Layer-2-IS-IS                   April 2010


6.  References

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

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

   [OTV]      Grover, H., Farinacci, D., and D. Rao, "OTV: Overlay
              Transport Virtualization", draft-hasmit-otv-00, 2010.

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

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









Banerjee, et al.        Expires November 1, 2010               [Page 58]


Internet-Draft                Layer-2-IS-IS                   April 2010


Authors' Addresses

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

   Email: ayabaner@cisco.com


   David Ward
   Juniper Networks
   1194 N. Mathilda Ave.
   Sunnyvale, CA  94089-1206
   USA

   Phone: +1-408-745-2000
   Email: 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
   Intel Labs
   2200 Mission College Blvd.
   Santa Clara, CA  95054
   US

   Phone: +1-408-765-8080
   Email: Radia.Perlman@alum.mit.edu




Banerjee, et al.        Expires November 1, 2010               [Page 59]


Internet-Draft                Layer-2-IS-IS                   April 2010


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

   Phone: +1-508-333-2270
   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

























Banerjee, et al.        Expires November 1, 2010               [Page 60]


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