draft-ietf-isis-layer2-01.txt   draft-ietf-isis-layer2-02.txt 
Network Working Group A. Banerjee, Ed. Network Working Group A. Banerjee, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track July 11, 2009 Intended status: Standards Track February 10, 2010
Expires: January 12, 2010 Expires: August 14, 2010
Extensions to IS-IS for Layer-2 Systems Extensions to IS-IS for Layer-2 Systems
draft-ietf-isis-layer2-01 draft-ietf-isis-layer2-02
Abstract
This document specifies the IS-IS extensions necessary to support
multi-link IPv4 and IPv6 networks, as well as to provide true link
state routing to any protocols running directly over layer 2. While
supporting this concept involves several pieces, this document only
describes extensions to IS-IS. We leave it to the systems using
these IS-IS extensions to explain how the information carried in
IS-IS is used.
Status of this Memo 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. provisions of BCP 78 and BCP 79.
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.
skipping to change at page 1, line 32 skipping to change at page 1, line 42
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 January 12, 2010. This Internet-Draft will expire on August 14, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document specifies the IS-IS extensions necessary to support described in the BSD License.
multi-link IPv4 and IPv6 networks, as well as to provide true link
state routing to any protocols running directly over layer 2. While
supporting this concept involves several pieces, this document only
describes extensions to IS-IS. We leave it to the systems using
these IS-IS extensions to explain how the information carried in
IS-IS is used.
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. TLV and sub-TLV Enhancements to IS-IS . . . . . . . . . . . . 4 2. PDU, TLV and sub-TLV Enhancements to IS-IS . . . . . . . . . . 4
2.1. The MAC-Reachability TLV . . . . . . . . . . . . . . . . . 5 2.1. The MAC-Reachability TLV . . . . . . . . . . . . . . . . . 4
2.2. The Group Address TLV . . . . . . . . . . . . . . . . . . 6 2.2. The Group Address TLV . . . . . . . . . . . . . . . . . . 6
2.2.1. The Group MAC Address sub-TLV . . . . . . . . . . . . 6 2.2.1. The Group MAC Address sub-TLV . . . . . . . . . . . . 6
2.2.2. The Group IP Address sub-TLV . . . . . . . . . . . . . 8 2.2.2. The Group IP Address sub-TLV . . . . . . . . . . . . . 8
2.2.3. The Group IPv6 Address sub-TLV . . . . . . . . . . . . 10 2.2.3. The Group IPv6 Address sub-TLV . . . . . . . . . . . . 9
2.3. Multi Topology aware Port Capability TLV . . . . . . . . . 12 2.2.4. The SPBV MAC Address sub-TLV . . . . . . . . . . . . . 11
2.3. Multi Topology aware Port Capability TLV . . . . . . . . . 13
2.3.1. The Special VLANs and Flags sub-TLV . . . . . . . . . 13 2.3.1. The Special VLANs and Flags sub-TLV . . . . . . . . . 13
2.3.2. Enabled VLANs sub-TLV . . . . . . . . . . . . . . . . 14 2.3.2. Enabled VLANs sub-TLV . . . . . . . . . . . . . . . . 14
2.3.3. Appointed Forwarders sub-TLV . . . . . . . . . . . . . 14 2.3.3. Appointed Forwarders sub-TLV . . . . . . . . . . . . . 15
2.3.4. Hop-by-Hop Options (HBHOPT) sub-TLV . . . . . . . . . 15 2.3.4. Hop-by-Hop Options (HBHOPT) sub-TLV . . . . . . . . . 17
2.3.5. Base VLAN-Identifiers sub-TLV . . . . . . . . . . . . 16 2.3.5. Base VLAN-Identifiers sub-TLV . . . . . . . . . . . . 18
2.4. Sub-TLVs for the Router Capability TLV . . . . . . . . . . 18 2.3.6. SPB Digest sub-TLV . . . . . . . . . . . . . . . . . . 19
2.4.1. The TRILL Version sub-TLV . . . . . . . . . . . . . . 18 2.3.7. Site Identifier sub-TLV . . . . . . . . . . . . . . . 20
2.4.2. The Nickname sub-TLV . . . . . . . . . . . . . . . . . 18 2.3.8. Site Group IPv4 sub-TLV . . . . . . . . . . . . . . . 20
2.4.3. The Trees sub-TLV . . . . . . . . . . . . . . . . . . 19 2.3.9. Site Group IPv6 sub-TLV . . . . . . . . . . . . . . . 21
2.4.4. The Tree Roots Identifier Sub-TLV . . . . . . . . . . 20 2.3.10. Adjacency Server IPv4 sub-TLV . . . . . . . . . . . . 21
2.4.5. The Tree Used Identifier Sub-TLV . . . . . . . . . . . 21 2.3.11. Adjacency Server IPv6 sub-TLV . . . . . . . . . . . . 22
2.4.6. Interested VLANs and Spanning Tree Roots sub-TLV . . . 22 2.4. Sub-TLVs for the Router Capability TLV . . . . . . . . . . 22
2.4.7. The VLAN Group sub-TLV . . . . . . . . . . . . . . . . 23 2.4.1. The TRILL Version sub-TLV . . . . . . . . . . . . . . 22
2.4.8. The Ingress-to-Egress Options (ITEOPT) sub-tlv . . . . 24 2.4.2. The Nickname sub-TLV . . . . . . . . . . . . . . . . . 23
2.5. Multi Topology Aware Capability TLV . . . . . . . . . . . 25 2.4.3. The Trees sub-TLV . . . . . . . . . . . . . . . . . . 24
2.5.1. SPB Instance sub-TLV . . . . . . . . . . . . . . . . . 26 2.4.4. The Tree Root Identifiers Sub-TLV . . . . . . . . . . 25
2.5.2. Service Identifier and Unicast Address sub-TLV . . . . 29 2.4.5. The Trees Used Identifiers Sub-TLV . . . . . . . . . . 26
2.6. SPB Link Metric sub-tlv . . . . . . . . . . . . . . . . . 30 2.4.6. Interested VLANs and Spanning Tree Roots sub-TLV . . . 26
3. The Multicast Group PDU . . . . . . . . . . . . . . . . . . . 31 2.4.7. The VLAN Group sub-TLV . . . . . . . . . . . . . . . . 28
3.1. The Multicast Group Partial Sequence Number PDU . . . . . 32 2.4.8. The Ingress-to-Egress Options (ITEOPT) sub-TLV . . . . 29
3.2. The Multicast Group Complete Sequence Number PDU . . . . . 32 2.4.9. VLAN Mapping (VMAP) sub-TLV . . . . . . . . . . . . . 30
3.3. Enhancements to the flooding process . . . . . . . . . . . 32 2.5. Multi Topology Aware Capability TLV . . . . . . . . . . . 31
3.4. Enhancements to the maximum sequence number reached . . . 33 2.5.1. SPB Instance sub-TLV . . . . . . . . . . . . . . . . . 32
4. Considerations for Using L2 Information in IS-IS . . . . . . . 33 2.5.2. SPBM Service Identifier and Unicast Address sub-TLV . 34
4.1. Building SPF Trees with Layer 2 Information . . . . . . . 33 2.6. Sub-TLVs of the Extended Reachability TLV . . . . . . . . 35
4.2. Designated Intermediate Routers . . . . . . . . . . . . . 33 2.6.1. SPB Link Metric sub-TLV . . . . . . . . . . . . . . . 35
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 2.6.2. MTU sub-TLV . . . . . . . . . . . . . . . . . . . . . 36
6. Security Considerations . . . . . . . . . . . . . . . . . . . 34 2.7. TRILL Neighbor TLV . . . . . . . . . . . . . . . . . . . . 37
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 2.8. The Group Membership Active Source TLV . . . . . . . . . . 38
8. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 35 2.8.1. The Group MAC Active Source sub-TLV . . . . . . . . . 39
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.8.2. The Group IP Active Source sub-TLV . . . . . . . . . . 41
9.1. Normative References . . . . . . . . . . . . . . . . . . . 37 2.8.3. The Group IPv6 Active Source sub-TLV . . . . . . . . . 42
9.2. Informative References . . . . . . . . . . . . . . . . . . 37 2.9. PDU Extensions to IS-IS . . . . . . . . . . . . . . . . . 44
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.9.1. The Multicast Group PDU . . . . . . . . . . . . . . . 44
2.9.2. The TRILL-Hello PDU . . . . . . . . . . . . . . . . . 46
2.9.3. The MTU PDU . . . . . . . . . . . . . . . . . . . . . 47
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 48
4. Security Considerations . . . . . . . . . . . . . . . . . . . 48
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
6. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 51
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.1. Normative References . . . . . . . . . . . . . . . . . . . 52
7.2. Informative References . . . . . . . . . . . . . . . . . . 52
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 53
1. Overview 1. Overview
There are a number of systems (for example, [RBRIDGES], [802.1aq]) There are a number of systems (for example, [RBRIDGES], [802.1aq])
that use layer 2 addresses carried in a link state routing protocol, that use layer 2 addresses carried in a link state routing protocol,
specifically IS-IS [IS-IS] [RFC1195], to provide true layer 2 routing specifically IS-IS [IS-IS] [RFC1195], to provide true layer 2
in specific environments. This document specifies a set of TLVs and routing. This document specifies a set of TLVs and sub-TLVs to be
sub-TLVs to be added to [IS-IS] level 1 PDUs, and three new PDU added to [IS-IS] level 1 PDUs, and six new PDU types, to support
types, to support these proposed systems. Some of these TLVs are these proposed systems. Some of these TLVs are generic layer 2
generic layer 2 additions and some are specific to [RBRIDGES] or to additions and some are specific to [RBRIDGES] or to [802.1aq]. This
[802.1aq]. This draft does not propose any new forwarding mechanisms draft does not propose any new forwarding mechanisms using this
using this additional information carried within IS-IS. additional information carried within IS-IS.
This document specifies additional TLVs and sub-TLVs, to carry This document specifies additional TLVs and sub-TLVs, to carry
unicast and multicast attached address information. It also proposes unicast and multicast attached address information. It also proposes
additional TLVs and sub-TLVs to carry information as required by the additional TLVs and sub-TLVs to carry information as required by the
IETF RBridge and IEEE 802.1aq protocols. IETF TRILL and IEEE 802.1aq protocols.
This document specifies three new IS-IS PDUs, the Multicast Group This document specifies six 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 PDUs. The TRILL-Hello PDU
provides the subnet specific layer of IS-IS for TRILL links. The
MTU-probe and MTU-ack PDUs provide a means of testing link MTU.
1.1. Terminology 1.1. Terminology
The term "Hello" or "Hello PDU" in this document, when not further The term "Hello" or "Hello PDU" in this document, when not further
qualified, includes both LAN IIH PDU and P2P IIH PDU. qualified, includes the TRILL IIH PDU, the LAN IIH PDU and the P2P
IIH PDU.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
2. TLV and sub-TLV Enhancements to IS-IS 2. PDU, TLV and sub-TLV Enhancements to IS-IS
In this section we describe the enhancements that are being proposed In this section we describe the enhancements that are being proposed
for the TLV and sub-TLVs as needed by Layer-2 technologies. for the PDUs, TLVs 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:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Type= MAC-RI | (1 byte) | Type= MAC-RI | (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+
| Confidence | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Topology-Id/ Nickname-Id | (2 bytes) | Topology-Id/ Nickname-Id | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Confidence | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | VLAN-ID | (2 bytes) | RESV | VLAN-ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (1) (6 bytes) | | MAC (1) (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. | | ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (N) (6 bytes) | | 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 bytes contained in the value field given o Length: Total number of bytes contained in the value field given
by 5 + 6*n bytes. by 5 + 6*n bytes.
o Confidence: This carries an 8-bit quantity indicating the o Confidence: This carries an 8-bit quantity indicating the
confidence level in the MAC addresses being transported. Whether confidence level in the MAC addresses being transported. Whether
this field is used, and its semantics if used, are further defined 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 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. MUST be set to zero on transmission and be ignored on receipt.
o Topology-Id/Nickname-Id: Depending on the technology in which it o Topology-Id/Nickname-Id: Depending on the technology in which it
is used, this carries the topology-id or nickname-id. When this is used, this carries the topology-id or nickname-id. When this
field is set to zero this implies that the MAC addresses are field is set to zero this implies that the MAC addresses are
reachable across all topologies or across all nicknames of the reachable across all topologies or across all nicknames of the
originating IS. originating IS.
o RESV: Must be sent as zero on transmission and is ignored on o RESV: Must be sent as zero on transmission and is ignored on
receipt. receipt.
skipping to change at page 6, line 24 skipping to change at page 6, line 18
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 bytes contained in the value field, which o Length: Total number of bytes contained in the value field, which
includes the length of the sub-tlvs carried in this TLV. includes the length of the sub-TLVs carried in this TLV.
o sub-TLVs: The Group Address TLV value contains sub-TLVs formatted o sub-TLVs: The Group Address TLV value contains sub-TLVs formatted
as described in [RFC5305]. The sub-TLVs for this TLV are as described in [RFC5305]. The sub-TLVs for this TLV are
specified in the following subsections. 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 sub-TLV type 1 The Group MAC Address (GMAC-ADDR) sub-TLV is IS-IS sub-TLV type 1
within the GADDR TLV and has 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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Topology-Id/ Nickname-Id | (2 bytes) | Topology-Id/ Nickname-Id | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Confidence | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | VLAN-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 7, line 49 skipping to change at page 7, line 27
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-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 bytes contained in the value field. o Length: Total number of bytes contained in the value field.
o Confidence: This carries an 8-bit quantity indicating the o Confidence: This carries an 8-bit quantity indicating the
confidence level in the MAC addresses being transported. Whether confidence level in the MAC addresses being transported. Whether
this field is used, and its semantics if used, are further defined 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 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. MUST be set to zero on transmission and be ignored on receipt.
o Topology-Id/Nickname-Id: Depending on the technology in which it o Topology-Id/Nickname-Id: Depending on the technology in which it
is used, this carries the topology-id or nickname-id. When this is used, this carries the topology-id or nickname-id. When this
field is set to zero this implies that the MAC addresses are field is set to zero this implies that the MAC addresses are
reachable across all topologies or across all nicknames of the reachable across all topologies or across all nicknames of the
originating IS. originating IS.
o RESV: Must be sent as zero on transmission and is ignored on o RESERVED: Must be sent as zero on transmission and is ignored on
receipt. receipt.
o VLAN-ID: This carries a 12 bit VLAN identifier that is valid for 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 all subsequent MAC addresses in this TLV, or the value zero if no
VLAN is specified. 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 is
by the number of sources, each of length 1 byte. It then has a followed by the number of sources, each of length 1 byte. It then
48-bit multicast Group Address followed by 48-bit source MAC has a 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. If the number of sources do not fit in a single sub-tlv, 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 it is permitted to have the same group address repeated with
different source addresses repeated in different sub-tlvs. different source addresses in another sub-TLV of another instance
of the Group Address TLV.
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:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
skipping to change at page 10, line 11 skipping to change at page 9, line 21
this field is used, and its semantics if used, are further defined 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 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. must be set to zero on transmission and be ignored on receipt.
o Topology-Id/Nickname-Id: Depending on the technology in which it o Topology-Id/Nickname-Id: Depending on the technology in which it
is used, this carries the topology-id or nickname-id. When this is used, this carries the topology-id or nickname-id. When this
field is set to zero this implies that the MAC addresses are field is set to zero this implies that the MAC addresses are
reachable across all topologies or across all nicknames of the reachable across all topologies or across all nicknames of the
originating IS. originating IS.
o RESV: Must be sent as zero on transmission and is ignored on o RESERVED: Must be sent as zero on transmission and is ignored on
receipt. receipt.
o VLAN-ID: This carries a 12 bit VLAN identifier that is valid for 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 all subsequent MAC addresses in this TLV, or the value zero if no
VLAN is specified. 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 is
by the number of sources, each of length 1 byte. It is followed followed by the number of sources, each of length 1 byte. It is
by a 32-bit IPv4 Group Address followed by 32-bit source IPv4 followed by a 32-bit IPv4 Group Address followed by 32-bit source
addresses. If the number of sources do not fit in a single sub- IPv4 addresses. If the number of sources do not fit in a single
tlv, it is permitted to have the same group address repeated with sub-TLV, it is permitted to have the same group address repeated
different source addresses repeated in different sub-tlvs. with different source addresses repeated in another sub-TLV of
another instance of the Group Address TLV.
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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Topology-Id/ Nickname-Id | (2 bytes) | Topology-Id/ Nickname-Id | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Confidence | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | VLAN-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 12, line 8 skipping to change at page 11, line 8
this field is used, and its semantics if used, are further defined 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 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. must be set to zero on transmission and be ignored on receipt.
o Topology-Id/Nickname-Id: Depending on the technology in which it o Topology-Id/Nickname-Id: Depending on the technology in which it
is used, this carries the topology-id or nickname-id. When this is used, this carries the topology-id or nickname-id. When this
field is set to zero this implies that the MAC addresses are field is set to zero this implies that the MAC addresses are
reachable across all topologies or across all nicknames of the reachable across all topologies or across all nicknames of the
originating IS. originating IS.
o RESV: Must be sent as zero on transmission and is ignored on o RESERVED: Must be sent as zero on transmission and is ignored on
receipt. receipt.
o VLAN-ID: This carries a 12 bit VLAN identifier that is valid for 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 all subsequent MAC addresses in this TLV, or the value zero if no
VLAN is specified. 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 is
by the number of sources, each of length 1 byte. It is followed followed by the number of sources, each of length 1 byte. It is
by a 128-bit multicast IPv6 Group Address followed by 128-bit followed by a 128-bit multicast IPv6 Group Address followed by
source IPv6 addresses. If the number of sources do not fit in a 128-bit source IPv6 addresses. If the number of sources do not
single sub-tlv, it is permitted to have the same group address fit in a single sub-TLV, it is permitted to have the same group
repeated with different source addresses repeated in different address repeated with different source addresses repeated in
sub-tlvs. another sub-TLV in another instance of the Group Address TLV.
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.2.4. The SPBV MAC Address sub-TLV
The SPBV MAC Address (SPBV-MAC-ADDR) TLV is IS-IS sub-TLV type 4 and
has the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|# MAC Addresses| reserved |SR | SPVID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|R| Reserved | MAC Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | T|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | T|R| Reserved | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type, set to 4 (SPBV-MAC-ADDR).
o Length: Total number of bytes contained in the value field.
o Number of MAC address (1 byte): Number of MAC address must be set.
It is the number of addresses associated with the SPVID that
follow. This is the number of addresses associated with this
SPVID.
o SR bits (2-bits) The SR bits are the service requirement parameter
from MMRP. The service requirement parameters have the value 0
(Forward all Groups) (and 1 (Forward All Unregistered Groups)
defined. However this attribute may also be missing. So the SR
bits are defined as 0 not declared, 1 Forward all Groups and 2
Forward All Unregistered Groups.
o SPVID (12-bits) The SPVID and by association Base VID and the ECT-
ALGORITHM and SPT Set that the MAC addresses defined below will
use. If the SPVID is not allocated the SPVID Value is 0. Note
that if the ECT-Algorithm in use is Spanning Tree Algorithm this
value should be populated with the Base VID and the MAC can be
populated.
o T Bit (1-bit) This is the Transmit allowed Bit for the following
group MAC address. This is an indication that SPBV Group MAC
Address with SPVID of source should be populated (for the bridge
advertising this Group MAC), and installed in the FDB of transit
bridges, when the bridge computing the trees is on the
corresponding ECT-ALGORITHM shortest path between the bridge
advertising this MAC with the T bit set, and any receiver of this
Group MAC Address. A bridge that does not advertise this bit set
for an Group MAC Address should have no forwarding state installed
for traffic originating from that bridge on other transit bridges
in the network.
o R Bit (1-bit) This is the Receive allowed Bit for the following
Group MAC Address. This is an indication that SPBV Group MAC
Addresses as receiver should be populated (for bridges advertising
this Group MAC Address with the T bit set) and installed when the
bridge computing the trees lies on the corresponding shortest path
for this ECT-ALGORITHM between this receiver and any transmitter
on this Group MAC Address. An entry that does not have this bit
set for a Group MAC Address is prevented from receiving on this
Group MAC Address because transit bridges will not install
multicast forwarding state towards it in their FDBs or the traffic
is explicitly filtered.
o MAC Address (48-bits) The MAC is the address is either a group
address or an individual address. When the MAC address is a group
address declares this bridge as part of the multicast interest for
this destination MAC address. Multicast trees can be efficiently
constructed for destination by populating multicast FDB entries
for the subset of the shortest path tree that connects the bridges
supporting the multicast address. This replaces the function of
MMRP for SPTs. The T and R bits above have meaning if this is a
group address. Individual addresses are populated only as if the
R bit was not set.
The SPBV-MAC-ADDR sub-TLV is carried within the GADDR TLV and MUST be
carried in a standard Level 1 link state MGROUP PDU.
2.3. Multi Topology aware Port Capability TLV 2.3. Multi Topology aware Port Capability TLV
The Multi Topology aware Port Capability (MT-PORT-CAP) is an IS-IS The Multi Topology aware Port Capability (MT-PORT-CAP) is an IS-IS
TLV type 143 [TBD], and has the following format: TLV type 143 [TBD], 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=MT PORTCAP| Length |O|R|R|R| Topology Identifier | |Type=MT PORTCAP| Length |O|R|R|R| Topology Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLVs | | sub-TLVs |
skipping to change at page 13, line 4 skipping to change at page 13, line 34
o Length: Total number of bytes contained in the value field, o Length: Total number of bytes contained in the value field,
including the length of the sub-TLVs carried in this TLV. including the length of the sub-TLVs carried in this TLV.
o O bit: The overload bit that follows the semantics associated with o O bit: The overload bit that follows the semantics associated with
an overloaded intermediate system. an overloaded intermediate system.
o Topology Identifier: MT ID is a 12-bit field containing the MT ID 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 of the topology being announced. This field when set to zero
implies that it is being used to carry base topology information. 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, In TRILL this value is set to ZERO, however, in IEEE SPB and SPBB,
it may be non-zero. it may be non-zero.
o sub-TLVs: The MT aware Port Capabilities TLV value contains sub- o sub-TLVs: The MT aware Port Capabilities TLV value contains sub-
TLVs formatted as described in [RFC5305]. They are defined in the TLVs formatted as described in [RFC5305]. They are defined in the
next sections. next sections.
The MT aware PORT-CAP-TLV MUST be carried only within a LAN IIH PDU, The MT-PORT-CAP TLV may occur multiple times, and is carried only
or a P2P IIH PDU. It may occur multiple times in a Hello PDU. within a IIH 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 and Flags) sub-TLV MUST appear The Special VLANs and Flags (VLAN and Flags) sub-TLV MUST appear in a
exactly once in a MT aware Port Capability TLV in every LAN IIH PDU. MT-PORT-CAP TLV. This is carried only once in every TRILL IIH PDU.
It has the following format: It has the following format:
0 1 2 3 4 - 15 16 - 19 20 - 31
+-+-+-+-+-+-+-+-+
|Type=VLAN Flags|
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+------+-------------------------+
| Port ID (2 bytes) |
+----+----+----+----+------------+----------+------------+ +----+----+----+----+------------+----------+------------+
| AF | AC | VM | BY | Outer.VLAN | Reserved | Desig.VLAN | | AF | AC | VM | BY | Outer.VLAN | Reserved | Desig.VLAN |
+----+----+----+----+------------+----------+------------+ +----+----+----+----+------------+----------+------------+
0 1 2 3 4 - 15 16 - 19 20 - 31
o Type: TLV Type, set to VLAN and Flags sub-TLV 1 [TBD]. o Type: TLV Type, set to VLAN and Flags sub-TLV 1 [TBD].
o Length: 4 - Number of bytes contained in the value field. o Length: 6 - Number of bytes contained in the value field.
o Port ID: An ID for the port on which the enclosing TRILL IIH PDU
is being sent. The transmitting RBridge assigns this ID such that
each of its ports has an ID different from all of its other ports.
o The first and second bytes have a copy of the Outer VLAN ID 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 byte 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 byte gives the lower VLAN ID bits. the second byte gives the lower VLAN ID bits.
o The upper 4 bits of the first byte are flag bits as shown. The AF o The upper 4 bits of the first byte are flag bits as shown. The AF
bit, if one, indicates that the sending Intermediate System bit, if one, indicates that the sending Intermediate System
believes it is Appointed Forwarder for the VLAN and port on which believes it is Appointed Forwarder for the VLAN and port on which
the Hellos was sent. The AC bit, if one, indicates that the the Hello was sent. The AC bit, if one, indicates that the
sending port is configured as an access port. The VM bit, if a sending port is configured as an access port. The VM bit, if a
one, indicates that the sending Intermediate System has detected one, indicates that the sending Intermediate System has detected
VLAN mapping within the link. The BY bit, if set, indicates VLAN mapping within the link. The BY bit, if set, indicates
bypass psuedonode. bypass psuedonode.
o The third and forth bytes give the Designated VLAN for the link. o The third and forth bytes give the Designated VLAN for the link.
The lower 4 bits of the third byte give the upper ID bits of the 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. 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 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 and Flags sub-TLV is carried within the MT aware PORT-CAP The VLAN and Flags sub-TLV is carried within the MT-PORT-CAP TLV. It
TLV and MUST be carried in LAN IIH PDU. It MUST NOT be carried MUST be carried only once in a TRILL IIH PDU. It MUST NOT be carried
within a P2P IIH PDU. within a LAN or 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.
+-+-+-+-+-+-+-+-+
|Type=EnabledVLAN|
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Resv | Start Vlan Id | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vlan bit-map....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type, set to Enabled VLANs sub-TLV 2 [TBD]. o 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 bytes. The third and o The minimum size of the value is 3 bytes. The third and
subsequent bytes provide a bit map of enabled VLANs starting at subsequent bytes provide a bit map of enabled VLANs starting at
the VLAN ID indicated in the first two bytes. The lower order the VLAN ID indicated in the first two bytes. The lower order
four bits of the first byte give the upper bits of the starting four bits of the first byte give the upper bits of the starting
VLAN ID and the second byte gives the lower bits of that VLAN ID. 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 The upper four bits of the first byte are reserved and MUST be
skipping to change at page 14, line 35 skipping to change at page 15, line 40
alternatively, as 0x00 0x00 0x40 0x02. alternatively, as 0x00 0x00 0x40 0x02.
This sub-TLV may occur more than once in a 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-byte 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 MT aware PORT-CAP TLV The Enabled VLAN sub-TLV is carried only within the MT-PORT-CAP TLV.
and MUST be carried in LAN IIH PDU. It MUST NOT be carried within a If present, it MUST be carried in TRILL IIH PDU. It MUST NOT be
P2P IIH PDU. carried within a LAN IIH or 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
Designated Intermediate System can inform other Intermediate Systems Designated Intermediate System can inform other Intermediate Systems
on the link that they are the designated VLAN-x forwarder for that on the link that they are the designated VLAN-x forwarder for that
link for one or more ranges of VLAN IDs. link for one or more ranges of VLAN IDs.
o Type: sub-TLV Type, set to Enabled VLANs sub-TLV 3 [TBD]. o Type: sub-TLV Type, set to Appointed Forwarders sub-TLV 3 [TBD].
o Length: The size of the value is 6*n bytes where there are n 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 appointments. Each 6-byte part of the value is formatted as
follows: follows:
+-+-+-+-+-+-+-+-+
|Type=App Frwrdr|
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+----------------+-----+-----+---------+-----+----+---------+ +----------------+-----+-----+---------+-----+----+---------+
| byte 1 - 2 | byte 3 | byte 4 | byte 5 | byte 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 Intermediate System is specified by its o The appointed forwarder Intermediate System is specified by its
nickname in the first two bytes. 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
skipping to change at page 15, line 32 skipping to change at page 16, line 42
end station service enabled on VLANs 100, 101, 199, and 200 (and end station service enabled on VLANs 100, 101, 199, and 200 (and
possibly other VLANs less than 100 or greater than 200), but not possibly other VLANs less than 100 or greater than 200), but not
enabled for VLANs 102 through 198. It could be appointed forwarder enabled for VLANs 102 through 198. It could be appointed forwarder
for these four VLANs through either (1) a single 6-byte value for these four VLANs through either (1) a single 6-byte value
sequence with start and end VLAN IDs of 100 and 200, or (2) a 12-byte sequence with start and end VLAN IDs of 100 and 200, or (2) a 12-byte
value sequence with start and end VLAN IDs of 100 and 101 in the value sequence with start and end VLAN IDs of 100 and 101 in the
first part and 199 and 200 in the second part. first part and 199 and 200 in the second part.
An Intermediate System's nickname may occur as appointed forwarder An Intermediate System's nickname may occur as appointed forwarder
for multiple VLAN ranges within the same or different Port Capability for multiple VLAN ranges within the same or different Port Capability
TLVs within a Designated Intermediate Systems's Hello. In the TLVs within a TRILL Hello. In the absence of appointed forwarder
absence of appointed forwarder sub-TLVs referring to a VLAN, the sub-TLVs referring to a VLAN, the Designated Intermediate System acts
Designated Intermediate System acts as the appointed forwarder for as the appointed forwarder for that VLAN if end station service is
that VLAN if end station service is enabled. enabled.
The Appointed Forwarder sub-TLV is carried within the MT aware PORT- The Appointed Forwarder sub-TLV is carried within the MT-PORT-CAP
CAP TLV and MUST be carried in a LAN IIH PDU. This MUST NOT be TLV. If present, it MUST be carried in a TRILL IIH PDU. This MUST
carried in a P2P IIH PDU. NOT be carried in a LAN IIH PDU or a P2P IIH PDU.
2.3.4. Hop-by-Hop Options (HBHOPT) sub-TLV 2.3.4. Hop-by-Hop Options (HBHOPT) sub-TLV
By including this sub-TLV within one or more MT aware Port Capability By including this sub-TLV within one or more MT aware Port Capability
TLVs in its Hellos, an Intermediate System can advertise the Hop-by- TLVs in its Hellos, an Intermediate System can advertise the Hop-by-
Hop options it supports on the port through which it sends the Hello. Hop options it supports on the port through which it sends the Hello.
This sub-TLV may appear zero or more times within a MT aware Port 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, Capability TLV. By default, in the absence of any HBHOPT sub-TLVs,
no Hop-by-Hop options are supported. no Hop-by-Hop options are supported.
There are two types of Hop-by-Hop option encoding within the TRILL There are two types of Hop-by-Hop option encoding within the TRILL
Header: bit options and TLV encoded options. Header: bit options and TLV encoded options.
The bit-encoded options supported are indicated by an HBHOPT sub-TLV 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 of length 3: an initial value byte of 0x00 followed by two bytes in
which each bit indicates that the corresponding bit option is which each bit indicates that the corresponding bit option is
implemented; in those four bytes the top two bits (0xC0000000) are implemented; in those two bytes the top two bits (0xC000) are
critical option summary bits that all RBridges MUST understand. critical option summary bits that all RBridges MUST understand;
Those two bits are reserved in the HBHOPT sub-TLV and must be sent as therefore support for these bits need not be advertised. Those two
zero are ignored on receipt. 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 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 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 option. Such HBHOPT sub-TLVs may have additional value bytes further
indicating how the option is supported as specified with the option's indicating how the option is supported as specified with the option's
definition, for example a list of supported security algorithms. definition, for example a list of supported security algorithms.
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Type = HBHOPT | | Type = HBHOPT |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
skipping to change at page 17, line 9 skipping to change at page 18, line 19
use. This information should be the same on all bridges in the use. This information should be the same on all bridges in the
topology identified by MT-PORT-CAP TLV it is being carried. topology identified by MT-PORT-CAP TLV it is being carried.
Discrepancies between neighbours with respect to this sub-TLV are Discrepancies between neighbours with respect to this sub-TLV are
temporarily allowed but the Base-VID must agree and use a spanning temporarily allowed but the Base-VID must agree and use a spanning
tree algorithm. tree algorithm.
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Type = B-VID | |Type = B-VID |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+
|M|B| RESERVED | (1 byte)
+-+-+-+-+-+-+-+-+-------------------------------- +-+-+-+-+-+-+-+-+--------------------------------
| VID Tuple (1) (4 bytes) | | ECT - VID Tuple (1) (6 bytes) |
+-----------------------------------------------+ +-----------------------------------------------+
| ......................... | | ......................... |
+-----------------------------------------------+ +-----------------------------------------------+
| VID Tuples (N) (4 bytes) | | ECT - VID Tuples (N) (6 bytes) |
+-----------------------------------------------+ +-----------------------------------------------+
o Type: sub-TLV Type, set to Base-VALN-ID sub-TLV 5 [TBD]. 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 o Length: The size of the value is ECT-VID Tuples*6 bytes. Each
4-byte part of the N-VID tuple is formatted as follows: 6-byte part of the ECT-VID tuple is formatted as follows:
0 1 - 3 4 - 15 16 - 19 20 - 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+----------+-------+-----------+------------+ | ECT - Algorithm (32 bits) |
|A| Reserved | VID | Algorithm | B-VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+----------+-------+-----------+------------+ | Base VID (12 bits) |U|M|RES|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o The M bit when set indicates that the Mode is Shortest Path VIDs o ECT-ALGORITHM (4 bytes) The ECT-ALGORITHM is advertised when the
one VID per tree. When clear this bit indicates that this is bridge supports a given ECT-ALGORITHM (by OUI/Index) on a given
using single VIDs. Neighboring bridges must have matching Base VID
configuration or the adjacency is rejected.
o The B Bit when set indicates this is Backbone Bridging o Base VID (12-bits) The Base-VID that is associate with the SPT
alternatively when clear this bit indicates this is Shortest path Set.
bridging.
o Combinations of the M and B bits are specified in the [IEEE o Use-Flag (1-bit) The Use-flag is set if this bridge, or any bridge
802.1aq]. that this bridge sees is currently using this ECTALGORITHM and
Base VID.
o Algorithm: Specifies the tie breaking algorithm to be used for o M-Bit (1-bit) The M-bit indicates if this is SPBM or SPBV mode.
this VID. Currently only the following values are supported:
* ALG = 0 a spanning tree. The Base VLAN-Identifier sub-TLV is carried within the MT-PORT-CAP
TLV and this is carried in a IIH PDU.
* ALG = 1 the Low PATHID algorithm is used for this VID. 2.3.6. SPB Digest sub-TLV
* ALG = 2 the High PATHID algorithm is used. 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.
o A bit when set declares this an SPVID with auto allocation. +-+-+-+-+-+-+-+-+
|Type =SPBDigest|
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MCID (50 Bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Aux MCID (50 Bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Agreement Digest (32 Bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|RES | A| D|
+-+-+-+-+-+-+-+-+
o VID is the VID for which the given algorithm applies, see [IEEE o Type: sub-TLV Type, set to SPB Digest sub-TLV 6 [TBD].
802.1aq].
o B-VID is the B-VID for which the given algorithm applies, see o Length: The size of the value defined below.
[IEEE 802.1aq].
o The "Reserved" fields MUST be sent as zero and ignored on receipt. o MCID (50-bytes) The complete MCID defined in IEEE 802.1Q which
identifies an SPT Region.
The Base VLAN-Identifier sub-TLV is carried within the MT aware PORT- o Aux MCID (50-bytes) The complete MCID defined in IEEE 802.1Q which
CAP TLV and this is carried in a IIH PDU. identifies an SPT Region. The aux MCID allows SP Regions to be
migrated allocating new VLAN to FID Mappings.
o Agreement Digest (32-bytes) This digest is use to determine when
IS-IS is synchronized between neighbors.
o A (2 bits) The agreement number 0-3 which aligns with BPDUs
agreement number concept. When the Agreement Digest for this node
changes this number is updated and sent in the hello.
o D (2 bits) The discarded agreement number 0-3 which aligns with
BPDUs agreement number concept. When the Agreement Digest for
this node changes this number is updated. Once an Agreement has
been sent it is considered outstanding until a matching or more
recent Discarded Agreement Number is received.
The SPB Digest sub-TLV is carried within the MT-PORT-CAP TLV and this
is carried in a IIH PDU.
2.3.7. Site Identifier sub-TLV
The site identifier sub-TLV carries information about the site this
device belongs to.
+-+-+-+-+-+-+-+-+
|Type = SiteCap |
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| System ID (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cluster ID (2 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags (1 byte)|
+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type, set to Site Identifier sub-TLV 250 [TBD].
o Length: The size of the value.
o System Id: The system-id of the site.
o Cluster Id: The cluster-id within the site.
o Flags: Indicates unicast reachability.
2.3.8. Site Group IPv4 sub-TLV
+-+-+-+-+-+-+-+-+
|Type=SiteGrpIP |
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type, set to Site Group IP sub-TLV 251 [TBD].
o Length: The size of the value.
o Value: The list of IPv4 addresses used by the site.
2.3.9. Site Group IPv6 sub-TLV
+-+-+-+-+-+-+-+-+
|Type=SiteGrpIPv6|
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type, set to Site Group IPv6 sub-TLV 252 [TBD].
o Length: The size of the value.
o Value: The list of IPv6 addresses used by the site.
2.3.10. Adjacency Server IPv4 sub-TLV
+-+-+-+-+-+-+-+-+
|Type = ASIPv4 |
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags(1 byte)|
+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type, set to Adjacency Server IP sub-TLV 253 [TBD].
o Length: The size of the value.
o Value: The list of IPv4 addresses used by the site.
o Flags: Indicates unicast reachability.
2.3.11. Adjacency Server IPv6 sub-TLV
+-+-+-+-+-+-+-+-+
|Type = ASIPv6 |
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags(1 byte)|
+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type, set to Adjacency Server IPv6 sub-TLV 254
[TBD].
o Length: The size of the value.
o Value: The list of IPv6 addresses used by the site.
o Flags: Indicates unicast reachability.
2.4. Sub-TLVs for the Router Capability TLV 2.4. Sub-TLVs for the Router Capability TLV
The Router Capability TLV is an optional TLV [RFC 4971] that may be The Router Capability TLV is an optional TLV [RFC 4971] that may be
generated by the originating Intermediate System. We specify these generated by the originating Intermediate System. We specify these
additional sub-TLVs that can be carried in it. These sub-TLVs additional sub-TLVs that can be carried in it. These sub-TLVs
announce the capabilities of the Intermediate System for the entire announce the capabilities of the Intermediate System for the entire
IS-IS routing domain. IS-IS routing domain.
2.4.1. The TRILL Version sub-TLV 2.4.1. The TRILL Version sub-TLV
skipping to change at page 18, line 36 skipping to change at page 23, line 4
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: sub-TLV Type, set to 5 (TRILL-VER). o Type: sub-TLV Type, set to 5 (TRILL-VER).
o Length: 2 - Total number of bytes contained in the TLV. o Length: 2 - Total number of bytes contained in the vlaue.
o Reserved: Set to zero on transmission and ignored on receipt. 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 Nickname sub-TLV 2.4.2. The Nickname sub-TLV
The Nickname (NICK) sub-TLV carries information about the nicknames The Nickname (NICKNAME) sub-TLV carries information about the
of the advertising device, along with information about its priority nicknames of the advertising device, along with information about its
to hold those nicknames. The Nickname sub-TLV MUST be carried within priority to hold those nicknames. The Nickname sub-TLV MUST be
the Router CAPABILITY TLV in a level-1 non-pseudo-node LSP generated carried within a Router CAPABILITY TLV in a level-1 LSP generated by
by the originating IS. the originating IS. Multiple instances of this sub-TLV are allowed
to be carried.
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Type = NICKNAME| |Type = NICKNAME|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NICKNAME RECORDS (1) | | NICKNAME RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. | | ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NICKNAME RECORDS (N) | | NICKNAME RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each nickname record is of the form: where each nickname record is of the form:
+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+
| Priority | (1 byte) |Nickname Priority| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree Root Priority | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname | (2 bytes) | Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to 6 (NICK). o Type: TLV Type, set to 6 (NICKNAME).
o Length: Total number of bytes contained in the TLV. o Length: 5*N, where N is the number of nickname records present.
o Priority: Set to application dependent values. o Nickname Priority: Priority with which this node holds this
nickname.
o Tree Root Priority: This is an unsigned 16-bit integer that gives
the value of the priority with which this nickname wants to be the
highest priority root node in the Layer-2 domain.
o Nickname: This is an unsigned 16-bit integer that gives device o Nickname: This is an unsigned 16-bit integer that gives device
identifier or alias. identifier or alias.
Each nickname record consists of a one-byte priority set to Each nickname record consists of a one-byte priority set to
application dependent values, and two bytes of device identifier or application dependent values, two bytes of tree root priority and two
alias (i.e., actual nickname). bytes of device identifier or alias (i.e., actual nickname).
2.4.3. The Trees sub-TLV 2.4.3. The Trees sub-TLV
The Trees sub-TLV MUST occur only once and can be carried within the The Trees sub-TLV MUST occur only once and is carried within the
Router CAPABILITY TLV in a level-1 non-pseudo-node LSP generated by Router CAPABILITY TLV in a level-1 non-pseudo-node LSP generated by
the originating IS. Each device announces four numbers: its own the originating IS. Each device announces three numbers: the number
priority to be a multi-destination frame distribution tree root; the of trees it dictates that all other Intermediate Systems in the
number of trees it dictates that all other Intermediate Systems in campus compute if it is the highest priority tree root; the maximum
the campus compute if it is the highest priority tree root; the number of trees it is able to compute; and the number of distribution
maximum number of trees it is able to compute; and the number of trees it wishes to be able to use in forwarding multi-destination
distribution trees it wishes to be able to use in forwarding multi- traffic.
destination traffic.
Once a node receives a new LSP, it runs an election algorithm, Once a node receives a new LSP, it runs an election algorithm to
independently of the other nodes in the network, to determine if it ensure if this node is reachable. On the reachable set of the nodes,
is the highest priority root. The node that announced the independently of the other nodes in the network, it determine if it
numerically highest priority to become a tree root is elected the to has the nickname that has the highest priority root. The node that
be the highest priority tree root. If two devices advertise the same announced the numerically highest priority nickname to become a tree
priority, the device with the higher system ID has the higher root is elected to be the highest priority tree root. If two devices
priority to be a tree root. The elected highest priority tree root advertise the same priority, the device with the higher system ID has
dictates the number of distribution tree roots to be used in the the higher priority to be a tree root. If system IDs also tie, the
network domain and can list those roots in the tree roots identifier device with the highest nickname value, considered as an unsigned
sub-TLV. integer, wins. The elected highest priority tree root dictates the
number of distribution tree roots to be used in the network domain
and can list those roots in the tree roots identifier sub-TLV.
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Type = TREE | |Type = TREE |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree Root Priority | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of trees to compute | (2 byte) | Number of trees to compute | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum trees able to compute | (2 byte) | Maximum trees able to compute | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of trees to use | (2 byte) | Number of trees to use | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type, set to 7 (TREE). o Type: sub-TLV Type, set to 7 (TREE).
o Length: 6 : Total number of bytes contained in the value field. o Length: 6 : Total number of bytes contained in the value field.
o Tree Root Pri: This is an unsigned 16-bit integer that gives the
value of the priority with which this node wants to be the highest
priority root node in the Layer-2 domain.
o Number of trees to compute: This is an unsigned 16-bit integer o Number of trees to compute: This is an unsigned 16-bit integer
that gives the requested number of distribution trees for multi- that gives the requested number of distribution trees for multi-
destination frames that will be in use in the Layer-2 domain, if destination frames that will be in use in the Layer-2 domain, if
this device becomes the highest priority tree root in the domain. this device becomes the highest priority tree root in the domain.
o Maximum number of tree able to compute: This is an unsigned 16-bit o Maximum number of trees able to compute: This is an unsigned 16-
integer that give the maximum number of threes that the bit integer that give the maximum number of threes that the
originating IS is able to compute for the campus. originating IS is able to compute for the campus.
o Number of trees to use: This is an unsigned 16-bit integer that o Number of trees to use: This is an unsigned 16-bit integer that
gives the number of distribution trees the originating IS wishes gives the number of distribution trees the originating IS wishes
to be able to use. to be able to use.
2.4.4. The Tree Roots Identifier Sub-TLV 2.4.4. The Tree Root Identifiers Sub-TLV
The tree root identifier sub-TLV is is an ordered list of nicknames. The tree root identifiers sub-TLV is an ordered list of nicknames.
When originated by the Intermediate System which is the highest When originated by the Intermediate System which is the highest
priority tree root, this list is the tree roots for which other priority tree root, this list is the tree roots for which other
Intermediate Systems are required to compute trees. If this Intermediate Systems are required to compute trees. If this
information is spread across multiple sub-tlvs, the starting tree information is spread across multiple sub-TLVs, the starting tree
root identifier is used to figure out the ordered list. It is 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 carried within the Router CAPABILITY TLV in a level-1 non-pseudo-node
and is given as: LSP and is given as:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Type=TREE-RT-ID| |Type=TREE-RT-ID|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Starting Tree Root Identifier| (2 bytes) |Starting Tree Root Identifier| (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname (K-th root) | (2 bytes) | Nickname (K-th root) | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname (K+1 - th root) | (2 bytes) | Nickname (K+1 - th root) | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname (...) | | Nickname (...) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type, set to 8 (TREE-RT-IDs). o Type: sub-TLV Type, set to 8 (TREE-RT-IDs).
o Length: Total number of bytes contained in the value field. o Length: Total number of bytes contained in the value field.
o Starting Tree Root Identifier: This identifies the starting tree o Starting Tree Number: This identifies the starting tree number of
root identifier of the nicknames which are roots for the domain. the nicknames which are roots for the domain. This is set to 1
This is set to 1 for the first sub-TLV. The starting value and for the first sub-TLV. The starting value and the length field
the length field gives the number of nicknames being carried in gives the number of nicknames being carried in the sub-TLV. In
the sub-TLV. In the event a tree identifier can be computed from the event a tree identifier can be computed from two such sub-TLVs
two such sub-TLVs and are different, then it is assumed that this and are different, then it is assumed that this is a transient
is a transient condition which will get cleared. 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 o Nickname: The nickname on which this tree is based.
which multicast root (or set of multicast roots) is used to send
traffic for a specific multicast group. If there is a discrepancy
between the number of multi-destination trees the broadcast-root has
announced, and the number of roots the root-identifier sub-tlv
carries, nodes MUST compute trees for the additional roots.
2.4.5. The Tree Used Identifier Sub-TLV 2.4.5. The Trees Used Identifiers Sub-TLV
This sub-TLV has the same structure as the Tree Roots Identifier Sub- This sub-TLV has the same structure as the Tree Roots Identifier sub-
TLV specified in the above section. The only difference is that its 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 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. only those that the originating intermediate systems wishes to use.
2.4.6. Interested VLANs and Spanning Tree Roots sub-TLV 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 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 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 Intermediate System is appointed forwarder on at least originating Intermediate System is appointed forwarder on at least
one port and the VLAN ranges in multiple VLANs sub-TLVs for an one port and the VLAN ranges in multiple VLANs sub-TLVs for an
Intermediate System MUST NOT overlap. That is, the intersection of Intermediate System MUST NOT overlap. That is, the intersection of
the VLAN ranges for any pair of these sub-TLVs originated by an the VLAN ranges for any pair of these sub-TLVs originated by an
Intermediate System must be null. The value length is 4 + 6*n where Intermediate System must be null. The value length is 10 + 6*n where
n is the number of root bridge IDs. The initial 4 bytes of value are n is the number of root bridge IDs. The TLV layout is as follows:
as follows:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Type = INT-VLAN| |Type = INT-VLAN|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+---------------+-----+ +---------------+-----+
| Nickname-Id | (2 bytes) | Nickname-Id | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interested VLANS | (8 bytes) | Interested VLANS | (8 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 22, line 47 skipping to change at page 27, line 12
specific nickname-id, in the event a node wants to segregate specific nickname-id, in the event a node wants to segregate
traffic using multiple device-ids. traffic using multiple device-ids.
o Interested VLANS: In the Interested VLANs, as shown below, the M4 o Interested VLANS: In the Interested VLANs, as shown below, the M4
bit indicates that there is an IPv4 multicast router on a link for bit indicates that there is an IPv4 multicast router on a link for
which the originating Intermediate System is appointed forwarder which the originating Intermediate System is appointed forwarder
for every VLAN in the indicated range. The M6 bit indicates the for every VLAN in the indicated range. The M6 bit indicates the
same for an IPv6 multicast router. The R and Reserved bits MUST 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 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 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 setting them both to that VLAN ID value. The Appointed Forwarder
format: Status Lost Counter is also included here. It is a count of how
many times a port that was appointed forwarder for the VLANs in
the range given has lost the status of being an appointed
forwarder. It has the following format:
0 1 2 3 4 - 15 16 - 19 20 - 31 0 1 2 3 4 - 15 16 - 19 20 - 31
+----+----+----+----+------------+----------+------------+ +----+----+----+----+------------+----------+------------+
| M4 | M6 | R | R | VLAN start | Reserved | VLAN end | | M4 | M6 | R | R | VLAN start | Reserved | VLAN end |
+----+----+----+----+------------+----------+------------+ +----+----+----+----+------------+----------+------------+
| Appointed Forwarder Status Lost Counter | | Appointed Forwarder Status Lost Counter |
+----+----+----+----+------------+----------+------------+ +----+----+----+----+------------+----------+------------+
o Root Bridges: The list of zero or more spanning tree root bridge o Root Bridges: The list of zero or more spanning tree root bridge
IDs is the set of root bridge IDs seen for all ports for which the IDs is the set of root bridge IDs seen for all ports for which the
Intermediate System is appointed forwarder for the VLANs in the Intermediate System is appointed forwarder for the VLANs in the
skipping to change at page 23, line 29 skipping to change at page 27, line 41
seen on any particular port, there may be multiple ports in the seen on any particular port, there may be multiple ports in the
same VLAN connected to differed bridged LANs with different same VLAN connected to differed bridged LANs with different
spanning tree roots.) If no spanning tree roots can be seen on spanning tree roots.) If no spanning tree roots can be seen on
any of the links in any of the VLANs in the range indicated for any of the links in any of the VLANs in the range indicated for
which the Intermediate System is appointed forwarder (for example which the Intermediate System is appointed forwarder (for example
all such links are point-to-point links to other Intermediate all such links are point-to-point links to other Intermediate
Systems or to end stations so no BPDUs are received) then the Systems or to end stations so no BPDUs are received) then the
listed set of spanning tree root IDs will be null. 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, or M6 bits are different, the sub-TLV is incorrect and of the M4, or M6 bits or the Appointed Forwarder Status Lost Counter
must be split into multiple sub-TLVs each indicating only VLANs with are different, the sub-TLV is incorrect and must be split into
the same M4, and M6 values. If there are any two VLANs in the range multiple sub-TLVs each indicating only VLANs with the same M4, M6,
indicated for which the set of root bridge IDs see on all links for and Appointed Forwarder Status Lost Counter values. If there are any
which the Intermediate System is appointed forwarder for the VLAN are two VLANs in the range indicated for which the set of root bridge IDs
not the same, the sub-TLV is incorrect and must be split into see on all links for which the Intermediate System is appointed
multiple subTLVs each indicating only VLANs with the same set of DRB forwarder for the VLAN are not the same, the sub-TLV is incorrect and
seen root bridge IDs. It is always safe to use sub-TLVs with a must be split into multiple subTLVs each indicating only VLANs with
"range" of one VLAN ID but this may be too verbose. the same set of DRB seen root bridge IDs. It is always safe to use
sub-TLVs with a "range" of one VLAN ID but this may be too verbose.
Wherever possible, an implementation SHOULD advertise the update to a
interested vlan and spanning trees sub-TLV in the same LSP fragment
as the advertisement that it replaces. Where this is not possible,
the two affected LSP fragments should be flooded as an atomic action.
Systems that receive an update to an existing interested vlan and
spanning sub-TLV can minimize the potential disruption associated
with the update by employing a holddown time prior to processing the
update so as to allow for the receipt of multiple LSP fragments
associated with the same update prior to beginning processing.
Where a receiving system has two copies of a interested vlan and
spanning sub-TLV from the same system that have different settings
for a given vlan, the procedure used to choose which copy shall be
used is undefined (refer to RFC 4971, Section 3).
This sub-TLV is carried within the CAPABILITY TLV in a level-1 non- This sub-TLV is carried within the CAPABILITY TLV in a level-1 non-
pseudo-node LSP. pseudo-node LSP.
2.4.7. 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 structured
as follows:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Type=VLAN-GROUP| |Type=VLAN-GROUP|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | 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) | | Primary VLAN ID (2 bytes) | Secondary VLAN ID (2 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ Possibly more Secondary VLAN IDs .......... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to 11 (VLAN-GROUPs). o Type: TLV Type, set to 11 (VLAN-GROUPs).
o Length: Total number of bytes contained in the value field. o Length: Total number of bytes contained in the value field, 4 +
2*n, where n may be 0.
o Primary VLAN-ID: This identifies the primary VLAN-ID. o Primary VLAN-ID: This identifies the primary VLAN-ID.
o Secondary VLAN-ID: This identifies the secondary VLAN-ID, address o Secondary VLAN-ID: This identifies the secondary VLAN-ID, address
learning is shared at the Intermediate System that announces this learning is shared at the Intermediate System that announces this
sub-tlv. sub-TLV.
This sub-TLV may appear zero, one, or multiple times. This sub-TLV may appear zero, one, or multiple times.
2.4.8. The Ingress-to-Egress Options (ITEOPT) sub-tlv 2.4.8. The Ingress-to-Egress Options (ITEOPT) sub-TLV
By including this sub-TLV within one or more Router Capability TLVs By including this sub-TLV within one or more Router Capability TLVs
in its LSPs, an RBridge can advertise the Ingress-to-Egress options 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 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- Router Capability TLV. By default, in the absence of any ITEOPT sub-
TLVs, no Ingress-to-Egress options are supported. TLVs, no Ingress-to-Egress options are supported.
All Ingress-to-Egress options are TLV encoded within the TRILL Header There are two types of Ingress-to-Egress option encoding within the
options area. The implementation of a TLV encoded option is TRILL Header: bit options and TLV encoded options.
The bit-encoded options supported are indicated by an ITEOPT sub-TLV
of length 3: an initial value byte of 0x00 followed by two bytes in
which each bit indicates that the corresponding bit Ingress-to-Egress
option is implemented.
Other Ingress-to-Egress options are TLV encoded within the TRILL
Header options area. The implementation of a TLV encoded option is
indicated by an ITEOPT sub-TLV whose value starts with a byte equal 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 to the first byte of the option. Such ITEOPT sub-TLVs may have
additional value bytes further indicating how the option is supported additional value bytes further indicating how the option is supported
as specified in the option's definition, for example a list of as specified in the option's definition, for example a list of
supported security algorithms. supported security algorithms.
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Type = ITEOPT | | Type = ITEOPT |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
skipping to change at page 25, line 23 skipping to change at page 30, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type, set to Ingress-to-Egress option sub-TLV 12 o Type: sub-TLV Type, set to Ingress-to-Egress option sub-TLV 12
[TBD]. [TBD].
o Length: variable, minimum 1. o Length: variable, minimum 1.
o Value: The first byte of the option followed by option dependent o Value: The first byte of the option followed by option dependent
information. information.
2.4.9. VLAN Mapping (VMAP) sub-TLV
The VLAN Mapping (VMAP) TLV carries information concerning VLAN
mappings configured at the originating IS. VLAN mapping is used when
an RBridge campus is divided into regions such that the same VLAN is
represented by different VLAN IDs in different regions or there is a
VLAN is one region that has no equivalent in another region. As
specified in [VMAP], each port on each of the border RBridges between
two or more regions MUST be configured at to which region each port
connects with. The numbering of regions is an arbitrary choice but
all border RBridges in the campus MUST agree on the number of each
region.
+-+-+-+-+-+-+-+-+
| Type = VMAP |
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+----------...+
| Mapping 1 | (8 bytes)
+-+-+-+-+-+-+-+------------...
| Mapping N, etc.|
+--------------------------...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count | From VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| From Region | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | To VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| To Region | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type, set to VLAN Mapping sub-TLV 13 [TBD].
o Length: variable, 8*N.
o Value: Specific information on each VLAN mapping as diagrammed
above and specified below:
* Count: If this four bit unsigned integer is zero or 1, then the
mapping of a single VLAN ID is being specified. If it is any
value from 2 through 15, then a block of that many contiguous
VLAN IDs starting with the From VLAN ID is mapped to a block of
that many contiguous VLAN IDS starting with the To VLAN ID.
* From VLAN ID: This is the VLAN ID that, when received on a port
connect to the From Region on a frame being sent to the To
Region, is mapped to the To VLAN ID. This must be a real VLAN
ID, that is, the values 0x000 and 0xFFF are prohibited.
* From Region: This is the region number, within the campus, such
that frames received on a port connected to that region and
destined to a port connected to the To Region have their VLAN
ID mapped as specified by the From VLAN ID and To VLAN ID
fields.
* RESV: MUST be sent as zero on sub-TLV creation and ignored on
receipt.
* To VLAN ID: This is the VLAN ID to be used on frames sent out a
port connected to the To Region if they were received on a port
connected to the From Region with the From VLAN ID; except that
if the To VLAN ID is 0x000 the frame is dropped. The value
invalid VLAN ID 0xFFF is prohibited in this field.
* To Region: This is the region number, within the campus, such
that frames sent on a port connected to this region from a port
connected to the From Region have their VLAN ID mapped as
specified by the From VLAN ID and To VLAN ID fields.
2.5. Multi Topology Aware Capability TLV 2.5. Multi Topology Aware Capability TLV
This section defines a new optional Intermediate System to This section defines a new optional Intermediate System to
Intermediate System (IS-IS) TLV named MT-CAPABILITY, formed of Intermediate System (IS-IS) TLV named MT-CAPABILITY, formed of
multiple sub-TLVs, which allows a router to announce its capabilities multiple sub-TLVs, which allows a router to announce its capabilities
for a particular topology within an IS-IS level or the entire routing for a particular topology within an IS-IS level or the entire routing
domain. This is different from Capability TLV defined in RFC 4971, domain. This is different from Router Capability TLV defined in RFC
in the sense, the capabilities announced here are topology scoped. 4971, in the sense, the capabilities announced here are topology
scoped.
The Multi Topology Aware Capability (MT-CAPABILITY) is an optional The Multi Topology Aware Capability (MT-CAPABILITY) is an optional
IS-IS TLV type 144 [TBD], that may be generated by the originating IS IS-IS TLV type 144 [TBD], that may be generated by the originating IS
and has the following format: 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=MTCAPABTLV| Length |O|R|R|R| Topology Identifier | |Type=MTCAPABTLV| Length |O|R|R|R| Topology Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLVs | | sub-TLVs |
skipping to change at page 26, line 8 skipping to change at page 32, line 14
o O bit: The overload bit that follows the semantics associated with o O bit: The overload bit that follows the semantics associated with
an overloaded intermediate system. an overloaded intermediate system.
o Topology Identifier: MT ID is a 12-bit field containing the MT ID 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 of the topology being announced. This field when set to zero
implies that it is being used to carry base topology information. 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, In TRILL this value is set to ZERO, however, in IEEE SPB and SPBB,
it may be non-zero. it may be non-zero.
o sub-tlvs: The MT aware Capabilities TLV value contains sub-TLVs o sub-TLVs: The MT aware Capabilities TLV value contains sub-TLVs
formatted as described in [RFC5305]. They are defined in the next formatted as described in [RFC5305]. They are defined in the next
sections. sections.
The MT-aware CAPABILITY TLV MUST be carried only within a LSP PDU. The MT-CAPABILITY TLV MUST be carried only within a LSP PDU. It may
It may occur multiple times in a LSP PDU. occur multiple times in a LSP PDU.
2.5.1. SPB Instance sub-TLV 2.5.1. SPB Instance sub-TLV
The SPB Instance sub-TLV gives the SPSourceID for this node/topology 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 instance. This is the 20 bit value that is used in the formation of
multicast DA addresses for packets originating from this node/ multicast DA addresses for packets originating from this node/
instance. The SPSourceID occupies the upper 20 bits of the multicast instance. The SPSourceID occupies the upper 20 bits of the multicast
DA together with 4 other bits (see the SPB 802.1ah multicast DA DA together with 4 other bits (see the SPB 802.1ah multicast DA
address format section). address format section).
This TLV SHOULD be carried within the fragment ZERO LSP. This sub-TLV SHOULD be carried within the MT-Capability TLV in 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 | CIST Root Identifier (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| reserved | N-VID | (2 bytes) | CIST Root Identifier (cont) (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN-ID (1) Tuples | (4 bytes) | CIST External ROOT Path Cost (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN-ID (N) Tuples | (4 bytes) | Bridge Priority | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| SPS Flags |V| SPSOURCEID | |R R R R| SPS Flags |V| SPSOURCEID | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (Auto Allocation Tiebreaker) | | N-VID Trees | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bridge Identifier | | VLAN-ID (1) Tuples (48 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bridge Identifier (cont) | | VLAN-ID (N) Tuples (48 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CIST Root Identifier | | Opaque ECT Algorithm (32 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CIST Root Identifier (cont) | | Opaque ECT Information (variable ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CIST External ROOT Path Cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where VLAN-ID tuples have the format as: where VLAN-ID tuples have the format as:
0 1 2- 3 4 - 15 16 - 19 20 - 31 0 1 2- 3 4 - 15 16 - 19 20 - 31
+-+-+---------+-------+-----------+------------+ +-+-+---------+-------+-----------+------------+
|A|U|Reserved | VID | Algorithm | B-VID | |A|U|Reserved | VID | Algorithm | B-VID |
+-+-+---------+-------+-----------+------------+ +-+-+---------+-------+-----------+------------+
o Type: TLV Type, set to SPB Instance sub-TLV 1 [TBD]. o Type: sub-TLV Type, set to SPB Instance sub-TLV 1 [TBD].
o Length: Total number of bytes contained in the value field. o Length: Total number of bytes contained in the value field.
o S bit indicates the presence of sub-TLVs following this value. o CIST Root Identifier (64-bits)The CIST Root Identifier is for SPB
interworking with RSTO and MSTP at SPT RegionBoundaries. This is
o The N-VID must be set to the number of VIDs tuples that follow. an imported value from a Spanning tree.
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 CIST External Root Path Cost (32-bits) The CIST External Root Path
Cost is the cost from the Spanning tree algorithm to the Root.
o ALG specifies the tie breaking algorithm to be used for this VID. o Bridge Priority (16-bits) Bridge priority is the 16 bits that
Currently only the following values are supported: together with the low 6 bytes of the System ID form the Bridge
Identifier. The 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 by combining the Bridge Priority and the
System ID to form the 8 byte Bridge Identifier. The 8 byte Bridge
Identifier is also the input to the 16 pre defined ECT tie breaker
algorithms.
* ALG = 0 a spanning tree. o V bit (1-Bit) The V bit (SPBM) indicates this SPSourceID is auto
allocated(27.11). If the V bit is clear the SPSourceID has been
configured and must be unique. When the bridge allocating
receives the complete LSP from the IS-IS adjacency it will
allocate a SPSourceID according to the allocation logic(27.11).
* ALG = 1 the Low PATHID algorithm is used for this VID. o The SPSOURCEID is a 20 bit value used to construct multicast DA's
as described below for multicast packets originating from the
origin (SPB node) of the link state packet (LSP) that contains
this TLV. More details are in [IEEE 802.1aq].
* ALG = 2 the High PATHID algorithm is used. o Number of Trees (8-bits) The Number of Trees is be set to the
number of [ECT-ALGORITHM, Base-VID plus flags] sub TLV's that
follow. Each ECT-ALGORITHM has an Base VID, an SPVID and some
flags described below. This must be set to at least one ECT.
These define the standard ECTs. In addition proprietary ECTs may
be defined in the opaque TLV S bit indicates the presence of sub-
TLVs following this value.
o VID is the VID for which the given algorithm applies. This o Each VID Tuple consists of:
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 o
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 * U-Bit (1-bit) The Use flag is set if this bridge, is currently
allocation. If the VID value is zero. A VID will be allocated using this ECT-ALGORITHM for I-SIDs it sources or sinks. This
once the bridge has synchronized the IS-IS LSPs. Neighbor bridges is a bit different than the U-bit found in the Hello, which
can distribute the LSPs but MUST not populate filtering databases will set the Use-Flag if it sees other nodal Use-Flags are set
(forwarding) for traffic from a bridge that has an SPVID of 0. OR it sources or sinks itself.
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 * M-Bit (1-bit) The M-bit indicates if this is SPBM or SPBV mode.
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 * A bit, The A bit (SPB) when set declares this is an SPVID with
allow collisions in SPSOURCEID to be resolved. If these fields auto allocation(27.11). If the VID value is zero. A VID will
are equal then the Bridge Priority takes precedence and if Bridge be allocated once the bridge has synchronized the IS-IS
Priority is equal then the numerically higher Bridge ID wins. The LSPs.Neighbor bridges can distribute the LSPs but must not
V bit indicates this SPSOURCEID is auto allocated. Note populate filtering databases (forwarding) for traffic from a
SPSOURCEIDs are only used in the case of Backbone Brides with bridge that has an SPVID of 0. When the bridge allocating is
single VIDs ( Base-VID TLV B bit = 1 and M bit = 0). Single VIDS synchronized with the IS-IS adjacency, it will allocate one or
are not auto allocated. If the A bit is clear the SPSOURCEID has more SPVIDs according to the allocation logic.
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 o ECT-ALGORITHM (4-bytes) ECT-ALGORITHM is advertised when the
identifier. This is configured exactly as specified in IEEE802 bridge supports a given ECT-ALGORITHM (by OUI/Index) on a given
[802.1D]. This allows SPB to build a compatible Spanning tree VID. This declaration must match the declaration in the Hello PDU
using link state. originating from the same bridge. The ECT-ALGORITHM, BASE-VID
should match what is generated in the Hellos of the same node.
The ECT-ALGORITHM, BASE-VIDs pairs can come in any order however.
o The four most significant bits of the most significant byte of a o Base VID (12-bits) The Base-VID that associated the SPT Set via
Bridge Identifier comprise a settable priority component that the ECT-ALGORITHM.
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 o SPVID (12-bits) The SPVID is the Shortest Path VID when using SPBV
SPT Region Boundaries. This is an imported value from a Spanning mode. It is not defined for SPBM Mode and should be 0 in SPBM
tree. mode.
o CIST External Root Path Cost is the cost from the Spanning tree o an opaque ECT Data TLV (type TBD) whose first 32 bits are the ECT-
algorithm to the Root. ALGORITHM which this data applies to.
2.5.2. Service Identifier and Unicast Address sub-TLV 2.5.2. SPBM Service Identifier and Unicast Address sub-TLV
The SPB Service Identifier and Unicast Address TLV is used to The SPBM Service Identifier and Unicast Address sub-TLV is used to
introduce service group membership on the originating node and/or to introduce service group membership on the originating node and/or to
advertise an additional B-MAC unicast address present on, or advertise an additional B-MAC unicast address present on, or
reachable by the node. reachable by the node.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B-MAC ADDRESS | | B-MAC ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B-MAC ADDRESS (cont) | Res. | VID | | B-MAC ADDRESS (cont) | Res. | Base-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|R| Reserved | ISID #1 | |T|R| Reserved | ISID #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|R| Reserved | ISID #2 | |T|R| Reserved | ISID #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|R| Reserved | ISID #n | |T|R| Reserved | ISID #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to Service Identifier and Unicast Address sub- o Type: sub-TLV Type, set to SPBM Service Identifier and Unicast
TLV 2 [TBD]. Address sub-TLV 2 [TBD].
o Length: Total number of bytes contained in the value field. 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 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 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 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 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 of the node. To add multiple B-MACs this TLV must be repeated per
additional B-MAC. additional B-MAC.
skipping to change at page 30, line 12 skipping to change at page 35, line 44
related B-MAC addresses and will also construct multicast related B-MAC addresses and will also construct multicast
forwarding state using the ISID and the node's SPSOURCEID to forwarding state using the ISID and the node's SPSOURCEID to
construct a multicast DA as described in IEEE 802.1aq LSB. Each 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 ISID has a Transmit(T) and Receive(R) bit which indicates if the
membership is as a Transmitter/Receiver or both (with both bits membership is as a Transmitter/Receiver or both (with both bits
set). In the case where the Transmit(T) and Receive(R) bits are 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 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 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. repeated with the same B-MAC but with different ISID values.
2.6. SPB Link Metric sub-tlv 2.6. Sub-TLVs of the Extended Reachability TLV
The SPB Link Metric Sub TLV occurs nested as within the Extended This section specifies two new sub-TLVs that appear only within the
Extended Reachability TLV (type 22).
2.6.1. SPB Link Metric sub-TLV
The SPB Link Metric sub-TLV occurs nested as within the Extended
Reachability TLV (type 22), or the Multi Topology Intermediate System Reachability TLV (type 22), or the Multi Topology Intermediate System
TLV (type 222). If this sub TLV is not present for an ISIS adjacency 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 then that adjacency MUST NOT carry SPB traffic for the given topology
instance. instance.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (must be 0) | | Reserved (must be 0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPB-LINK-METRIC | Num port ID | | SPB-LINK-METRIC | Num port ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Identifier | | Port Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque ECT Algorithm (32 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque ECT Information (variable ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to SPB Link Metric sub-TLV 5 [TBD]. 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 Length: Total number of bytes contained in the value field.
o SPB-LINK-METRIC indicates the administrative cost or weight of o SPB-LINK-METRIC indicates the administrative cost or weight of
using this link as a 24 bit unsigned number. Smaller numbers using this link as a 24 bit unsigned number. Smaller numbers
indicate lower weights and are more likely to carry SPB traffic. indicate lower weights and are more likely to carry SPB traffic.
Only one metric is allowed per SPB instance per link. If multiple Only one metric is allowed per SPB instance per link. If multiple
metrics are required multiple SPB instances are required, either metrics are required multiple SPB instances are required, either
within IS-IS or within several independent IS-IS instances. within IS-IS or within several independent IS-IS instances.
o Num of Ports is the number of ports associated with this link. 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 o Port Identifier is the standard IEEE port identifier used to build
a spanning tree associated with this link. a spanning tree associated with this link.
SPB routes follow the minimum sum of link metrics from the source to o an opaque ECT Data TLV (type TBD) whose first 32 bits are the ECT-
the destination. If any SPB link metric is not the same as its ALGORITHM which this data applies to.
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 2.6.2. MTU sub-TLV
The systems that this dcoument is concerned with want to carry not The MTU sub-TLV is used to optionally announce the MTU of a link. It
occurs nested as within the Extended Reachability TLV (type 22).
+-+-+-+-+-+-+-+-+
| Type = MTU |
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Reserved | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to MTU sub-TLV 6 [TBD].
o Length: Total number of bytes contained in the value field.
o Failed: This bit is a one if MTU testing on this link failed at
the required campus-wide MTU.
o MTU: This field is set to the largest successfully tested MTU size
for this link or zero if it has not been tested.
2.7. TRILL Neighbor TLV
The TRILL Neighbor TLV is used in the TRILL-Hello PDU in place of the
IS Neighbor TLV. It differs in that MTU information is provided per
neighbor and provision is made for fragmentation, so that not all
neighbors need be reported in each TRILL-Hello, to support the hard
limit on the size of TRILL-Hellos. The structure of the TRILL
Neighbor TLV is as follows:
+-+-+-+-+-+-+-+-+
| Type = TNeigh |
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|L| Reserved | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The list of neighbors MUST be ordered by MAC address, considering
each 6-byte MAC address to be an unsigned integer, starting with the
smallest. The information present for each neighbor is as follows:
+-+-------------------+
|F| Reserved | (2 bytes)
+-+-------------------+
| MTU | (2 bytes)
+--------------------------------------------------------+
| MAC Address | (6 bytes)
+--------------------------------------------------------+
o Type: TLV Type, set to TRILL-Neighbor TLV XX [TBD].
o Length: Total number of bytes contained in the value field, 4
+10*n, where n is the number of neighbor records.
o S: smallest flag. If this bit is a one, then the list of
neighbors includes the neighbor with the smallest MAC address.
o L: largest flag. If this bit is a one, then the list of neighbors
includes the neighbor with the largest MAC address.
o Reserved: These bits are reserved for future use and MUST be set
to zero on transmission and ignored on receipt.
o Sender nickname: If the sending intermediate system is holding any
nicknames, one MUST be included here. Otherwise, the field is set
to zero. This field is to support intelligent end stations that
determine the egress RBridge for unicast data through a directory
service or the like and need a nickname for their first hop to
insert as the ingress nickname to correctly format a TRILL
encapsulated data frame.
o F: failed. This bit is a one if MTU testing to their neighbor
(see Section 3.3) failed at the required campus-wide MTU
o MTU: This field is set to the largest successfully tested MTU size
for this neighbor or zero if it has not been tested.
o MAC Address: The MAC address of the neighbor as in the IS Neighbor
RLV (#6).
2.8. The Group Membership Active Source TLV
The Group Active Source (GMAS) TLV is IS-IS TLV type 146 [TBD] and
has the following format:
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 = GMAS | Length | sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to GMAS-TLV 146 [TBD].
o Length: Total number of bytes contained in the value field, which
includes the length of the sub-TLVs carried in this TLV.
o sub-TLVs: The Group Active Source TLV value contains sub-TLVs
formatted as described in [RFC5305]. The sub-TLVs for this TLV
are specified in the following subsections.
The GMAS TLV is carried within Multicast Group Level 1 link state
PDU.
2.8.1. The Group MAC Active Source sub-TLV
The Group MAC Source (GMAS-MAC) sub-TLV is IS-IS sub-TLV type 1
within the GMAS TLV and has the following format:
+-+-+-+-+-+-+-+-+
| Type=GMAS-MAC | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
| Confidence | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Topology-Id/ Nickname-Id | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|S|R|R| VLAN-ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Num Group Recs | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each group record is of the form:
+-+-+-+-+-+-+-+-+
| RESERVED | (1 byte)
+-+-+-+-+-+-+-+-+
| Num of Sources| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 1 Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 2 Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source M Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type, set to 1 (GMAS-MAC) of length 1 byte.
o Length: Total number of bytes contained in the value field.
o Confidence: This carries an 8-bit quantity indicating the
confidence level in the MAC addresses being transported. Whether
this field is used, and its semantics if used, are further defined
by the specific protocol using Layer-2-IS-IS. If not used, it
MUST be set to zero on transmission and be ignored on receipt.
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 RESERVED: Must be sent as zero on transmission and is ignored on
receipt.
o G: Delivery Group is set
o S: Delivery Source is set
o VLAN-ID: This carries a 12 bit VLAN identifier that is valid for
all subsequent MAC addresses in this TLV, or the value zero if no
VLAN is specified.
o Number of Group Records: This is of length 1 byte and lists the
number of group records in this TLV.
o Group Record: Each group record has a reserved space and is
followed by the number of sources, each of length 1 byte. It then
has a 48-bit multicast Group Address followed by 48-bit source MAC
addresses. An address being a group multicast address or unicast
source address can be checked using the multicast bit in the
address. If the number of sources do not fit in a single sub-TLV,
it is permitted to have the same group address repeated with
different source addresses in another sub-TLV of another instance
of the Group Active Source TLV.
The GMAS-MAC sub-TLV is carried within the GMAS TLV and MUST be
carried in a standard Level 1 link state MGROUP PDU.
2.8.2. The Group IP Active Source sub-TLV
The Group IP Address (GMAS-IP) sub-TLV is IS-IS TLV type 2 and has
the following format:
+-+-+-+-+-+-+-+-+
| Type=GMAS-IP |
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
| Confidence | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Topology-Id/ Nickname-Id | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|S|R|R| VLAN-ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Num Group Recs | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each group record is of the form:
+-+-+-+-+-+-+-+-+
| RESERVED | (1 byte)
+-+-+-+-+-+-+-+-+
| Num of Sources| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 1 Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 2 Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source M Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type, set to 2 (GIP-ADDR).
o Length: Total number of bytes contained in the value field of the
TLV.
o Confidence: This carries an 8-bit quantity indicating the
confidence level in the IP addresses being transported. Whether
this field is used, and its semantics if used, are further defined
by the specific protocol using Layer-2-IS-IS. If not used, it
must be set to zero on transmission and be ignored on receipt.
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 RESERVED: Must be sent as zero on transmission and is ignored on
receipt.
o G: Delivery Group is set
o S: Delivery Source is set
o VLAN-ID: This carries a 12 bit VLAN identifier that is valid for
all subsequent MAC addresses in this TLV, or the value zero if no
VLAN is specified.
o Number of Group Records: This is of length 1 byte and lists the
number of group records in this TLV.
o Group Record: Each group record has a reserved space and 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 addresses. If the number of sources do not fit in a single
sub-TLV, it is permitted to have the same group address repeated
with different source addresses repeated in another sub-TLV of
another instance of the Group Active Source TLV.
The GMAS-IP TLV is carried within the GMAS TLV and MUST be carried in
a standard Level 1 link state MGROUP PDU.
2.8.3. The Group IPv6 Active Source sub-TLV
The Group IPv6 Active Source (GMAS-IPv6) TLV is IS-IS sub-TLV type 3
and has the following format:
+-+-+-+-+-+-+-+-+
|Type=GMAS-IPv6 |
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
| Confidence | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Topology-Id/ Nickname-Id | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|S|R|R| VLAN-ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Num Group Recs | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each group record is of the form:
+-+-+-+-+-+-+-+-+
| RESERVED | (1 byte)
+-+-+-+-+-+-+-+-+
| Num of Sources| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 1 Address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 2 Address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source M Address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type, set to 3 (GIPV6-ADDR).
o Length: Total number of bytes contained in the value field.
o Confidence: This carries an 8-bit quantity indicating the
confidence level in the IPv6 addresses being transported. Whether
this field is used, and its semantics if used, are further defined
by the specific protocol using Layer-2-IS-IS. If not used, it
must be set to zero on transmission and be ignored on receipt.
o Topology-Id/Nickname-Id: Depending on the technology in which it
is used, this carries the topology-id or nickname-id. When this
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 RESERVED: Must be sent as zero on transmission and is ignored on
receipt.
o G: Delivery Group is set
o S: Delivery Source is set
o VLAN-ID: This carries a 12 bit VLAN identifier that is valid for
all subsequent MAC addresses in this TLV, or the value zero if no
VLAN is specified.
o Number of Group Records: This of length 1 byte and lists the
number of group records in this TLV.
o Group Record: Each group record has a reserved space and 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 source IPv6 addresses. If the number of sources do not
fit in a single sub-TLV, it is permitted to have the same group
address repeated with different source addresses repeated in
another sub-TLV in another instance of the Group Address TLV.
The GMAS-IPv6 sub-TLV is carried within the GMAS TLV and MUST be
carried in a standard Level 1 link state MGROUP PDU.
2.9. PDU Extensions to IS-IS
2.9.1. The Multicast Group PDU
The systems that this document is concerned with want to carry not
only layer-2 unicast information in the link state protocols, but only layer-2 unicast information in the link state protocols, but
also multicast information. This document specifies three new IS-IS also multicast information. This section specifies three new IS-IS
PDUs, the Multicast Group (MGROUP) PDU, for carrying a list of PDUs, the Multicast Group (MGROUP) PDU, for carrying a list of
attached or joined multicast groups. The Multicast Group Complete attached or joined multicast groups. The Multicast Group Complete
Sequence Number (MGROUP-CSNP) PDU and the Multicast Group Partial Sequence Number (MGROUP-CSNP) PDU and the Multicast Group Partial
Sequence Number (MGROUP-PSNP) PDU packets are also defined to be used Sequence Number (MGROUP-PSNP) PDU packets are also defined to be used
with the new MGROUP-PDU to perform database exchange on the MGROUP with the new MGROUP-PDU to perform database exchange on the MGROUP
PDU packets. 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
skipping to change at page 31, line 45 skipping to change at page 45, line 18
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. The PDU MUST NOT carry Area Address TLV or reachability information.
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.
The information carried in this PDU is processed in a similar fashion The information carried in this PDU is processed in a similar fashion
as described in [RFC 1584]. as described in [RFC 1584].
3.1. The Multicast Group Partial Sequence Number PDU 2.9.1.1. The Multicast Group Partial Sequence Number PDU
The Multicast Group Partial Sequence Number (MGROUP-PSNP) PDU is used The Multicast Group Partial Sequence Number (MGROUP-PSNP) PDU is used
to reliably flood the MGROUP PDU following the base protocol to reliably flood the MGROUP PDU following the base protocol
specifications. specifications.
3.2. The Multicast Group Complete Sequence Number PDU 2.9.1.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 2.9.1.3. Enhancements to the flooding process
This document proposes that the information contained in the MGROUP- This document proposes that the information contained in the MGROUP-
PDU is in a parallel database and its update mechanisms mimic that of PDU is in a parallel database and its update mechanisms mimic that of
the regular database. Nodes running IS-IS in an L2 domain MUST the regular database. Nodes running IS-IS in an L2 domain MUST
support these additional MGROUP PDUs defined in this document. In support these additional MGROUP PDUs defined in this document. In
general, the flooding of the MGROUP-PDU in tandem with the MGROUP- general, the flooding of the MGROUP-PDU in tandem with the MGROUP-
PSNP and MGROUP-CSNP PDUs uses the same update procedures as defined PSNP and MGROUP-CSNP PDUs uses the same update procedures as defined
for the regular 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
skipping to change at page 33, line 13 skipping to change at page 46, line 32
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 5306], the normal hello operations as described in the restart [RFC 5306], the normal hello operations as described in the
RFC will be followed. The enhancements will take place such that RFC will be followed. The enhancements will take place such that
CSNP and PSNP triggers will necessitate a parallel MGROUP-CSNP and CSNP and PSNP triggers will necessitate a parallel MGROUP-CSNP and
MGROUP-PSNP exchange and update process will be triggered in parallel MGROUP-PSNP exchange and update process will be triggered in parallel
for the MGROUP-PDUs. After both databases containing the regular for the MGROUP-PDUs. After both databases containing the regular
PDUs and MGROUP-PDUs have been obtained, the restart process is PDUs and MGROUP-PDUs have been obtained, the restart process is
deemed complete. deemed complete.
3.4. Enhancements to the maximum sequence number reached 2.9.1.4. Enhancements to the maximum sequence number reached
In the event, LSPs reach the maximum sequence number, ISO/IEC 10589 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 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 the introduction of the MGROUP-PDU, the same process now applies when
LSPs from either database reach the maximum sequence number. LSPs from either database reach the maximum sequence number.
4. Considerations for Using L2 Information in IS-IS 2.9.2. The TRILL-Hello PDU
While this document does not specify the way in which addresses A different Hello PDU is required for TRILL links because it is
carried in these TLVs are used in IS-IS, two general areas of concern necessary that a single Designated RBridge (DIS) be elected on each
are considered in this section: building the SPF tree when using this link based just on priority and MAC address regardless of two-way
information, and the election of designated intermediate systems connectivity. However, RBridge reachability is reported by RBridges
(DIS) in an environment using this information. in their LSP on the same basis as layer 3 Intermediate Systems report
reachability, that is, if and only if two-way connectivity exists.
4.1. Building SPF Trees with Layer 2 Information The TRILL-Hello PDU has the same general structure as an IS-IS LAN
PDU. An RBridge (an Intermediate System supporting TRILL) sends this
PDU, with the same timing as the IS-IS LAN Hello PDU. More
specifically, in a TRILL-Hello PDU the IS-IS Common Header and the
fixed PDU Header are the same as a Level 1 IS-IS LAN Hello except
that a new PDU Type number is used as listed in Section 7. The
circuit type field, of course, is always equal to one. A TRILL-Hello
PDU SHOULD not be padded and MUST NOT exceed a length limit equal to
42 bytes shorter than the reasonable lower bound for the link MTU.
For example, for an 802.3 Ethernet link, the MTU SHOULD be assumed to
be 1512 bytes for the purpose of determining the maximum size of
TRILL-Hello PDUs on that link. Thus, for such a link, TRILL-Hellos
MUST NOT exceed 1470 bytes.
Each IS which is part of a single broadcast domain from a layer 2 The following MUST appear in every TRILL-Hello PDU: a Port Capability
perspective will build multiple SPF trees (SPT) for every IS that is TLV (see Section 2.3) containing a Special VLANs and Flags sub-TLV.
announced by the IS deemed to be the broadcast root.
We assume some mechanism for forwarding traffic to these attached Additional TLVs/sub-TLVs MAY appear in a TRILL-Hello including the
addresses added to the SPT is provided for in the mechanism proposing TRILL Hello TLV specified in Section 2.7 and the following sub-TLVs
the use of these extension TLVs. specified in Section 2.3: Enabled VLANs sub-TLV, Appointed Forwarders
sub-TLV, and Hop-by-Hop Options sub-TLV.
4.2. Designated Intermediate Routers The Padding TLV (#8) SHOULD NOT appear in a TRILL-Hello.
A single DIS SHOULD be elected as described in [IS-IS] for each layer The IS-IS Neighbor TLV (#6) MUST NOT appear in a TRILL-Hello.
2 broadcast domain (VLAN) for which information is being carried in Instead, it uses the TRILL Neighbor TLV (see Section 2.7).
IS-IS. This reduces the amount of work required to flood and
maintain synchronized databases over the underlying media on which
IS-IS is running and providing layer 2 forwarding information for.
5. Acknowledgements 2.9.3. The MTU PDU
The authors would like to thank Les Ginsberg for his useful comments. The MTU-probe and MTU-ack PDUs are used to determine the MTU on a
link between intermediate systems. An MTU-probe MUST be padded to
the size being tested with the Padding TLV (#8). The ability to send
an MTU-probe PDU is optional but an Intermediate System that supports
TRILL MUST send an MTU-ack in response to an MTU-probe and that MTU-
ack MUST be padded to the size of the MTU-probe.
6. Security Considerations The MTU PDUs have the standard IS-IS common header with two new PDU
Type numbers, one each, as listed in Section 7. They also have a 20-
byte common fixed MTU PDU header as shown below.
+------------+
| PDU Length | (2 bytes)
+------------+-------------------------+
| Probe ID | (6 bytes)
+--------------------------------------+
| Probe Source ID | (6 bytes)
+--------------------------------------+
| Ack Source ID | (6 bytes)
+--------------------------------------+
As with other IS-IS PDUs, the PDU length contains length of the
entire IS-IS packet starting with and including the IS-IS common
header.
The Probe ID field is an arbitrary 48-bit quantity set by the
Intermediate System issuing an MTU-probe and copied by the responding
system into the corresponding MTU-ack. For example, an Intermediate
System creating an MTU-probe could compose this quantity from a port
identifier and probe sequence number relative to that port.
The Probe Source ID is set by an Intermediate system issuing an MTU-
probe to its System ID and copied by the responding system into the
corresponding MTU-ack.
The Ack Source ID is set to zero in MTU-probe PDUs. An Intermediate
System issuing an MTU-ack set this field to its System ID.
The TLV area follows the MTU PDU header area. This area MAY contain
an Authentication TLV and MUST be padded to the size being tested
with the Padding TLV.
3. Acknowledgements
The authors would like to thank Les Ginsberg and Mike Shand for their
useful comments.
4. Security Considerations
This document adds no additional security risks to IS-IS, nor does it This document adds no additional security risks to IS-IS, nor does it
provide any additional security for IS-IS. provide any additional security for IS-IS.
7. IANA Considerations 5. IANA Considerations
This document creates three new PDU types, namely the MCAST PDU, This document creates six new PDU types, namely the MCAST PDU, MCAST-
MCAST-CSNP PDU, and the MCAST-PSNP PDU. IANA SHOULD assign a new PDU CSNP PDU, the MCAST-PSNP PDU, TRILL-HELLO-PDU, MTU-PROBE-PDU, and
type to the level-1 PDUs described above and reflect it in the PDU MTU-ACK-PDU. IANA SHOULD assign a new PDU type to the level-1 PDUs
registry. described above and reflect it in the PDU registry.
MCAST-PDU Level-1 PDU Type: 19 MCAST-PDU Level-1 PDU Type: 19
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
TRILL-HELLO-PDU Level-1 PDU Type: 21
MTU-PROBE-PDU Level-1 PDU Type: 23
MTU-ACK-PDU Level-1 PDU Type: 28
This document requires the definition a set of new ISIS TLVs, the This document specifies the definition a set of new IS-IS 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 the Port-Capability TLV (type 143), the MT-Capability TLV (type 144),
the ISIS TLV code-point registry. and the Trill-Neighbor TLV (type 145), and Group Member Active Source
TLV (type 146) that needs to be reflected in the IS-IS 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-TLVs 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 along with Capability TLV. The TLV and sub-TLVs are given below along with
technologies that use them. technologies that use them.
IIH LSP SNP MCAST MCAST TRILL/ IIH LSP SNP MCAST MCAST TRILL/
LSP SNP IEEE LSP SNP IEEE
MAC-RI TLV (141) - X - - - T/I MAC-RI TLV (141) - X - - - T/I
GADDR-TLV (142) - - - X - T/I GADDR-TLV (142) - - - X - -/I
GADDR-TLV.GMAC-ADDR sub-tlv 1 - - - X - T/I GADDR-TLV.GMAC-ADDR sub-TLV 1 - - - X - T/I
GADDR-TLV.GMAC-IP sub-tlv 2 - - - X - T/I GADDR-TLV.GMAC-IP sub-TLV 2 - - - X - T/I
GADDR-TLV.GMAC-IPV6 sub-tlv 3 - - - X - T/I GADDR-TLV.GMAC-IPV6 sub-TLV 3 - - - X - T/I
GADDR-TLV.SPBV-MAC-ADDR sub-TLV 4 - - - X - -/I
MT-Port-Cap-TLV (143) X - - - - T/- MT-Port-Cap-TLV (143) X - - - - T/-
PortCap.VLAN and Flags sub-tlv 1 X - - - - T/- PortCap.VLAN and Flags sub-TLV 1 X - - - - T/-
PortCap.Enabled-VLANs sub-tlv 2 X - - - - T/- PortCap.Enabled-VLANs sub-TLV 2 X - - - - T/-
PortCap.AppointedFwrdrs sub-tlv 3 X - - - - T/- PortCap.AppointedFwrdrs sub-TLV 3 X - - - - T/-
PortCap.HopbyHopOptions sub-tlv 4 X - - - - T/- PortCap.HBHOPT sub-TLV 4 X - - - - T/-
PortCap.BaseVLANID sub-tlv 5 X - - - - -/I PortCap.BaseVLANID sub-TLV 5 X - - - - -/I
PortCap.SPBDigest sub-TLV 6 X - - - - -/I
PortCap.SiteIdentifier sub-TLV 250 X - - - - -/-
PortCap.SiteGroupIP sub-TLV 251 X - - - - -/-
PortCap.SiteGroupIPv6 sub-TLV 252 X - - - - -/-
PortCap.AdjServerIP sub-TLV 253 X - - - - -/-
PortCap.AdjServerIPv6 sub-TLV 254 X - - - - -/-
CAPABILITY.Trill-Version sub-tlv 5 - X - - - T/- CAPABILITY.Trill-Version sub-TLV 5 - X - - - T/-
CAPABILITY.Nickname sub-tlv 6 - X - X - T/- CAPABILITY.Nickname sub-TLV 6 - X - - - T/-
CAPABILITY.Tree sub-tlv 7 - X - - - T/- CAPABILITY.Tree sub-TLV 7 - X - - - T/-
CAPABILITY.Tree Roots Id sub-tlv 8 - X - - - T/- CAPABILITY.Tree Roots Id sub-TLV 8 - X - - - T/-
CAPABILITY.TreeUseRootId sub-tlv 9 - X - - - T/- CAPABILITY.TreeUseRootId sub-TLV 9 - X - - - T/-
CAPABILITY.Int-VLANs sub-tlv 10 - X - X - T/- CAPABILITY.Int-VLANs sub-TLV 10 - X - X - T/-
CAPABILITY.VLAN-Groups sub-tlv 11 - X - - - T/- CAPABILITY.VLAN-Groups sub-TLV 11 - X - - - T/-
CAPABILITY.ITEOPT sub-tlv 12 - X - - - T/- CAPABILITY.ITEOPT sub-TLV 12 - X - - - T/-
CAPABILITY.VMAP sub-TLV 13 - X - - - T/-
MT-Capability-TLV (144) X - - - - -/I MT-Capability-TLV (144) - X - - - -/I
MT-Cap.SPB Instance sub-tlv 1 X - - - - -/I MT-Cap.SPB Instance sub-TLV 1 - X - - - -/I
MT-Cap.Service Id. sub-tlv 2 X - - - - -/I MT-Cap.Service Id. sub-TLV 2 - X - - - -/I
EXT-IS.SPB Link Metric sub-tlv 5 X - - - - -/I TRILL-Nieghbor TLV (145) X - - - - T/-
MT-EXT-IS.SPB LinkMetric sub-tlv 5 X - - - - -/I
IANA SHOULD manage the remaining space using the consensus method. EXT-IS.SPB Link Metric sub-TLV 5 - X - - - -/I
EXT-IS.MTU sub-TLV 6 - X - - - -/I
MT-EXT-IS.SPB LinkMetric sub-TLV 5 - X - - - -/I
8. Contributing Authors Group Mem Active Source TLV (146) - - - X - -/-
GMAS-TLV.GMAS-MAC sub-TLV 1 - - - X - -/-
GMAS-TLV.GMAS-IP sub-TLV 2 - - - X - -/-
GMAS-TLV.GMAS-IPV6 sub-TLV 3 - - - X - -/-
IANA SHOULD manage the remaining space using the IETF Review method
[RFC 5226].
David Ward 6. Contributing Authors
Cisco Systems
170 W Tasman Drive
San Jose, CA 95138
US
Email: wardd@cisco.com David Ward
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, California 94089-1206 USA
Phone: +1-408-745-2000
Email: dward@juniper.net
Russ White Russ White
Cisco Systems Cisco Systems
170 W Tasman Drive 170 W Tasman Drive
San Jose, CA 95138 San Jose, CA 95138
US US
Email: riw@cisco.com Email: riw@cisco.com
Dino Farinacci Dino Farinacci
Cisco Systems Cisco Systems
170 W Tasman Drive 170 W Tasman Drive
San Jose, CA 95138 San Jose, CA 95138
US US
Email: dino@cisco.com Email: dino@cisco.com
Radia Perlman Radia Perlman
Sun Microsystems
16 Network Circle
Menlo Park, CA 94025
US US
Email: Radia.Perlman@Sun.com Email: Radia@alum.mit.edu
Donald E. Eastlake 3rd Donald E. Eastlake 3rd
Stellar Switches 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 Peter Ashwood-Smith
Huawei Technologies Canada Co. Ltd. Huawei Technologies Canada Co. Ltd.
411 Legget Drive, Suite 503 411 Legget Drive, Suite 503
Kanta, Ontario K2K 3C9 Kanta, Ontario K2K 3C9
CANADA CANADA
Email: Peter.AshwoodSmith@huawei.com Email: Peter.AshwoodSmith@huawei.com
Don Fedyk Don Fedyk
Alcatel-Lucent Alcatel-Lucent
skipping to change at page 37, line 4 skipping to change at page 52, line 17
Kanta, Ontario K2K 3C9 Kanta, Ontario K2K 3C9
CANADA CANADA
Email: Peter.AshwoodSmith@huawei.com Email: Peter.AshwoodSmith@huawei.com
Don Fedyk Don Fedyk
Alcatel-Lucent Alcatel-Lucent
220 Hayden Road 220 Hayden Road
Groton, MA 01450 Groton, MA 01450
US US
Email: Donald.Fedyk@alcatel-lucent.com Email: Donald.Fedyk@alcatel-lucent.com
9. References 7. References
9.1. Normative References 7.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.
skipping to change at page 37, line 32 skipping to change at page 52, line 46
Router Information", 2007. Router Information", 2007.
[RFC 5305] [RFC 5305]
Li, T. and H. Smit, "IS-IS Extensions for Traffic Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", 2008. Engineering", 2008.
[RFC 5306] [RFC 5306]
Shand, M. and L. Ginsberg, "Restart Signaling for Shand, M. and L. Ginsberg, "Restart Signaling for
Intermediate System to Intermediate System (IS-IS)", 2004. Intermediate System to Intermediate System (IS-IS)", 2004.
9.2. Informative References 7.2. Informative References
[IEEE 802.1aq] [IEEE 802.1aq]
"Standard for Local and Metropolitan Area Networks / "Standard for Local and Metropolitan Area Networks /
Virtual Bridged Local Area Networks / Amendment 9: Virtual Bridged Local Area Networks / Amendment 9:
Shortest Path Bridging, Draft IEEE P802.1aq/D1.5", 2008. Shortest Path Bridging, Draft IEEE P802.1aq/D1.5", 2008.
[RBRIDGES] [RBRIDGES]
Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A.
Ghanwani, "RBridges: Base Protocol Specification", 2009. Ghanwani, "RBridges: Base Protocol Specification", 2009.
 End of changes. 169 change blocks. 
470 lines changed or deleted 1230 lines changed or added

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