Network Working Group                                   A. Banerjee, Ed.
Internet-Draft                                             Cisco Systems
Expires: September 3, 2009                                 March 2, 2009


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

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

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

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

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

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

   This Internet-Draft will expire on September 3, 2009.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of



Banerjee, et al.        Expires September 3, 2009               [Page 1]


Internet-Draft                Layer-2-IS-IS                   March 2009


   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

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


1.  Overview

   There are a number of systems (for example, [RBRIDGES]) which have
   proposed using layer 2 addresses carried in a link state routing
   protocol, specifically IS-IS [IS-IS] [RFC1195], to provide true layer
   2 routing in specific environments.  This draft proposes a set of
   TLVs and sub-TLVs to be added to [IS-IS] level 1 PDUs, and three new
   PDU types, to support these proposed systems.

   This draft does not propose new forwarding mechanisms using this
   additional information carried within IS-IS.  There is a short
   section included on two possible ways to build a shortest path first
   tree including this information, to illustrate how this information
   might be used.


2.  Proposed Enhancements to IS-IS

   This draft proposes additional TLVs, to carry unicast and multicast
   attached address information.  It also proposes additional sub-tlvs
   to carry information regarding building trees for Layer 2 networks.
   This draft proposes 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.

2.1.  The MAC-Reachability TLV

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




Banerjee, et al.        Expires September 3, 2009               [Page 2]


Internet-Draft                Layer-2-IS-IS                   March 2009


    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= MAC-RI  | Length        |              Vlan-Id          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             MAC (1)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            MAC (1)            |             MAC (2)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             MAC (2)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       .................                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             MAC (N)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: TLV Type, set to 141 (MAC-RI).
   o  Length: Total number of octets contained in the TLV.
   o  Vlan-id: This carries a 16 bit VLAN identifier that is valid for
      all subsequent MAC addresses in this TLV.
   o  MAC(i): This is the 48-bit MAC address reachable from the IS that
      is announcing this TLV.

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

2.2.  The Group Address TLV

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

   o  Type: TLV Type, set to GADDR-TLV 142 [TBD].
   o  Length: Total number of octets contained in the TLV, including the
      length of the sub-tlvs carried in this TLV.
   o  sub-tlvs: The following sub-TLVs are defined.

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

2.2.1.  The Group MAC Address sub-TLV

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



Banerjee, et al.        Expires September 3, 2009               [Page 3]


Internet-Draft                Layer-2-IS-IS                   March 2009


   +-+-+-+-+-+-+-+-+
   | Type=GMAC-ADDR|                  (1 byte)
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Vlan-Id          |  (2 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |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: TLV Type, set to 1 (GMAC-ADDR) of length 1 byte.
   o  Length: Total number of octets contained in the TLV.
   o  Vlan-id: This carries a 16 bit VLAN identifier that is valid for
      all subsequent MAC addresses in this TLV.
   o  Number of Group Records: This is of length 1 byte and lists the
      number of group records in this TLV.
   o  Group Record: Each group record has a reserved space and followed
      by the number of sources, each of length 1 byte.  It then has a
      48-bit multicast Group Address followed by 48-bit source MAC
      addresses.  An address being a group multicast address or unicast
      source address can be checked using the multicast bit in the
      address.

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




Banerjee, et al.        Expires September 3, 2009               [Page 4]


Internet-Draft                Layer-2-IS-IS                   March 2009


2.2.2.  The Group IP Address sub-TLV

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

   +-+-+-+-+-+-+-+-+
   | Type=GIP-ADDR |
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Vlan-Id          |  (2 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |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: TLV Type, set to 2 (GIP-ADDR).
   o  Length: Total number of octets contained in the TLV.
   o  Vlan-id: This carries a 16 bit VLAN identifier that is valid for
      all subsequent IPv4 source or group addresses in this TLV.
   o  Number of Group Records: This is of length 1 byte and lists the
      number of group records in this TLV.
   o  Group Record: Each group record has a reserved space and followed
      by the number of sources, each of length 1 byte.  It is followed
      by a 32-bit IPv4 Group Address followed by 32-bit source IPv4
      addresses.




Banerjee, et al.        Expires September 3, 2009               [Page 5]


Internet-Draft                Layer-2-IS-IS                   March 2009


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

2.2.3.  The Group IPv6 Address sub-TLV

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

   +-+-+-+-+-+-+-+-+
   |Type=GIPv6-ADDR|
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Vlan-Id          |  (2 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |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: TLV Type, set to 3 (GIPV6-ADDR).
   o  Length: Total number of octets contained in the TLV.
   o  Vlan-id: This carries a 16 bit VLAN identifier that is valid for
      all subsequent IPv6 source or group addresses in this TLV.
   o  Number of Group Records: This of length 1 byte and lists the
      number of group records in this TLV.





Banerjee, et al.        Expires September 3, 2009               [Page 6]


Internet-Draft                Layer-2-IS-IS                   March 2009


   o  Group Record: Each group record has a reserved space and followed
      by the number of sources, each of length 1 byte.  It is followed
      by a 128-bit multicast IPv6 Group Address followed by 128-bit
      source IPv6 addresses.

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

2.3.  Link Capability TLV

   The Link Capability (LINK-CAP) is an optional IS-IS TLV type 143
   [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=LINKCAPTLV| Length        |              sub-tlvs         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: TLV Type, set to LINK-CAP TLV 143 [TBD].
   o  Length: Total number of octets contained in the TLV, including the
      length of the sub-tlvs carried in this TLV.
   o  sub-tlvs: The following sub-TLVs are defined.

   The LINK-CAP-TLV is carried within a LAN IIH PDU, or within a P2P IIH
   PDU.

2.3.1.  The Special VLANs and Flags sub-TLV

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

   o  Type: TLV Type, set to VLAN &amp Flags sub-TLV 1 [TBD].
   o  Length: 4 - Number of octets contained in the TLV.
   o  The first and second octets have a copy of the Outer VLAN ID
      associated with the Hello frame when it was sent.  The lower 4
      bits of the first octet give the upper ID bits of the VLAN ID and
      the second octet gives the lower VLAN ID bits.
   o  The upper 4 bits of the first octet are flag bits as shown.  The
      AF bit, if one, indicates that the sending RBridge believes it is
      Appointed Forwarder for the VLAN and port on which the Hellos was
      sent.  The AC bit, if one, indicates that the sending port is
      configured as an access port.  The VM flag, if a one, indicates



Banerjee, et al.        Expires September 3, 2009               [Page 7]


Internet-Draft                Layer-2-IS-IS                   March 2009


      that the sending RBridge has detected VLAN mapping within the
      link.  The R bit is reserved and MUST be sent as zero and ignored
      on receipt.
   o  The third and forth octets give the Designated VLAN for the link.
      The lower 4 bits of the third octet give the upper ID bits of the
      Designated VLAN and the forth octet gives the lower VLAN ID bits.
      The upper 4 bits of the third octet are reserved and MUST be sent
      as zero and ignored on receipt.

   The VLAN & Flags sub-TLV is carried within the LINK-CAP TLV and MUST
   be carried in 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.

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

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

   The Enabled VLAN sub-TLV is carried within the LINK-CAP TLV and MUST
   be carried in IIH PDU.

2.3.3.  Appointed Forwarders sub-TLV

   The Appointed Forwarder sub-TLV provides the mechanism by which the
   DRB can inform other RBridges on the link that they are the
   designated VLAN-x forwarder for that link for one or more ranges of



Banerjee, et al.        Expires September 3, 2009               [Page 8]


Internet-Draft                Layer-2-IS-IS                   March 2009


   VLAN IDs.

   o  Type: TLV Type, set to Enabled VLANs sub-TLV 3 [TBD].
   o  Length: The size of the value is 6*n octets where there are n
      appointments.  Each 6 octet part of the value is formatted as
      follows:

   +----------------+-----+-----+---------+-----+----+---------+
   |  octet 1 - 2   |  octet 3  | octet 4 |  octet 5 | octet 6 |
   +----------------+-----+-----+---------+-----+----+---------+
   | Appointee Nick | Res | Start VLAN ID | Res | End VLAN ID  |
   +----------------+-----+-----+---------+-----+----+---------+
   o  The appointed forwarder RBridge is specified by its nickname in
      the first two octets.
   o  The "Res" fields of 4 bits each are reserved and MUST be sent as
      zero and ignored on reciept.

   The VLAN range given is inclusive.  To specify a single VLAN, that
   VLAN ID appears as both the start and end VLAN.  The RBridge 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 RBridge 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-octet value sequence with start and end
   VLAN IDs of 100 and 200, or (2) a 12-octet 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 RBridge's nickname may occur as appointed forwarder for multiple
   VLAN ranges within the same or different Link Capability TLVs within
   a DRB's Hello.  In the absence of appointed forwarder subTLVs
   referring to a VLAN, the DRB acts as the appointed forwarder for that
   VLAN if end station service is enabled.

   The Appointed Forwarder sub-TLV is carried within the LINK-CAP TLV
   and MUST be carried in IIH PDU.

2.4.  Sub-TLVs for the Capability TLV

   The Capability TLV is an optional TLV [RFC 4971] that may be
   generated by the originating IS.  We introduce these additional sub-
   TLVs that are carried within it.  These sub-tlvs announce the
   capabilities of the router for the entire IS-IS routing domain.






Banerjee, et al.        Expires September 3, 2009               [Page 9]


Internet-Draft                Layer-2-IS-IS                   March 2009


2.4.1.  The TRILL Version sub-TLV

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

   o  Type: TLV Type, set to 5 (TRILL-VER).
   o  Length: 2 - Total number of octets contained in the TLV.
   o  Reserved: Set to 0.
   o  Max-version: Set to application dependent values.

2.4.2.  The Device ID sub-TLV

   The Device ID (DEVID) sub-TLV carries information about the identity
   of the advertising device, along with information about device
   priority.  The Device-Id sub-TLV MUST be carried within the
   CAPABILITY TLV in a level-1 non-pseudo-node LSP generated by the
   originating IS.
    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   |    Priority   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Reserved             |          Device Id            |
   +---------------------------------------------------------------+

   o  Type: TLV Type, set to 6 (DEVID).
   o  Length: Total number of octets contained in the TLV.
   o  Reserved: Set to 0.
   o  Priority: Set to application dependent values.
   o  Device ID: Left padded device ID or alias.

2.4.3.  The Root Priority sub-TLV

   The Root Priority sub-TLV MUST be carried within the CAPABILITY TLV
   in a level-1 non-pseudo-node LSP generated by the originating IS.
   Each device announces a broadcast root-priority and the number of
   trees it expects all other nodes to compute if it does become the
   broadcast root.  Once a node receives a new LSP, it runs an election
   algorithm, independently of the other nodes in the network, to
   determine the broadcast root.  The node that announced the lowest



Banerjee, et al.        Expires September 3, 2009              [Page 10]


Internet-Draft                Layer-2-IS-IS                   March 2009


   broadcast priority becomes the root of the broadcast tree.  If two
   devices advertise the same broadcast priority, the device with the
   lower system ID becomes the root of the broadcast tree.  The elected
   broadcast-root decides on the multicast-roots to be used in the
   network domain and their roots.  This announcement takes place in the
   roots identifier sub-TLV.

   +-+-+-+-+-+-+-+-+
   |Type = ROOT-PRI|
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Broadcast Root Pri        |  (2 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Num of multi-destination trees |  (2 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: TLV Type, set to 7 (ROOT-PRI).
   o  Length: Total number of octets contained in the TLV.
   o  Br Root Pri: This gives the value of the priority with which this
      node wants to be the broadcast root node in the Layer-2 domain.
   o  Num of multi-destination trees: This gives the number of
      distribution trees for multi-destination frames that will be in
      use in the Layer-2 domain, excluding the broadcast tree rooted at
      itself, if this device becomes the broadcast root in the domain.

2.4.4.  The Root Identifier Sub-tlv

   The root identifier sub-tlv is populated by the root of the broadcast
   tree.  If this is also announced by other nodes in the network, it
   implies that the specific node that is advertising it will only
   restrict traffic to the common set of the trees in its announcement
   and the ones announced by the broadcast root.  It is carried within
   the CAPABILITY TLV in a level-1 non-pseudo-node LSP and is given as:

















Banerjee, et al.        Expires September 3, 2009              [Page 11]


Internet-Draft                Layer-2-IS-IS                   March 2009


    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= ROOT-IDs | Length        |           RESERVED            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Multi-destination Tree Num   | Broadcast Root System  Id...  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              ... Broadcast Root System  Id                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Multi-destination Tree Num   | Multicast Root System Id  ... |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               ... Multicast Root System  Id                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               ...                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: TLV Type, set to 8 (ROOT-IDs).
   o  Length: Total number of octets contained in the TLV.
   o  Multi-destination Tree Num: This identifies the trees being used
      by the specific nodes.
   o  Broadcast Root System Id: The Broadcast Root System ID at which a
      broadcast tree is rooted.  It is of length 6 bytes.
   o  Multicast Root System Id: The Multicast Root System ID at which a
      multicast tree is rooted.  It is of length 6 bytes.
   A locally significant hash is used by edge devices to determine which
   multicast root (or set of multicast roots) is used to send traffic
   for a specific multicast group.  If there is a discrepancy between
   the number of multi-destination trees the broadcast-root has
   announced, and the number of roots the root-identifier sub-tlv
   carries, nodes MUST compute trees on the additional roots.

2.4.5.  Interested Vlans and Spanning Tree Roots sub-TLV

   The value of this subTLV consists of a VLAN range, flags, and a
   variable length list of spanning tree root bridge IDs.  This subTLV
   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 RBridge is appointed forwarder on at least one port and
   the VLAN ranges in multiple VLANs subTLVs for an RBridge MUST NOT
   overlap.  That is, the intersection of the VLAN ranges for any pair
   of these subTLVs originated by an RBridge must be null.  The value
   length is 4 + 6*n where n is the number of root bridge IDs.The
   initial 4 octets of value are as follows:








Banerjee, et al.        Expires September 3, 2009              [Page 12]


Internet-Draft                Layer-2-IS-IS                   March 2009


   +-+-+-+-+-+-+-+-+
   |Type = INT-VLAN|
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Interested VLANS           |  (4 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Multi-destination tree roots  |  (6*n bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: TLV Type, set to 9 (INT-VLAN).
   o  Length: Total number of octets contained in the TLV.
   o  Interested VLANS: The M4 bit indicates that there is an IPv4
      multicast router on a link for which the originating RBridge is
      appointed forwarder for every VLAN in the indicated range.  The M6
      bit indicates the same for an IPv6 multicast router.  The OM bit
      indicates that this RBridge requests that all non-IP derived
      multicast traffic in the indicated VLAN range be sent to it.  The
      R and Reserved bits MUST be sent as zero and are ignored on
      receipt.  The VLAN start and end IDs are inclusive.  A range of
      one VLAN ID is indicated by setting them both to that VLAN ID
      value.  It has the following format:
     0    1    2    3     4 - 15      16 - 19     20 - 31
   +----+----+----+----+------------+----------+------------+
   | AF | AC | VM |  R | Outer.VLAN | Reserved | Desig.VLAN |
   +----+----+----+----+------------+----------+------------+
   o  Multi-destination tree roots: 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 RBridge is appointed forwarder for the VLANs
      in the range.  This information is learned from BPDUs heard by the
      RBridge.  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 RBridge
      is appointed forwarder (for example all such links are point-to-
      point links to other RBridges 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, M6, or OM bits are different, the subTLV is incorrect and
   must be split into multiple subTLVs each indicating only VLANs with
   the same M4, M6, and OM 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 RBridge is appointed forwarder for the VLAN are not the



Banerjee, et al.        Expires September 3, 2009              [Page 13]


Internet-Draft                Layer-2-IS-IS                   March 2009


   same, the subTLV is incorrect and must be split into multiple subTLVs
   each indicating only VLANs with the same set of DRB seen root bridge
   IDs.  It is always safe to use subTLVs with a "range" of one VLAN ID
   but this may be too verbose.

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

2.4.6.  The Vlan Group Sub-tlv

   The Vlan Group sub-tlv consists of two or more 16-bit fields each of
   which has a VLAN ID in the low order 12 bits.  The top 4 bits MUST be
   sent as zero and ignored on receipt.  The first such VLAN ID is the
   primary, or may be zero if there is no primary.  It is carried within
   the CAPABILITY TLV in a level-1 non-pseudo-node LSP and is given as:
    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=VLAN-GROUP| Length        |           RESERVED            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Primary Vlan-Id        |        Secondary Vlan  Id     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               ...                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: TLV Type, set to 10 (VLAN-GROUPs).
   o  Length: Total number of octets contained in the TLV.
   o  Primary Vlan-id: This identifies the primary Vlan-id.
   o  Secondary Vlan-id: This identifies the secondary Vlan-id, address
      learning is shared at the Rbridge that announces this sub-tlv.
   This sub-tlv may appear zero, one, or multiple times.


3.  The Multicast Group PDU

   The systems that this draft is concerned with want to carry not only
   layer-2 unicast information in the link state protocols, but also
   multicast information.  This draft has defined a new Multicast Group
   (MGROUP) PDU that can be used to advertise a set of attached, or
   joined, multicast groups.  Accordingly, it has also introduced a
   couple more PDUs as described in the next sections for the flooding
   and update process to work seamlessly.

   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



Banerjee, et al.        Expires September 3, 2009              [Page 14]


Internet-Draft                Layer-2-IS-IS                   March 2009


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

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

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

3.1.  The Multicast Group Partial Sequence Number PDU

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

3.2.  The Multicast Group Complete Sequence Number PDU

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

3.3.  Enhancements to the flooding process

   This draft proposes that the information contained in the MGROUP-PDU
   is in a parallel database and its update mechanisms mimic that of the
   regular database.  Nodes running IS-IS in an L2 domain MUST support
   these additional MGROUP PDUs defined in this draft.  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



Banerjee, et al.        Expires September 3, 2009              [Page 15]


Internet-Draft                Layer-2-IS-IS                   March 2009


   LSP, PSNP, and CSNP PDUs.

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

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

   In general, the database synchronization is performed in parallel
   with no interactions between the messages.  However, the initial
   triggers that start a CSNP exchange are correlated, in the sense it
   also triggers a MGROUP-CSNP exchange.  For example, during graceful
   restart [RFC 3847], a parallel MGROUP-CSNP and MGROUP-PSNP exchange
   and update process will be run for the MGROUP-PDUs and restart
   process completes after both databases have been received.


4.  Considerations for Using L2 Information in IS-IS

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

4.1.  Building SPF Trees with Layer 2 Information

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

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

4.2.  Designated Intermediate Routers

   A single DIS SHOULD be elected as described in [IS-IS] for each layer
   2 broadcast domain (VLAN) for which information is being carried in
   IS-IS.  This reduces the amount of work required to flood and



Banerjee, et al.        Expires September 3, 2009              [Page 16]


Internet-Draft                Layer-2-IS-IS                   March 2009


   maintain synchronized databases over the underlying media on which
   IS-IS is running and providing layer 2 forwarding information for.


5.  Acknowledgements

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


6.  Security Considerations

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


7.  IANA Considerations

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

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

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

   This document creates a number of new sub-TLV in the numbering space
   for the Group Address TLV, the Link Capability TLV, and the
   Capability TLV.  The TLV and sub-TLVs are given below:

















Banerjee, et al.        Expires September 3, 2009              [Page 17]


Internet-Draft                Layer-2-IS-IS                   March 2009


                                             IIH  LSP  SNP MCAST MCAST
                                                            LSP   SNP
      MAC-RI TLV  (141)                       -    X    -    -     -

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

      Link-Cap-TLV (143)                      X    -    -    -     -
      LinkCap.Vlan & Flags     sub-tlv  1     X    -    -    -     -
      LinkCap.Enabled-Vlans    sub-tlv  2     X    -    -    -     -
      LinkCap.AppointedFwrdrs  sub-tlv  3     X    -    -    -     -

      CAPABILITY.Trill-Version sub-tlv  5     -    X    -    -     -
      CAPABILITY.Device ID     sub-tlv  6     -    X    -    X     -
      CAPABILITY.Root Priority sub-tlv  7     -    X    -    -     -
      CAPABILITY.Roots         sub-tlv  8     -    X    -    -     -
      CAPABILITY.Int-Vlans     sub-tlv  9     -    X    -    -     -
      CAPABILITY.Vlan-Groups   sub-tlv 10     -    X    -    -     -

   IANA SHOULD manage the remaining space using the consensus method.





























Banerjee, et al.        Expires September 3, 2009              [Page 18]


Internet-Draft                Layer-2-IS-IS                   March 2009


8.  Contributors

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

      Email: wardd@cisco.com


      Russ White
      Cisco Systems
      170 W Tasman Drive
      San Jose, CA  95138
      US

      Email: riw@cisco.com


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

      Email: dino@cisco.com

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

      Email: Radia.Perlman@Sun.com


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

      Email: d3e3e3@gmail.com


9.  References




Banerjee, et al.        Expires September 3, 2009              [Page 19]


Internet-Draft                Layer-2-IS-IS                   March 2009


9.1.  Normative References

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

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

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

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

9.2.  Informative References

   [RBRIDGES]
              Perlman, R. and J. Touch, "Transparent Interconnection of
              Lots of Links (TRILL):  Problem and Applicability
              Statement", 2008.

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


Author's Address

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

   Email: ayabaner@cisco.com











Banerjee, et al.        Expires September 3, 2009              [Page 20]