draft-ietf-isis-layer2-00.txt   draft-ietf-isis-layer2-01.txt 
Network Working Group A. Banerjee, Ed. Network Working Group A. Banerjee, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Expires: September 3, 2009 March 2, 2009 Intended status: Standards Track July 11, 2009
Expires: January 12, 2010
Extensions to IS-IS for Layer-2 Systems Extensions to IS-IS for Layer-2 Systems
draft-ietf-isis-layer2-00 draft-ietf-isis-layer2-01
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 3, 2009. This Internet-Draft will expire on January 12, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
This draft specifies the IS-IS extensions necessary to support multi- This document specifies the IS-IS extensions necessary to support
link IPv4 and IPv6 networks, as well as to provide true link state multi-link IPv4 and IPv6 networks, as well as to provide true link
routing to any protocols running directly over layer 2. While state routing to any protocols running directly over layer 2. While
supporting this concept involves several pieces, this document only supporting this concept involves several pieces, this document only
describes extensions to IS-IS. We leave it to the systems using describes extensions to IS-IS. We leave it to the systems using
these IS-IS extensions to explain how the information carried in these IS-IS extensions to explain how the information carried in
IS-IS is used. IS-IS is used.
1. Overview Table of Contents
There are a number of systems (for example, [RBRIDGES]) which have 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
proposed using layer 2 addresses carried in a link state routing 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
protocol, specifically IS-IS [IS-IS] [RFC1195], to provide true layer 2. TLV and sub-TLV Enhancements to IS-IS . . . . . . . . . . . . 4
2 routing in specific environments. This draft proposes a set of 2.1. The MAC-Reachability TLV . . . . . . . . . . . . . . . . . 5
TLVs and sub-TLVs to be added to [IS-IS] level 1 PDUs, and three new 2.2. The Group Address TLV . . . . . . . . . . . . . . . . . . 6
PDU types, to support these proposed systems. 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
This draft does not propose new forwarding mechanisms using this 1. Overview
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 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 draft proposes additional TLVs, to carry unicast and multicast This document specifies additional TLVs and sub-TLVs, to carry
attached address information. It also proposes additional sub-tlvs unicast and multicast attached address information. It also proposes
to carry information regarding building trees for Layer 2 networks. additional TLVs and sub-TLVs to carry information as required by the
This draft proposes three new IS-IS PDUs, the Multicast Group 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 (MGROUP) PDU, for carrying a list of attached or joined multicast
groups. The Multicast Group Complete Sequence Number (MGROUP-CSNP) groups. The Multicast Group Complete Sequence Number (MGROUP-CSNP)
PDU and the Multicast Group Partial Sequence Number (MGROUP-PSNP) PDU PDU and the Multicast Group Partial Sequence Number (MGROUP-PSNP) PDU
packets are also defined to be used with the new MGROUP-PDU to packets are also defined to be used with the new MGROUP-PDU to
perform database exchange on the MGROUP PDU packets. 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.
2.1. The MAC-Reachability TLV 2.1. The MAC-Reachability TLV
The MAC-Reachability (MAC-RI) TLV is IS-IS TLV type 141 and has the The MAC-Reachability (MAC-RI) TLV is IS-IS TLV type 141 and has the
following format: 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= MAC-RI | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Type= MAC-RI | Length | Vlan-Id | | Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| MAC (1) | | Confidence | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (1) | MAC (2) | | Topology-Id/ Nickname-Id | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | VLAN-ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (2) | | MAC (1) (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. | | ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (N) | | MAC (N) (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to 141 (MAC-RI). 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 o Length: Total number of bytes contained in the value field given
all subsequent MAC addresses in this TLV. 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.
o MAC(i): This is the 48-bit MAC address reachable from the IS that o MAC(i): This is the 48-bit MAC address reachable from the IS that
is announcing this TLV. is announcing this TLV.
The MAC-RI TLV is carried in a standard Level 1 link state PDU. It The MAC-RI TLV is carried in a standard Level 1 link state PDU. It
MUST contain only unicast addresses. MUST contain only unicast addresses.
2.2. The Group Address TLV 2.2. The Group Address TLV
The Group Address (GADDR) TLV is IS-IS TLV type 142 [TBD] and has the The Group Address (GADDR) TLV is IS-IS TLV type 142 [TBD] and has the
following format: following format:
0 1 2 3 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 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 | |Type = GADDRTLV| Length | sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to GADDR-TLV 142 [TBD]. 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 Length: Total number of bytes contained in the value field, which
o sub-tlvs: The following sub-TLVs are defined. 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 The GADDR TLV is carried within Multicast Group Level 1 link state
PDU. PDU.
2.2.1. The Group MAC Address sub-TLV 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 Group MAC Address (GMAC-ADDR) sub-TLV is IS-IS sub-TLV type 1
the following format: within the GADDR TLV and has the following format:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Type=GMAC-ADDR| (1 byte) | Type=GMAC-ADDR| (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+
| Confidence | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vlan-Id | (2 byte) | Topology-Id/ Nickname-Id | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | VLAN-ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Num Group Recs | (1 byte) |Num Group Recs | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (1) | | GROUP RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. | | ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (N) | | GROUP RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 4, line 37 skipping to change at page 7, line 41
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (6 bytes) | | Group Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 1 Address (6 bytes) | | Source 1 Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 2 Address (6 bytes) | | Source 2 Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source M Address (6 bytes) | | Source M Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to 1 (GMAC-ADDR) of length 1 byte. o Type: sub-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 o Length: Total number of bytes contained in the value field.
all subsequent MAC addresses in this TLV.
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.
o Number of Group Records: This is of length 1 byte and lists the o Number of Group Records: This is of length 1 byte and lists the
number of group records in this TLV. number of group records in this TLV.
o Group Record: Each group record has a reserved space and followed 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 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 48-bit multicast Group Address followed by 48-bit source MAC
addresses. An address being a group multicast address or unicast addresses. An address being a group multicast address or unicast
source address can be checked using the multicast bit in the source address can be checked using the multicast bit in the
address. 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 The GMAC-ADDR sub-TLV is carried within the GADDR TLV and MUST be
carried in a standard Level 1 link state MGROUP PDU. carried in a standard Level 1 link state MGROUP PDU.
2.2.2. The Group IP Address sub-TLV 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 Group IP Address (GIP-ADDR) sub-TLV is IS-IS TLV type 2 and has
the following format: the following format:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Type=GIP-ADDR | | Type=GIP-ADDR |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+
| Confidence | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vlan-Id | (2 byte) | Topology-Id/ Nickname-Id | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | VLAN-ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Num Group Recs | (1 byte) |Num Group Recs | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (1) | | GROUP RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. | | ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (N) | | GROUP RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 5, line 42 skipping to change at page 9, line 41
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (4 bytes) | | Group Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 1 Address (4 bytes) | | Source 1 Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 2 Address (4 bytes) | | Source 2 Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source M Address (4 bytes) | | Source M Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to 2 (GIP-ADDR). o Type: sub-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 o Length: Total number of bytes contained in the value field of the
all subsequent IPv4 source or group addresses in this TLV. TLV.
o Confidence: This carries an 8-bit quantity indicating the
confidence level in the IP addresses being transported. Whether
this field is used, and its semantics if used, are further defined
by the specific protocol using Layer-2-IS-IS. If not used, it
must be set to zero on transmission and be ignored on receipt.
o Topology-Id/Nickname-Id: Depending on the technology in which it
is used, this carries the topology-id or nickname-id. When this
field is set to zero this implies that the MAC addresses are
reachable across all topologies or across all nicknames of the
originating IS.
o RESV: 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 o Number of Group Records: This is of length 1 byte and lists the
number of group records in this TLV. number of group records in this TLV.
o Group Record: Each group record has a reserved space and followed 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 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 by a 32-bit IPv4 Group Address followed by 32-bit source IPv4
addresses. 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 The GIP-ADDR TLV is carried within the GADDR TLV and MUST be carried
in a standard Level 1 link state MGROUP PDU. in a standard Level 1 link state MGROUP PDU.
2.2.3. The Group IPv6 Address sub-TLV 2.2.3. The Group IPv6 Address sub-TLV
The Group IPv6 Address (GIPV6-ADDR) TLV is IS-IS sub-TLV type 3 and The Group IPv6 Address (GIPV6-ADDR) TLV is IS-IS sub-TLV type 3 and
has the following format: has the following format:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Type=GIPv6-ADDR| |Type=GIPv6-ADDR|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+
| Confidence | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vlan-Id | (2 byte) | Topology-Id/ Nickname-Id | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | VLAN-ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Num Group Recs | (1 byte) |Num Group Recs | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (1) | | GROUP RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. | | ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (N) | | GROUP RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 6, line 45 skipping to change at page 11, line 41
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (16 bytes) | | Group Address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 1 Address (16 bytes) | | Source 1 Address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 2 Address (16 bytes) | | Source 2 Address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source M Address (16 bytes) | | Source M Address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to 3 (GIPV6-ADDR). o Type: sub-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 o Length: Total number of bytes contained in the value field.
all subsequent IPv6 source or group addresses in this TLV.
o Confidence: This carries an 8-bit quantity indicating the
confidence level in the IPv6 addresses being transported. Whether
this field is used, and its semantics if used, are further defined
by the specific protocol using Layer-2-IS-IS. If not used, it
must be set to zero on transmission and be ignored on receipt.
o Topology-Id/Nickname-Id: Depending on the technology in which it
is used, this carries the topology-id or nickname-id. When this
field is set to zero this implies that the MAC addresses are
reachable across all topologies or across all nicknames of the
originating IS.
o RESV: 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 o Number of Group Records: This of length 1 byte and lists the
number of group records in this TLV. number of group records in this TLV.
o Group Record: Each group record has a reserved space and followed 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 the number of sources, each of length 1 byte. It is followed
by a 128-bit multicast IPv6 Group Address followed by 128-bit by a 128-bit multicast IPv6 Group Address followed by 128-bit
source IPv6 addresses. 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 The GIPV6-ADDR sub-TLV is carried within the GADDR TLV and MUST be
carried in a standard Level 1 link state MGROUP PDU. carried in a standard Level 1 link state MGROUP PDU.
2.3. Link Capability TLV 2.3. Multi Topology aware Port Capability TLV
The Link Capability (LINK-CAP) is an optional IS-IS TLV type 143 The Multi Topology aware Port Capability (MT-PORT-CAP) is an IS-IS
[TBD], that may be generated by the originating IS and has the TLV type 143 [TBD], and has the following format:
following format:
0 1 2 3 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 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 | |Type=MT PORTCAP| Length |O|R|R|R| Topology Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to LINK-CAP TLV 143 [TBD]. o Type: TLV Type, set to MT-PORT-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 o Length: Total number of bytes contained in the value field,
PDU. 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.
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 2.3.1. The Special VLANs and Flags sub-TLV
The Special VLANs and Flags (VLAN & Flags) sub-TLV MUST appear The Special VLANs and Flags (VLAN and Flags) sub-TLV MUST appear
exactly once in a Port Information TLV in every TRILL Hello PDU. It exactly once in a MT aware Port Capability TLV in every LAN IIH PDU.
has the following format: It has the following format:
0 1 2 3 4 - 15 16 - 19 20 - 31 0 1 2 3 4 - 15 16 - 19 20 - 31
+----+----+----+----+------------+----------+------------+ +----+----+----+----+------------+----------+------------+
| AF | AC | VM | R | Outer.VLAN | Reserved | Desig.VLAN | | AF | AC | VM | BY | Outer.VLAN | Reserved | Desig.VLAN |
+----+----+----+----+------------+----------+------------+ +----+----+----+----+------------+----------+------------+
o Type: TLV Type, set to VLAN &amp Flags sub-TLV 1 [TBD]. o Type: TLV Type, set to VLAN and 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 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 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 bits of the first byte give the upper ID bits of the VLAN ID and
the second octet gives the lower VLAN ID bits. the second byte 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 o The upper 4 bits of the first byte are flag bits as shown. The AF
Appointed Forwarder for the VLAN and port on which the Hellos was bit, if one, indicates that the sending Intermediate System
sent. The AC bit, if one, indicates that the sending port is believes it is Appointed Forwarder for the VLAN and port on which
configured as an access port. The VM flag, if a one, indicates the Hellos was sent. The AC bit, if one, indicates that the
that the sending RBridge has detected VLAN mapping within the sending port is configured as an access port. The VM bit, if a
link. The R bit is reserved and MUST be sent as zero and ignored one, indicates that the sending Intermediate System has detected
on receipt. VLAN mapping within the link. The BY bit, if set, indicates
o The third and forth octets give the Designated VLAN for the link. bypass psuedonode.
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. o The third and forth bytes give the Designated VLAN for the link.
The upper 4 bits of the third octet are reserved and MUST be sent 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. as zero and ignored on receipt.
The VLAN & Flags sub-TLV is carried within the LINK-CAP TLV and MUST The VLAN and Flags sub-TLV is carried within the MT aware PORT-CAP
be carried in IIH PDU. TLV and MUST be carried in LAN IIH PDU. It MUST NOT be carried
within a P2P IIH PDU.
2.3.2. Enabled VLANs sub-TLV 2.3.2. Enabled VLANs sub-TLV
The Enabled VLAN sub-TLV specifies the VLANs enabled for end station The Enabled VLAN sub-TLV specifies the VLANs enabled for end station
service at the port on which the Hello was sent. service at the port on which the Hello was sent.
o Type: TLV Type, set to Enabled VLANs sub-TLV 2 [TBD]. o Type: sub-TLV Type, set to Enabled VLANs sub-TLV 2 [TBD].
o Length: variable, depending on contents described next. 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 o The minimum size of the value is 3 bytes. The third and
the VLAN ID indicated in the first two octets. The lower order subsequent bytes provide a bit map of enabled VLANs starting at
four bits of the first octet give the upper bits of the starting the VLAN ID indicated in the first two bytes. The lower order
VLAN ID and the second octet gives the lower bits of that VLAN ID. four bits of the first byte give the upper bits of the starting
The upper four bits of the first octet are reserved and MUST be 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 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 third byte indicates the VLAN equal to the starting ID while the
lowest order bit of the third octet indicated that ID plus 7. For lowest order bit of the third byte indicated that ID plus 7. For
example, VLANs 1 and 14 being enabled for end station service example, VLANs 1 and 14 being enabled for end station service
could be encoded in 4-octets value 0x00 0x01 0x80 0x04 or, could be encoded in 4-bytes value 0x00 0x01 0x80 0x04 or,
alternatively, as 0x00 0x00 0x40 0x02. alternatively, as 0x00 0x00 0x40 0x02.
This sub-TLV may occur more than once in a TRILL Hello and a VLAN is 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 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 if this is indicated by any occurrence in the Hello. For example, a
receiver could allocate a 512-octet buffer and, with appropriate receiver could allocate a 512-byte buffer and, with appropriate
shifting operations, OR in the enabled bits for each subTLV of this 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 type it finds in a Hello to derive the complete bit map of these
VLANs. VLANs.
The Enabled VLAN sub-TLV is carried within the LINK-CAP TLV and MUST The Enabled VLAN sub-TLV is carried within the MT aware PORT-CAP TLV
be carried in IIH PDU. 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 2.3.3. Appointed Forwarders sub-TLV
The Appointed Forwarder sub-TLV provides the mechanism by which the The Appointed Forwarder sub-TLV provides the mechanism by which the
DRB can inform other RBridges on the link that they are the Designated Intermediate System can inform other Intermediate Systems
designated VLAN-x forwarder for that link for one or more ranges of on the link that they are the designated VLAN-x forwarder for that
VLAN IDs. link for one or more ranges of VLAN IDs.
o Type: TLV Type, set to Enabled VLANs sub-TLV 3 [TBD]. o Type: sub-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 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: follows:
+----------------+-----+-----+---------+-----+----+---------+ +----------------+-----+-----+---------+-----+----+---------+
| octet 1 - 2 | octet 3 | octet 4 | octet 5 | octet 6 | | byte 1 - 2 | byte 3 | byte 4 | byte 5 | byte 6 |
+----------------+-----+-----+---------+-----+----+---------+ +----------------+-----+-----+---------+-----+----+---------+
| Appointee Nick | Res | Start VLAN ID | Res | End VLAN ID | | 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 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 o The "Res" fields of 4 bits each are reserved and MUST be sent as
zero and ignored on reciept. zero and ignored on receipt.
The VLAN range given is inclusive. To specify a single VLAN, that 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 VLAN ID appears as both the start and end VLAN. The Intermediate
nickname is given is appointed forwarder for those VLANs for which it System whose nickname is given is appointed forwarder for those VLANs
has end station service enabled (see item 2 above) in the inclusive for which it has end station service enabled (see item 2 above) in
range. For example, assume an RBridge with end station service the inclusive range. For example, assume an Intermediate System with
enabled on VLANs 100, 101, 199, and 200 (and possibly other VLANs end station service enabled on VLANs 100, 101, 199, and 200 (and
less than 100 or greater than 200), but not enabled for VLANS 102 possibly other VLANs less than 100 or greater than 200), but not
through 198. It could be appointed forwarder for these four VLANs enabled for VLANs 102 through 198. It could be appointed forwarder
through either (1) a single 6-octet value sequence with start and end for these four VLANs through either (1) a single 6-byte value
VLAN IDs of 100 and 200, or (2) a 12-octet value sequence with start sequence with start and end VLAN IDs of 100 and 200, or (2) a 12-byte
and end VLAN IDs of 100 and 101 in the first part and 199 and 200 in value sequence with start and end VLAN IDs of 100 and 101 in the
the second part. first part and 199 and 200 in the second part.
An RBridge's nickname may occur as appointed forwarder for multiple An Intermediate System's nickname may occur as appointed forwarder
VLAN ranges within the same or different Link Capability TLVs within for multiple VLAN ranges within the same or different Port Capability
a DRB's Hello. In the absence of appointed forwarder subTLVs TLVs within a Designated Intermediate Systems's Hello. In the
referring to a VLAN, the DRB acts as the appointed forwarder for that absence of appointed forwarder sub-TLVs referring to a VLAN, the
VLAN if end station service is enabled. 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 LINK-CAP TLV The Appointed Forwarder sub-TLV is carried within the MT aware PORT-
and MUST be carried in IIH PDU. CAP TLV and MUST be carried in a LAN IIH PDU. This MUST NOT be
carried in a P2P IIH PDU.
2.4. Sub-TLVs for the Capability TLV 2.3.4. Hop-by-Hop Options (HBHOPT) sub-TLV
The Capability TLV is an optional TLV [RFC 4971] that may be By including this sub-TLV within one or more MT aware Port Capability
generated by the originating IS. We introduce these additional sub- TLVs in its Hellos, an Intermediate System can advertise the Hop-by-
TLVs that are carried within it. These sub-tlvs announce the Hop options it supports on the port through which it sends the Hello.
capabilities of the router for the entire IS-IS routing domain. This sub-TLV may appear zero or more times within a MT aware Port
Capability TLV. By default, in the absence of any HBHOPT sub-TLVs,
no Hop-by-Hop options are supported.
There are two types of Hop-by-Hop option encoding within the TRILL
Header: bit options and TLV encoded options.
The bit-encoded options supported are indicated by an HBHOPT sub-TLV
of length 3: an initial value byte of 0xFF followed by four bytes in
which each bit indicates that the corresponding bit option is
implemented; in those four bytes the top two bits (0xC0000000) are
critical option summary bits that all RBridges MUST understand.
Those two bits are reserved in the HBHOPT sub-TLV and must be sent as
zero are ignored on receipt.
The implementation of a TLV encoded option is indicated by an HBHOPT
sub-TLV whose value starts with a byte equal to the first byte of the
option. Such HBHOPT sub-TLVs may have additional value bytes further
indicating how the option is supported as specified with the option's
definition, for example a list of supported security algorithms.
+-+-+-+-+-+-+-+-+
| Type = HBHOPT |
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
| Option | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option dependent variable length information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type, set to Hop-by-Hop sub-TLV 4 [TBD].
o Length: variable, minimum 1.
o Value: The first byte of the option followed by option dependent
information.
2.3.5. Base VLAN-Identifiers sub-TLV
This sub-TLV is added to an IIH PDU to indicate the algorithms for
the VIDs and the Base VIDs and VIDs or Backbone-VIDs (B-VIDs) are in
use. This information should be the same on all bridges in the
topology identified by MT-PORT-CAP TLV it is being carried.
Discrepancies between neighbours with respect to this sub-TLV are
temporarily allowed but the Base-VID must agree and use a spanning
tree algorithm.
+-+-+-+-+-+-+-+-+
|Type = B-VID |
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
|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.
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 2.4.1. The TRILL Version sub-TLV
The TRILL Version (TRILL-VER) sub-TLV indicates support of TRILL The TRILL Version (TRILL-VER) sub-TLV indicates support of TRILL
Versions. The device announces the maximum version of TRILL, it is Versions. The device announces the maximum version of TRILL, it is
capable of supporting, including lower versions. In the event, this capable of supporting, including lower versions. In the event, this
sub-tlv is missing, this implies that the node can only support the sub-TLV is missing, this implies that the node can only support the
base version of the protocol. base version of the protocol.
0 1 2 3 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 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 | | Type | Length | Reserved | Max-version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to 5 (TRILL-VER). o Type: sub-TLV Type, set to 5 (TRILL-VER).
o Length: 2 - Total number of octets contained in the TLV.
o Reserved: Set to 0. 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. o Max-version: Set to application dependent values.
2.4.2. The Device ID sub-TLV 2.4.2. The Nickname sub-TLV
The Device ID (DEVID) sub-TLV carries information about the identity The Nickname (NICK) sub-TLV carries information about the nicknames
of the advertising device, along with information about device of the advertising device, along with information about its priority
priority. The Device-Id sub-TLV MUST be carried within the to hold those nicknames. The Nickname sub-TLV MUST be carried within
CAPABILITY TLV in a level-1 non-pseudo-node LSP generated by the the Router CAPABILITY TLV in a level-1 non-pseudo-node LSP generated
originating IS. 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 = NICKNAME|
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Priority | | NICKNAME RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NICKNAME RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Device Id |
+---------------------------------------------------------------+
o Type: TLV Type, set to 6 (DEVID). where each nickname record is of the form:
o Length: Total number of octets contained in the TLV.
o Reserved: Set to 0. +-+-+-+-+-+-+-+-+-+
| 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 Priority: Set to application dependent values.
o Device ID: Left padded device ID or alias.
2.4.3. The Root Priority sub-TLV o Nickname: This is an unsigned 16-bit integer that gives device
identifier or alias.
The Root Priority sub-TLV MUST be carried within the CAPABILITY TLV Each nickname record consists of a one-byte priority set to
in a level-1 non-pseudo-node LSP generated by the originating IS. application dependent values, and two bytes of device identifier or
Each device announces a broadcast root-priority and the number of alias (i.e., actual nickname).
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 2.4.3. The Trees sub-TLV
algorithm, independently of the other nodes in the network, to
determine the broadcast root. The node that announced the lowest The Trees sub-TLV MUST occur only once and can be carried within the
broadcast priority becomes the root of the broadcast tree. If two Router CAPABILITY TLV in a level-1 non-pseudo-node LSP generated by
devices advertise the same broadcast priority, the device with the the originating IS. Each device announces four numbers: its own
lower system ID becomes the root of the broadcast tree. The elected priority to be a multi-destination frame distribution tree root; the
broadcast-root decides on the multicast-roots to be used in the number of trees it dictates that all other Intermediate Systems in
network domain and their roots. This announcement takes place in the the campus compute if it is the highest priority tree root; the
roots identifier sub-TLV. 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
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 = ROOT-PRI| |Type = TREE |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Broadcast Root Pri | (2 byte) | Tree Root Priority | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Num of multi-destination trees | (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: TLV Type, set to 7 (ROOT-PRI). o Type: sub-TLV Type, set to 7 (TREE).
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 o Length: 6 : Total number of bytes contained in the value field.
The root identifier sub-tlv is populated by the root of the broadcast o Tree Root Pri: This is an unsigned 16-bit integer that gives the
tree. If this is also announced by other nodes in the network, it value of the priority with which this node wants to be the highest
implies that the specific node that is advertising it will only priority root node in the Layer-2 domain.
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:
0 1 2 3 o Number of trees to compute: This is an unsigned 16-bit integer
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 that gives the requested number of distribution trees for multi-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ destination frames that will be in use in the Layer-2 domain, if
|Type= ROOT-IDs | Length | RESERVED | this device becomes the highest priority tree root in the domain.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 Maximum number of tree able to compute: This is an unsigned 16-bit
o Length: Total number of octets contained in the TLV. integer that give the maximum number of threes that the
o Multi-destination Tree Num: This identifies the trees being used originating IS is able to compute for the campus.
by the specific nodes.
o Broadcast Root System Id: The Broadcast Root System ID at which a o Number of trees to use: This is an unsigned 16-bit integer that
broadcast tree is rooted. It is of length 6 bytes. gives the number of distribution trees the originating IS wishes
o Multicast Root System Id: The Multicast Root System ID at which a to be able to use.
multicast tree is rooted. It is of length 6 bytes.
A locally significant hash is used by edge devices to determine which 2.4.4. The Tree Roots Identifier Sub-TLV
multicast root (or set of multicast roots) is used to send traffic
for a specific multicast group. If there is a discrepancy between The tree root identifier sub-TLV is is an ordered list of nicknames.
the number of multi-destination trees the broadcast-root has When originated by the Intermediate System which is the highest
priority tree root, this list is the tree roots for which other
Intermediate Systems are required to compute trees. If this
information is spread across multiple sub-tlvs, the starting tree
root identifier is used to figure out the ordered list. It is
carried within the 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 announced, and the number of roots the root-identifier sub-tlv
carries, nodes MUST compute trees on the additional roots. carries, nodes MUST compute trees for the additional roots.
2.4.5. Interested Vlans and Spanning Tree Roots sub-TLV 2.4.5. The Tree Used Identifier Sub-TLV
The value of this subTLV consists of a VLAN range, flags, and a This sub-TLV has the same structure as the Tree Roots Identifier Sub-
variable length list of spanning tree root bridge IDs. This subTLV TLV specified in the above section. The only difference is that its
sub-TLV type is set to 9 TBD (TREE-USE-IDs) and the roots listed are
only those that the originating intermediate systems wishes to use.
2.4.6. Interested VLANs and Spanning Tree Roots sub-TLV
The value of this sub-TLV consists of a VLAN range, flags, and a
variable length list of spanning tree root bridge IDs. This sub-TLV
may appear zero, one, or many times. The union of the VLAN ranges in 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 all occurrences MUST be precisely the set of VLANs for which the
originating RBridge is appointed forwarder on at least one port and originating Intermediate System is appointed forwarder on at least
the VLAN ranges in multiple VLANs subTLVs for an RBridge MUST NOT one port and the VLAN ranges in multiple VLANs sub-TLVs for an
overlap. That is, the intersection of the VLAN ranges for any pair Intermediate System MUST NOT overlap. That is, the intersection of
of these subTLVs originated by an RBridge must be null. The value the VLAN ranges for any pair of these sub-TLVs originated by an
length is 4 + 6*n where n is the number of root bridge IDs.The Intermediate System must be null. The value length is 4 + 6*n where
initial 4 octets of value are as follows: n is the number of root bridge IDs. The initial 4 bytes of value are
as follows:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Type = INT-VLAN| |Type = INT-VLAN|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+---------------+-----+
| Nickname-Id | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interested VLANS | (4 bytes) | Interested VLANS | (8 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multi-destination tree roots | (6*n bytes) | Root Bridges | (6*n bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to 9 (INT-VLAN). o Type: sub-TLV Type, set to 10 (INT-VLAN).
o Length: Total number of octets contained in the TLV.
o Interested VLANS: The M4 bit indicates that there is an IPv4 o Length: Total number of bytes contained in the value field.
multicast router on a link for which the originating RBridge is
appointed forwarder for every VLAN in the indicated range. The M6 o Nickname Id: If this is set to 0, then it applies to all device-
bit indicates the same for an IPv6 multicast router. The OM bit ids generated by the node. It may alternatively be set to a
indicates that this RBridge requests that all non-IP derived specific nickname-id, in the event a node wants to segregate
multicast traffic in the indicated VLAN range be sent to it. The traffic using multiple device-ids.
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 o Interested VLANS: In the Interested VLANs, as shown below, the M4
one VLAN ID is indicated by setting them both to that VLAN ID bit indicates that there is an IPv4 multicast router on a link for
value. It has the following format: 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:
0 1 2 3 4 - 15 16 - 19 20 - 31 0 1 2 3 4 - 15 16 - 19 20 - 31
+----+----+----+----+------------+----------+------------+ +----+----+----+----+------------+----------+------------+
| AF | AC | VM | R | Outer.VLAN | Reserved | Desig.VLAN | | M4 | M6 | R | R | VLAN start | Reserved | VLAN end |
+----+----+----+----+------------+----------+------------+ +----+----+----+----+------------+----------+------------+
o Multi-destination tree roots: The list of zero or more spanning | Appointed Forwarder Status Lost Counter |
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 o Root Bridges: The list of zero or more spanning tree root bridge
RBridge. If MSTP is in use on a link, the root bridge referred to IDs is the set of root bridge IDs seen for all ports for which the
is the CIST (common and internal spanning tree) root bridge. Intermediate System is appointed forwarder for the VLANs in the
(While, of course, only one spanning tree root should be seen on range. This information is learned from BPDUs heard by the
any particular port, there may be multiple ports in the same VLAN Intermediate System. If MSTP is in use on a link, the root bridge
connected to differed bridged LANs with different spanning tree referred to is the CIST (common and internal spanning tree) root
roots.) If no spanning tree roots can be seen on any of the links bridge. (While, of course, only one spanning tree root should be
in any of the VLANs in the range indicated for which the RBridge seen on any particular port, there may be multiple ports in the
is appointed forwarder (for example all such links are point-to- same VLAN connected to differed bridged LANs with different
point links to other RBridges or to end stations so no BPDUs are spanning tree roots.) If no spanning tree roots can be seen on
received) then the listed set of spanning tree root IDs will be any of the links in any of the VLANs in the range indicated for
null. 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 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 of the M4, or M6 bits are different, the sub-TLV is incorrect and
must be split into multiple subTLVs each indicating only VLANs with must be split into multiple sub-TLVs each indicating only VLANs with
the same M4, M6, and OM values. If there are any two VLANs in the the same M4, and M6 values. If there are any two VLANs in the range
range indicated for which the set of root bridge IDs see on all links indicated for which the set of root bridge IDs see on all links for
for which the RBridge is appointed forwarder for the VLAN are not the which the Intermediate System is appointed forwarder for the VLAN are
same, the subTLV is incorrect and must be split into multiple subTLVs not the same, the sub-TLV is incorrect and must be split into
each indicating only VLANs with the same set of DRB seen root bridge multiple subTLVs each indicating only VLANs with the same set of DRB
IDs. It is always safe to use subTLVs with a "range" of one VLAN ID seen root bridge IDs. It is always safe to use sub-TLVs with a
but this may be too verbose. "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- This sub-TLV is carried within the CAPABILITY TLV in a level-1 non-
pseudo-node LSP. pseudo-node LSP.
2.4.6. The Vlan Group Sub-tlv 2.4.7. The VLAN Group sub-TLV
The Vlan Group sub-tlv consists of two or more 16-bit fields each of 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 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 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 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: the CAPABILITY TLV in a level-1 non-pseudo-node LSP and is given as:
+-+-+-+-+-+-+-+-+
|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.
+-+-+-+-+-+-+-+-+
| 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
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 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 | |Type=MTCAPABTLV| Length |O|R|R|R| Topology Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Primary Vlan-Id | Secondary Vlan Id | | 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
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to 10 (VLAN-GROUPs). where VLAN-ID tuples have the format as:
o Length: Total number of octets contained in the TLV.
o Primary Vlan-id: This identifies the primary Vlan-id. 0 1 2- 3 4 - 15 16 - 19 20 - 31
o Secondary Vlan-id: This identifies the secondary Vlan-id, address +-+-+---------+-------+-----------+------------+
learning is shared at the Rbridge that announces this sub-tlv. |A|U|Reserved | VID | Algorithm | B-VID |
This sub-tlv may appear zero, one, or multiple times. +-+-+---------+-------+-----------+------------+
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
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
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
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
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 3. The Multicast Group PDU
The systems that this draft is concerned with want to carry not only The systems that this dcoument is concerned with want to carry not
layer-2 unicast information in the link state protocols, but also only layer-2 unicast information in the link state protocols, but
multicast information. This draft has defined a new Multicast Group also multicast information. This document specifies three new IS-IS
(MGROUP) PDU that can be used to advertise a set of attached, or PDUs, the Multicast Group (MGROUP) PDU, for carrying a list of
joined, multicast groups. Accordingly, it has also introduced a attached or joined multicast groups. The Multicast Group Complete
couple more PDUs as described in the next sections for the flooding Sequence Number (MGROUP-CSNP) PDU and the Multicast Group Partial
and update process to work seamlessly. 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 In the Layer-2 environment, it is expected the join/leave frequency
of the multicast members will be much higher than unicast topology of the multicast members will be much higher than unicast topology
changes. It is efficient to separate the updates for the group changes. It is efficient to separate the updates for the group
membership change information from the remainder of the information membership change information from the remainder of the information
by placing this information in a separate PDU. This enables by placing this information in a separate PDU. This enables
reachability information, that would trigger an SPF, to be not reachability information, that would trigger an SPF, to be not
impacted at all. Furthermore, during SPF runs, TLVs being on impacted at all. Furthermore, during SPF runs, TLVs being on
different PDUs which do not affect SPF need not be inspected during different PDUs which do not affect SPF need not be inspected during
processing. processing.
The choice of a different PDU also opens the LSP-space to another 256 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 fragments to carry a large number of groups. This additional space
can be used judiciously to carry only multicast information. can be used judiciously to carry only multicast information.
The Multicast Group (MGROUP) PDU can be used to advertise a set of The Multicast Group (MGROUP) PDU can be used to advertise a set of
attached, or joined, multicast groups. The MGROUP PDU is formatted 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 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 [IS-IS]. One field, PDU Type, is changed to 19 [TBD], to signify
this PDU is carrying multicast group information, rather than unicast this PDU is carrying multicast group information, rather than unicast
reachability information. 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 The Multicast Group PDU carries TLVs indicating multicast membership
information. There are three sub-TLVs of the GADDR TLV defined in information. There are three sub-TLVs of the GADDR TLV defined in
this document, that MAY be present in this PDU, namely, GMAC-ADDR, this document, that MAY be present in this PDU, namely, GMAC-ADDR,
GIP-ADDR, and GIPV6-ADDR TLVs. GIP-ADDR, and GIPV6-ADDR TLVs.
One or more TLVs MAY be carried in a single MGROUP PDU. Future 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 multicast address TLVs MAY be defined using other type codes, and be
carried in an MGROUP PDU. carried in an MGROUP PDU.
skipping to change at page 15, line 46 skipping to change at page 32, line 27
specifications. specifications.
3.2. The Multicast Group Complete Sequence Number PDU 3.2. The Multicast Group Complete Sequence Number PDU
The Multicast Group Complete Sequence Number PDU (MGROUP-CSNP) PDU is The Multicast Group Complete Sequence Number PDU (MGROUP-CSNP) PDU is
used to reliably flood the MGROUP PDU following the base protocol used to reliably flood the MGROUP PDU following the base protocol
specifications. specifications.
3.3. Enhancements to the flooding process 3.3. Enhancements to the flooding process
This draft proposes that the information contained in the MGROUP-PDU This document proposes that the information contained in the MGROUP-
is in a parallel database and its update mechanisms mimic that of the PDU is in a parallel database and its update mechanisms mimic that of
regular database. Nodes running IS-IS in an L2 domain MUST support the regular database. Nodes running IS-IS in an L2 domain MUST
these additional MGROUP PDUs defined in this draft. In general, the support these additional MGROUP PDUs defined in this document. In
flooding of the MGROUP-PDU in tandem with the MGROUP-PSNP and MGROUP- general, the flooding of the MGROUP-PDU in tandem with the MGROUP-
CSNP PDUs uses the same update procedures as defined for the regular PSNP and MGROUP-CSNP PDUs uses the same update procedures as defined
LSP, PSNP, and CSNP PDUs. for the regular LSP, PSNP, and CSNP PDUs.
For example, on P2P links CSNP is exchanged on the formation of an 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 adjacency. In a similar fashion a MGROUP-CSNP MUST also be exchanged
between the neighbors at the same time. This gets the initial between the neighbors at the same time. This gets the initial
MGROUP-database synchronization going. After this similar actions of MGROUP-database synchronization going. After this similar actions of
the base protocol specifications for the regular database the base protocol specifications for the regular database
synchronization will be maintained to keep the MGROUP-database synchronization will be maintained to keep the MGROUP-database
synchronized. synchronized.
Similarly, on LAN links the DIS is responsible for sending periodic Similarly, on LAN links the DIS is responsible for sending periodic
CSNP transmissions. The DIS in the L2 IS-IS network domain will also CSNP transmissions. The DIS in the L2 IS-IS network domain will also
be responsible for sending periodic MGROUP-CSNP transmissions. The be responsible for sending periodic MGROUP-CSNP transmissions. The
update and flooding process will work in parallel for the two update and flooding process will work in parallel for the two
databases and there is no further synchronization between them. databases and there is no further synchronization between them.
In general, the database synchronization is performed in parallel In general, the database synchronization is performed in parallel
with no interactions between the messages. However, the initial with no interactions between the messages. However, the initial
triggers that start a CSNP exchange are correlated, in the sense it triggers that start a CSNP exchange are correlated, in the sense it
also triggers a MGROUP-CSNP exchange. For example, during graceful also triggers a MGROUP-CSNP exchange. For example, during graceful
restart [RFC 3847], a parallel MGROUP-CSNP and MGROUP-PSNP exchange restart [RFC 5306], the normal hello operations as described in the
and update process will be run for the MGROUP-PDUs and restart RFC will be followed. The enhancements will take place such that
process completes after both databases have been received. 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 4. Considerations for Using L2 Information in IS-IS
While this document does not specify the way in which addresses 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 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 are considered in this section: building the SPF tree when using this
information, and the election of designated intermediate systems information, and the election of designated intermediate systems
(DIS) in an environment using this information. (DIS) in an environment using this information.
4.1. Building SPF Trees with Layer 2 Information 4.1. Building SPF Trees with Layer 2 Information
Each IS which is part of a single broadcast domain from a layer 2 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 perspective will build multiple SPF trees (SPT) for every IS that is
announced by the IS deemed to be the broadcast root. announced by the IS deemed to be the broadcast root.
skipping to change at page 17, line 34 skipping to change at page 34, line 28
MCAST-CSNP-PDU Level-1 PDU Type: 22 MCAST-CSNP-PDU Level-1 PDU Type: 22
MCAST-PSNP-PDU Level-1 PDU Type: 29 MCAST-PSNP-PDU Level-1 PDU Type: 29
This document requires the definition a set of new ISIS TLVs, the This document requires the definition a set of new ISIS TLVs, the
MAC-Reachability TLV (type 141), the Group Address TLV (type 142), MAC-Reachability TLV (type 141), the Group Address TLV (type 142),
and the Link-Capability TLV (type 143), that needs to be reflected in and the Link-Capability TLV (type 143), that needs to be reflected in
the ISIS TLV code-point registry. the ISIS TLV code-point registry.
This document creates a number of new sub-TLV in the numbering space This document creates a number of new sub-TLV in the numbering space
for the Group Address TLV, the Link Capability TLV, and the for the Group Address TLV, the Link Capability TLV, and the
Capability TLV. The TLV and sub-TLVs are given below: Capability TLV. The TLV and sub-TLVs are given below along with
technologies that use them.
IIH LSP SNP MCAST MCAST IIH LSP SNP MCAST MCAST TRILL/
LSP SNP LSP SNP IEEE
MAC-RI TLV (141) - X - - - MAC-RI TLV (141) - X - - - T/I
GADDR-TLV (142) - - - X - GADDR-TLV (142) - - - X - T/I
GADDR-TLV.GMAC-ADDR sub-tlv 1 - - - X - GADDR-TLV.GMAC-ADDR sub-tlv 1 - - - X - T/I
GADDR-TLV.GMAC-IP sub-tlv 2 - - - X - GADDR-TLV.GMAC-IP sub-tlv 2 - - - X - T/I
GADDR-TLV.GMAC-IPV6 sub-tlv 3 - - - X - GADDR-TLV.GMAC-IPV6 sub-tlv 3 - - - X - T/I
Link-Cap-TLV (143) X - - - - MT-Port-Cap-TLV (143) X - - - - T/-
LinkCap.Vlan & Flags sub-tlv 1 X - - - - PortCap.VLAN and Flags sub-tlv 1 X - - - - T/-
LinkCap.Enabled-Vlans sub-tlv 2 X - - - - PortCap.Enabled-VLANs sub-tlv 2 X - - - - T/-
LinkCap.AppointedFwrdrs sub-tlv 3 X - - - - 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 - - - CAPABILITY.Trill-Version sub-tlv 5 - X - - - T/-
CAPABILITY.Device ID sub-tlv 6 - X - X - CAPABILITY.Nickname sub-tlv 6 - X - X - T/-
CAPABILITY.Root Priority sub-tlv 7 - X - - - CAPABILITY.Tree sub-tlv 7 - X - - - T/-
CAPABILITY.Roots sub-tlv 8 - X - - - CAPABILITY.Tree Roots Id sub-tlv 8 - X - - - T/-
CAPABILITY.Int-Vlans sub-tlv 9 - X - - - CAPABILITY.TreeUseRootId sub-tlv 9 - X - - - T/-
CAPABILITY.Vlan-Groups sub-tlv 10 - X - - - 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. IANA SHOULD manage the remaining space using the consensus method.
8. Contributors 8. Contributing Authors
David Ward David Ward
Cisco Systems Cisco Systems
170 W Tasman Drive 170 W Tasman Drive
San Jose, CA 95138 San Jose, CA 95138
US US
Email: wardd@cisco.com Email: wardd@cisco.com
Russ White Russ White
skipping to change at page 19, line 40 skipping to change at page 36, line 27
Radia Perlman Radia Perlman
Sun Microsystems Sun Microsystems
16 Network Circle 16 Network Circle
Menlo Park, CA 94025 Menlo Park, CA 94025
US US
Email: Radia.Perlman@Sun.com Email: Radia.Perlman@Sun.com
Donald E. Eastlake 3rd Donald E. Eastlake 3rd
Eastlake Enterprises Stellar Switches
155 Beaver Street 155 Beaver Street
Milford, MA 07157 Milford, MA 07157
US US
Email: d3e3e3@gmail.com Email: d3e3e3@gmail.com
Peter Ashwood-Smith
Huawei Technologies Canada Co. Ltd.
411 Legget Drive, Suite 503
Kanta, Ontario K2K 3C9
CANADA
Email: Peter.AshwoodSmith@huawei.com
Don Fedyk
Alcatel-Lucent
220 Hayden Road
Groton, MA 01450
US
Email: Donald.Fedyk@alcatel-lucent.com
9. References 9. References
9.1. Normative References 9.1. Normative References
[IS-IS] ISO/IEC 10589, "Intermediate System to Intermediate System [IS-IS] ISO/IEC 10589, "Intermediate System to Intermediate System
Intra-Domain Routing Exchange Protocol for use in Intra-Domain Routing Exchange Protocol for use in
Conjunction with the Protocol for Providing the Conjunction with the Protocol for Providing the
Connectionless-mode Network Service (ISO 8473)", 2005. Connectionless-mode Network Service (ISO 8473)", 2005.
[RFC 1195] [RFC 1195]
Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and
Dual Environments", 1990. Dual Environments", 1990.
[RFC 3847]
Shand, M. and L. Ginsberg, "Restart Signaling for
Intermediate System to Intermediate System (IS-IS)", 2004.
[RFC 4971] [RFC 4971]
Vasseur, JP. and N. Shen, "Intermediate System to Vasseur, JP. and N. Shen, "Intermediate System to
Intermediate System (IS-IS) Extensions for Advertising Intermediate System (IS-IS) Extensions for Advertising
Router Information", 2007. 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 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] [RBRIDGES]
Perlman, R. and J. Touch, "Transparent Interconnection of Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A.
Lots of Links (TRILL): Problem and Applicability Ghanwani, "RBridges: Base Protocol Specification", 2009.
Statement", 2008.
[RFC 1584] [RFC 1584]
Moy, J., "Multicast Extensions to OSPF", March 1994. Moy, J., "Multicast Extensions to OSPF", March 1994.
Author's Address Author's Address
Ayan Banerjee (editor) Ayan Banerjee (editor)
Cisco Systems Cisco Systems
170 W Tasman Drive 170 W Tasman Drive
San Jose, CA 95138 San Jose, CA 95138
 End of changes. 113 change blocks. 
337 lines changed or deleted 1087 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/