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