One document matched: draft-ietf-isis-layer2-00.txt
Network Working Group A. Banerjee, Ed.
Internet-Draft Cisco Systems
Expires: September 3, 2009 March 2, 2009
Extensions to IS-IS for Layer-2 Systems
draft-ietf-isis-layer2-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 3, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
Banerjee, et al. Expires September 3, 2009 [Page 1]
Internet-Draft Layer-2-IS-IS March 2009
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This draft specifies the IS-IS extensions necessary to support multi-
link IPv4 and IPv6 networks, as well as to provide true link state
routing to any protocols running directly over layer 2. While
supporting this concept involves several pieces, this document only
describes extensions to IS-IS. We leave it to the systems using
these IS-IS extensions to explain how the information carried in
IS-IS is used.
1. Overview
There are a number of systems (for example, [RBRIDGES]) which have
proposed using layer 2 addresses carried in a link state routing
protocol, specifically IS-IS [IS-IS] [RFC1195], to provide true layer
2 routing in specific environments. This draft proposes a set of
TLVs and sub-TLVs to be added to [IS-IS] level 1 PDUs, and three new
PDU types, to support these proposed systems.
This draft does not propose new forwarding mechanisms using this
additional information carried within IS-IS. There is a short
section included on two possible ways to build a shortest path first
tree including this information, to illustrate how this information
might be used.
2. Proposed Enhancements to IS-IS
This draft proposes additional TLVs, to carry unicast and multicast
attached address information. It also proposes additional sub-tlvs
to carry information regarding building trees for Layer 2 networks.
This draft proposes three new IS-IS PDUs, the Multicast Group
(MGROUP) PDU, for carrying a list of attached or joined multicast
groups. The Multicast Group Complete Sequence Number (MGROUP-CSNP)
PDU and the Multicast Group Partial Sequence Number (MGROUP-PSNP) PDU
packets are also defined to be used with the new MGROUP-PDU to
perform database exchange on the MGROUP PDU packets.
2.1. The MAC-Reachability TLV
The MAC-Reachability (MAC-RI) TLV is IS-IS TLV type 141 and has the
following format:
Banerjee, et al. Expires September 3, 2009 [Page 2]
Internet-Draft Layer-2-IS-IS March 2009
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type= MAC-RI | Length | Vlan-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (1) | MAC (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to 141 (MAC-RI).
o Length: Total number of octets contained in the TLV.
o Vlan-id: This carries a 16 bit VLAN identifier that is valid for
all subsequent MAC addresses in this TLV.
o MAC(i): This is the 48-bit MAC address reachable from the IS that
is announcing this TLV.
The MAC-RI TLV is carried in a standard Level 1 link state PDU. It
MUST contain only unicast addresses.
2.2. The Group Address TLV
The Group Address (GADDR) TLV is IS-IS TLV type 142 [TBD] and has the
following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type = GADDRTLV| Length | sub-tlvs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to GADDR-TLV 142 [TBD].
o Length: Total number of octets contained in the TLV, including the
length of the sub-tlvs carried in this TLV.
o sub-tlvs: The following sub-TLVs are defined.
The GADDR TLV is carried within Multicast Group Level 1 link state
PDU.
2.2.1. The Group MAC Address sub-TLV
The Group MAC Address (GMAC-ADDR) sub-TLV is IS-IS TLV type 1 and has
the following format:
Banerjee, et al. Expires September 3, 2009 [Page 3]
Internet-Draft Layer-2-IS-IS March 2009
+-+-+-+-+-+-+-+-+
| Type=GMAC-ADDR| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vlan-Id | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Num Group Recs | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each group record is of the form:
+-+-+-+-+-+-+-+-+
| RESERVED | (1 byte)
+-+-+-+-+-+-+-+-+
| Num of Sources| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 1 Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 2 Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source M Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to 1 (GMAC-ADDR) of length 1 byte.
o Length: Total number of octets contained in the TLV.
o Vlan-id: This carries a 16 bit VLAN identifier that is valid for
all subsequent MAC addresses in this TLV.
o Number of Group Records: This is of length 1 byte and lists the
number of group records in this TLV.
o Group Record: Each group record has a reserved space and followed
by the number of sources, each of length 1 byte. It then has a
48-bit multicast Group Address followed by 48-bit source MAC
addresses. An address being a group multicast address or unicast
source address can be checked using the multicast bit in the
address.
The GMAC-ADDR sub-TLV is carried within the GADDR TLV and MUST be
carried in a standard Level 1 link state MGROUP PDU.
Banerjee, et al. Expires September 3, 2009 [Page 4]
Internet-Draft Layer-2-IS-IS March 2009
2.2.2. The Group IP Address sub-TLV
The Group IP Address (GIP-ADDR) sub-TLV is IS-IS TLV type 2 and has
the following format:
+-+-+-+-+-+-+-+-+
| Type=GIP-ADDR |
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vlan-Id | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Num Group Recs | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each group record is of the form:
+-+-+-+-+-+-+-+-+
| RESERVED | (1 byte)
+-+-+-+-+-+-+-+-+
| Num of Sources| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 1 Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 2 Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source M Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to 2 (GIP-ADDR).
o Length: Total number of octets contained in the TLV.
o Vlan-id: This carries a 16 bit VLAN identifier that is valid for
all subsequent IPv4 source or group addresses in this TLV.
o Number of Group Records: This is of length 1 byte and lists the
number of group records in this TLV.
o Group Record: Each group record has a reserved space and followed
by the number of sources, each of length 1 byte. It is followed
by a 32-bit IPv4 Group Address followed by 32-bit source IPv4
addresses.
Banerjee, et al. Expires September 3, 2009 [Page 5]
Internet-Draft Layer-2-IS-IS March 2009
The GIP-ADDR TLV is carried within the GADDR TLV and MUST be carried
in a standard Level 1 link state MGROUP PDU.
2.2.3. The Group IPv6 Address sub-TLV
The Group IPv6 Address (GIPV6-ADDR) TLV is IS-IS sub-TLV type 3 and
has the following format:
+-+-+-+-+-+-+-+-+
|Type=GIPv6-ADDR|
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vlan-Id | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Num Group Recs | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each group record is of the form:
+-+-+-+-+-+-+-+-+
| RESERVED | (1 byte)
+-+-+-+-+-+-+-+-+
| Num of Sources| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 1 Address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 2 Address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source M Address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to 3 (GIPV6-ADDR).
o Length: Total number of octets contained in the TLV.
o Vlan-id: This carries a 16 bit VLAN identifier that is valid for
all subsequent IPv6 source or group addresses in this TLV.
o Number of Group Records: This of length 1 byte and lists the
number of group records in this TLV.
Banerjee, et al. Expires September 3, 2009 [Page 6]
Internet-Draft Layer-2-IS-IS March 2009
o Group Record: Each group record has a reserved space and followed
by the number of sources, each of length 1 byte. It is followed
by a 128-bit multicast IPv6 Group Address followed by 128-bit
source IPv6 addresses.
The GIPV6-ADDR sub-TLV is carried within the GADDR TLV and MUST be
carried in a standard Level 1 link state MGROUP PDU.
2.3. Link Capability TLV
The Link Capability (LINK-CAP) is an optional IS-IS TLV type 143
[TBD], that may be generated by the originating IS and has the
following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=LINKCAPTLV| Length | sub-tlvs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to LINK-CAP TLV 143 [TBD].
o Length: Total number of octets contained in the TLV, including the
length of the sub-tlvs carried in this TLV.
o sub-tlvs: The following sub-TLVs are defined.
The LINK-CAP-TLV is carried within a LAN IIH PDU, or within a P2P IIH
PDU.
2.3.1. The Special VLANs and Flags sub-TLV
The Special VLANs and Flags (VLAN & Flags) sub-TLV MUST appear
exactly once in a Port Information TLV in every TRILL Hello PDU. It
has the following format:
0 1 2 3 4 - 15 16 - 19 20 - 31
+----+----+----+----+------------+----------+------------+
| AF | AC | VM | R | Outer.VLAN | Reserved | Desig.VLAN |
+----+----+----+----+------------+----------+------------+
o Type: TLV Type, set to VLAN & Flags sub-TLV 1 [TBD].
o Length: 4 - Number of octets contained in the TLV.
o The first and second octets have a copy of the Outer VLAN ID
associated with the Hello frame when it was sent. The lower 4
bits of the first octet give the upper ID bits of the VLAN ID and
the second octet gives the lower VLAN ID bits.
o The upper 4 bits of the first octet are flag bits as shown. The
AF bit, if one, indicates that the sending RBridge believes it is
Appointed Forwarder for the VLAN and port on which the Hellos was
sent. The AC bit, if one, indicates that the sending port is
configured as an access port. The VM flag, if a one, indicates
Banerjee, et al. Expires September 3, 2009 [Page 7]
Internet-Draft Layer-2-IS-IS March 2009
that the sending RBridge has detected VLAN mapping within the
link. The R bit is reserved and MUST be sent as zero and ignored
on receipt.
o The third and forth octets give the Designated VLAN for the link.
The lower 4 bits of the third octet give the upper ID bits of the
Designated VLAN and the forth octet gives the lower VLAN ID bits.
The upper 4 bits of the third octet are reserved and MUST be sent
as zero and ignored on receipt.
The VLAN & Flags sub-TLV is carried within the LINK-CAP TLV and MUST
be carried in IIH PDU.
2.3.2. Enabled VLANs sub-TLV
The Enabled VLAN sub-TLV specifies the VLANs enabled for end station
service at the port on which the Hello was sent.
o Type: TLV Type, set to Enabled VLANs sub-TLV 2 [TBD].
o Length: variable, depending on contents described next.
o The minimum size of the value is 3 octets. The third and
subsequent octets provide a bit map of enabled VLANs starting at
the VLAN ID indicated in the first two octets. The lower order
four bits of the first octet give the upper bits of the starting
VLAN ID and the second octet gives the lower bits of that VLAN ID.
The upper four bits of the first octet are reserved and MUST be
sent as zero and ignored on receipt. The highest order bit of the
third octet indicates the VLAN equal to the starting ID while the
lowest order bit of the third octet indicated that ID plus 7. For
example, VLANs 1 and 14 being enabled for end station service
could be encoded in 4-octets value 0x00 0x01 0x80 0x04 or,
alternatively, as 0x00 0x00 0x40 0x02.
This sub-TLV may occur more than once in a TRILL Hello and a VLAN is
enabled for end station service on the port where the Hellos was sent
if this is indicated by any occurrence in the Hello. For example, a
receiver could allocate a 512-octet buffer and, with appropriate
shifting operations, OR in the enabled bits for each subTLV of this
type it finds in a Hello to derive the complete bit map of these
VLANs.
The Enabled VLAN sub-TLV is carried within the LINK-CAP TLV and MUST
be carried in IIH PDU.
2.3.3. Appointed Forwarders sub-TLV
The Appointed Forwarder sub-TLV provides the mechanism by which the
DRB can inform other RBridges on the link that they are the
designated VLAN-x forwarder for that link for one or more ranges of
Banerjee, et al. Expires September 3, 2009 [Page 8]
Internet-Draft Layer-2-IS-IS March 2009
VLAN IDs.
o Type: TLV Type, set to Enabled VLANs sub-TLV 3 [TBD].
o Length: The size of the value is 6*n octets where there are n
appointments. Each 6 octet part of the value is formatted as
follows:
+----------------+-----+-----+---------+-----+----+---------+
| octet 1 - 2 | octet 3 | octet 4 | octet 5 | octet 6 |
+----------------+-----+-----+---------+-----+----+---------+
| Appointee Nick | Res | Start VLAN ID | Res | End VLAN ID |
+----------------+-----+-----+---------+-----+----+---------+
o The appointed forwarder RBridge is specified by its nickname in
the first two octets.
o The "Res" fields of 4 bits each are reserved and MUST be sent as
zero and ignored on reciept.
The VLAN range given is inclusive. To specify a single VLAN, that
VLAN ID appears as both the start and end VLAN. The RBridge whose
nickname is given is appointed forwarder for those VLANs for which it
has end station service enabled (see item 2 above) in the inclusive
range. For example, assume an RBridge with end station service
enabled on VLANs 100, 101, 199, and 200 (and possibly other VLANs
less than 100 or greater than 200), but not enabled for VLANS 102
through 198. It could be appointed forwarder for these four VLANs
through either (1) a single 6-octet value sequence with start and end
VLAN IDs of 100 and 200, or (2) a 12-octet value sequence with start
and end VLAN IDs of 100 and 101 in the first part and 199 and 200 in
the second part.
An RBridge's nickname may occur as appointed forwarder for multiple
VLAN ranges within the same or different Link Capability TLVs within
a DRB's Hello. In the absence of appointed forwarder subTLVs
referring to a VLAN, the DRB acts as the appointed forwarder for that
VLAN if end station service is enabled.
The Appointed Forwarder sub-TLV is carried within the LINK-CAP TLV
and MUST be carried in IIH PDU.
2.4. Sub-TLVs for the Capability TLV
The Capability TLV is an optional TLV [RFC 4971] that may be
generated by the originating IS. We introduce these additional sub-
TLVs that are carried within it. These sub-tlvs announce the
capabilities of the router for the entire IS-IS routing domain.
Banerjee, et al. Expires September 3, 2009 [Page 9]
Internet-Draft Layer-2-IS-IS March 2009
2.4.1. The TRILL Version sub-TLV
The TRILL Version (TRILL-VER) sub-TLV indicates support of TRILL
Versions. The device announces the maximum version of TRILL, it is
capable of supporting, including lower versions. In the event, this
sub-tlv is missing, this implies that the node can only support the
base version of the protocol.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Max-version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to 5 (TRILL-VER).
o Length: 2 - Total number of octets contained in the TLV.
o Reserved: Set to 0.
o Max-version: Set to application dependent values.
2.4.2. The Device ID sub-TLV
The Device ID (DEVID) sub-TLV carries information about the identity
of the advertising device, along with information about device
priority. The Device-Id sub-TLV MUST be carried within the
CAPABILITY TLV in a level-1 non-pseudo-node LSP generated by the
originating IS.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Device Id |
+---------------------------------------------------------------+
o Type: TLV Type, set to 6 (DEVID).
o Length: Total number of octets contained in the TLV.
o Reserved: Set to 0.
o Priority: Set to application dependent values.
o Device ID: Left padded device ID or alias.
2.4.3. The Root Priority sub-TLV
The Root Priority sub-TLV MUST be carried within the CAPABILITY TLV
in a level-1 non-pseudo-node LSP generated by the originating IS.
Each device announces a broadcast root-priority and the number of
trees it expects all other nodes to compute if it does become the
broadcast root. Once a node receives a new LSP, it runs an election
algorithm, independently of the other nodes in the network, to
determine the broadcast root. The node that announced the lowest
Banerjee, et al. Expires September 3, 2009 [Page 10]
Internet-Draft Layer-2-IS-IS March 2009
broadcast priority becomes the root of the broadcast tree. If two
devices advertise the same broadcast priority, the device with the
lower system ID becomes the root of the broadcast tree. The elected
broadcast-root decides on the multicast-roots to be used in the
network domain and their roots. This announcement takes place in the
roots identifier sub-TLV.
+-+-+-+-+-+-+-+-+
|Type = ROOT-PRI|
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Broadcast Root Pri | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Num of multi-destination trees | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to 7 (ROOT-PRI).
o Length: Total number of octets contained in the TLV.
o Br Root Pri: This gives the value of the priority with which this
node wants to be the broadcast root node in the Layer-2 domain.
o Num of multi-destination trees: This gives the number of
distribution trees for multi-destination frames that will be in
use in the Layer-2 domain, excluding the broadcast tree rooted at
itself, if this device becomes the broadcast root in the domain.
2.4.4. The Root Identifier Sub-tlv
The root identifier sub-tlv is populated by the root of the broadcast
tree. If this is also announced by other nodes in the network, it
implies that the specific node that is advertising it will only
restrict traffic to the common set of the trees in its announcement
and the ones announced by the broadcast root. It is carried within
the CAPABILITY TLV in a level-1 non-pseudo-node LSP and is given as:
Banerjee, et al. Expires September 3, 2009 [Page 11]
Internet-Draft Layer-2-IS-IS March 2009
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type= ROOT-IDs | Length | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multi-destination Tree Num | Broadcast Root System Id... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Broadcast Root System Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multi-destination Tree Num | Multicast Root System Id ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Multicast Root System Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to 8 (ROOT-IDs).
o Length: Total number of octets contained in the TLV.
o Multi-destination Tree Num: This identifies the trees being used
by the specific nodes.
o Broadcast Root System Id: The Broadcast Root System ID at which a
broadcast tree is rooted. It is of length 6 bytes.
o Multicast Root System Id: The Multicast Root System ID at which a
multicast tree is rooted. It is of length 6 bytes.
A locally significant hash is used by edge devices to determine which
multicast root (or set of multicast roots) is used to send traffic
for a specific multicast group. If there is a discrepancy between
the number of multi-destination trees the broadcast-root has
announced, and the number of roots the root-identifier sub-tlv
carries, nodes MUST compute trees on the additional roots.
2.4.5. Interested Vlans and Spanning Tree Roots sub-TLV
The value of this subTLV consists of a VLAN range, flags, and a
variable length list of spanning tree root bridge IDs. This subTLV
may appear zero, one, or many times. The union of the VLAN ranges in
all occurrences MUST be precisely the set of VLANs for which the
originating RBridge is appointed forwarder on at least one port and
the VLAN ranges in multiple VLANs subTLVs for an RBridge MUST NOT
overlap. That is, the intersection of the VLAN ranges for any pair
of these subTLVs originated by an RBridge must be null. The value
length is 4 + 6*n where n is the number of root bridge IDs.The
initial 4 octets of value are as follows:
Banerjee, et al. Expires September 3, 2009 [Page 12]
Internet-Draft Layer-2-IS-IS March 2009
+-+-+-+-+-+-+-+-+
|Type = INT-VLAN|
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interested VLANS | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multi-destination tree roots | (6*n bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to 9 (INT-VLAN).
o Length: Total number of octets contained in the TLV.
o Interested VLANS: The M4 bit indicates that there is an IPv4
multicast router on a link for which the originating RBridge is
appointed forwarder for every VLAN in the indicated range. The M6
bit indicates the same for an IPv6 multicast router. The OM bit
indicates that this RBridge requests that all non-IP derived
multicast traffic in the indicated VLAN range be sent to it. The
R and Reserved bits MUST be sent as zero and are ignored on
receipt. The VLAN start and end IDs are inclusive. A range of
one VLAN ID is indicated by setting them both to that VLAN ID
value. It has the following format:
0 1 2 3 4 - 15 16 - 19 20 - 31
+----+----+----+----+------------+----------+------------+
| AF | AC | VM | R | Outer.VLAN | Reserved | Desig.VLAN |
+----+----+----+----+------------+----------+------------+
o Multi-destination tree roots: The list of zero or more spanning
tree root bridge IDs is the set of root bridge IDs seen for all
ports for which the RBridge is appointed forwarder for the VLANs
in the range. This information is learned from BPDUs heard by the
RBridge. If MSTP is in use on a link, the root bridge referred to
is the CIST (common and internal spanning tree) root bridge.
(While, of course, only one spanning tree root should be seen on
any particular port, there may be multiple ports in the same VLAN
connected to differed bridged LANs with different spanning tree
roots.) If no spanning tree roots can be seen on any of the links
in any of the VLANs in the range indicated for which the RBridge
is appointed forwarder (for example all such links are point-to-
point links to other RBridges or to end stations so no BPDUs are
received) then the listed set of spanning tree root IDs will be
null.
If there are any two VLANs in the range indicated for which the value
of the M4, M6, or OM bits are different, the subTLV is incorrect and
must be split into multiple subTLVs each indicating only VLANs with
the same M4, M6, and OM values. If there are any two VLANs in the
range indicated for which the set of root bridge IDs see on all links
for which the RBridge is appointed forwarder for the VLAN are not the
Banerjee, et al. Expires September 3, 2009 [Page 13]
Internet-Draft Layer-2-IS-IS March 2009
same, the subTLV is incorrect and must be split into multiple subTLVs
each indicating only VLANs with the same set of DRB seen root bridge
IDs. It is always safe to use subTLVs with a "range" of one VLAN ID
but this may be too verbose.
This sub-tlv is carried within the CAPABILITY TLV in a level-1 non-
pseudo-node LSP.
2.4.6. The Vlan Group Sub-tlv
The Vlan Group sub-tlv consists of two or more 16-bit fields each of
which has a VLAN ID in the low order 12 bits. The top 4 bits MUST be
sent as zero and ignored on receipt. The first such VLAN ID is the
primary, or may be zero if there is no primary. It is carried within
the CAPABILITY TLV in a level-1 non-pseudo-node LSP and is given as:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=VLAN-GROUP| Length | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Primary Vlan-Id | Secondary Vlan Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to 10 (VLAN-GROUPs).
o Length: Total number of octets contained in the TLV.
o Primary Vlan-id: This identifies the primary Vlan-id.
o Secondary Vlan-id: This identifies the secondary Vlan-id, address
learning is shared at the Rbridge that announces this sub-tlv.
This sub-tlv may appear zero, one, or multiple times.
3. The Multicast Group PDU
The systems that this draft is concerned with want to carry not only
layer-2 unicast information in the link state protocols, but also
multicast information. This draft has defined a new Multicast Group
(MGROUP) PDU that can be used to advertise a set of attached, or
joined, multicast groups. Accordingly, it has also introduced a
couple more PDUs as described in the next sections for the flooding
and update process to work seamlessly.
In the Layer-2 environment, it is expected the join/leave frequency
of the multicast members will be much higher than unicast topology
changes. It is efficient to separate the updates for the group
membership change information from the remainder of the information
by placing this information in a separate PDU. This enables
Banerjee, et al. Expires September 3, 2009 [Page 14]
Internet-Draft Layer-2-IS-IS March 2009
reachability information, that would trigger an SPF, to be not
impacted at all. Furthermore, during SPF runs, TLVs being on
different PDUs which do not affect SPF need not be inspected during
processing.
The choice of a different PDU also opens the LSP-space to another 256
fragments to carry a large number of groups. This additional space
can be used judiciously to carry only multicast information.
The Multicast Group (MGROUP) PDU can be used to advertise a set of
attached, or joined, multicast groups. The MGROUP PDU is formatted
identical to a Level 1 Link State PDU, as described in Section 9.3 of
[IS-IS]. One field, PDU Type, is changed to 19 [TBD], to signify
this PDU is carrying multicast group information, rather than unicast
reachability information.
The Multicast Group PDU carries TLVs indicating multicast membership
information. There are three sub-TLVs of the GADDR TLV defined in
this document, that MAY be present in this PDU, namely, GMAC-ADDR,
GIP-ADDR, and GIPV6-ADDR TLVs.
One or more TLVs MAY be carried in a single MGROUP PDU. Future
multicast address TLVs MAY be defined using other type codes, and be
carried in an MGROUP PDU.
The information carried in this PDU is processed in a similar fashion
as described in [RFC 1584].
3.1. The Multicast Group Partial Sequence Number PDU
The Multicast Group Partial Sequence Number (MGROUP-PSNP) PDU is used
to reliably flood the MGROUP PDU following the base protocol
specifications.
3.2. The Multicast Group Complete Sequence Number PDU
The Multicast Group Complete Sequence Number PDU (MGROUP-CSNP) PDU is
used to reliably flood the MGROUP PDU following the base protocol
specifications.
3.3. Enhancements to the flooding process
This draft proposes that the information contained in the MGROUP-PDU
is in a parallel database and its update mechanisms mimic that of the
regular database. Nodes running IS-IS in an L2 domain MUST support
these additional MGROUP PDUs defined in this draft. In general, the
flooding of the MGROUP-PDU in tandem with the MGROUP-PSNP and MGROUP-
CSNP PDUs uses the same update procedures as defined for the regular
Banerjee, et al. Expires September 3, 2009 [Page 15]
Internet-Draft Layer-2-IS-IS March 2009
LSP, PSNP, and CSNP PDUs.
For example, on P2P links CSNP is exchanged on the formation of an
adjacency. In a similar fashion a MGROUP-CSNP MUST also be exchanged
between the neighbors at the same time. This gets the initial
MGROUP-database synchronization going. After this similar actions of
the base protocol specifications for the regular database
synchronization will be maintained to keep the MGROUP-database
synchronized.
Similarly, on LAN links the DIS is responsible for sending periodic
CSNP transmissions. The DIS in the L2 IS-IS network domain will also
be responsible for sending periodic MGROUP-CSNP transmissions. The
update and flooding process will work in parallel for the two
databases and there is no further synchronization between them.
In general, the database synchronization is performed in parallel
with no interactions between the messages. However, the initial
triggers that start a CSNP exchange are correlated, in the sense it
also triggers a MGROUP-CSNP exchange. For example, during graceful
restart [RFC 3847], a parallel MGROUP-CSNP and MGROUP-PSNP exchange
and update process will be run for the MGROUP-PDUs and restart
process completes after both databases have been received.
4. Considerations for Using L2 Information in IS-IS
While this document does not specify the way in which addresses
carried in these TLVs is used in IS-IS, two general areas of concern
are considered in this section: building the SPF tree when using this
information, and the election of designated intermediate systems
(DIS) in an environment using this information.
4.1. Building SPF Trees with Layer 2 Information
Each IS which is part of a single broadcast domain from a layer 2
perspective will build multiple SPF trees (SPT) for every IS that is
announced by the IS deemed to be the broadcast root.
We assume some mechanism for forwarding traffic to these attached
addresses added to the SPT is provided for in the mechanism proposing
the use of these extension TLVs.
4.2. Designated Intermediate Routers
A single DIS SHOULD be elected as described in [IS-IS] for each layer
2 broadcast domain (VLAN) for which information is being carried in
IS-IS. This reduces the amount of work required to flood and
Banerjee, et al. Expires September 3, 2009 [Page 16]
Internet-Draft Layer-2-IS-IS March 2009
maintain synchronized databases over the underlying media on which
IS-IS is running and providing layer 2 forwarding information for.
5. Acknowledgements
The authors would like to thank Les Ginsberg for his useful comments.
6. Security Considerations
This document adds no additional security risks to IS-IS, nor does it
provide any additional security for IS-IS.
7. IANA Considerations
This document creates three new PDU types, namely the MCAST PDU,
MCAST-CSNP PDU, and the MCAST-PSNP PDU. IANA SHOULD assign a new PDU
type to the level-1 PDUs described above and reflect it in the PDU
registry.
MCAST-PDU Level-1 PDU Type: 19
MCAST-CSNP-PDU Level-1 PDU Type: 22
MCAST-PSNP-PDU Level-1 PDU Type: 29
This document requires the definition a set of new ISIS TLVs, the
MAC-Reachability TLV (type 141), the Group Address TLV (type 142),
and the Link-Capability TLV (type 143), that needs to be reflected in
the ISIS TLV code-point registry.
This document creates a number of new sub-TLV in the numbering space
for the Group Address TLV, the Link Capability TLV, and the
Capability TLV. The TLV and sub-TLVs are given below:
Banerjee, et al. Expires September 3, 2009 [Page 17]
Internet-Draft Layer-2-IS-IS March 2009
IIH LSP SNP MCAST MCAST
LSP SNP
MAC-RI TLV (141) - X - - -
GADDR-TLV (142) - - - X -
GADDR-TLV.GMAC-ADDR sub-tlv 1 - - - X -
GADDR-TLV.GMAC-IP sub-tlv 2 - - - X -
GADDR-TLV.GMAC-IPV6 sub-tlv 3 - - - X -
Link-Cap-TLV (143) X - - - -
LinkCap.Vlan & Flags sub-tlv 1 X - - - -
LinkCap.Enabled-Vlans sub-tlv 2 X - - - -
LinkCap.AppointedFwrdrs sub-tlv 3 X - - - -
CAPABILITY.Trill-Version sub-tlv 5 - X - - -
CAPABILITY.Device ID sub-tlv 6 - X - X -
CAPABILITY.Root Priority sub-tlv 7 - X - - -
CAPABILITY.Roots sub-tlv 8 - X - - -
CAPABILITY.Int-Vlans sub-tlv 9 - X - - -
CAPABILITY.Vlan-Groups sub-tlv 10 - X - - -
IANA SHOULD manage the remaining space using the consensus method.
Banerjee, et al. Expires September 3, 2009 [Page 18]
Internet-Draft Layer-2-IS-IS March 2009
8. Contributors
David Ward
Cisco Systems
170 W Tasman Drive
San Jose, CA 95138
US
Email: wardd@cisco.com
Russ White
Cisco Systems
170 W Tasman Drive
San Jose, CA 95138
US
Email: riw@cisco.com
Dino Farinacci
Cisco Systems
170 W Tasman Drive
San Jose, CA 95138
US
Email: dino@cisco.com
Radia Perlman
Sun Microsystems
16 Network Circle
Menlo Park, CA 94025
US
Email: Radia.Perlman@Sun.com
Donald E. Eastlake 3rd
Eastlake Enterprises
155 Beaver Street
Milford, MA 07157
US
Email: d3e3e3@gmail.com
9. References
Banerjee, et al. Expires September 3, 2009 [Page 19]
Internet-Draft Layer-2-IS-IS March 2009
9.1. Normative References
[IS-IS] ISO/IEC 10589, "Intermediate System to Intermediate System
Intra-Domain Routing Exchange Protocol for use in
Conjunction with the Protocol for Providing the
Connectionless-mode Network Service (ISO 8473)", 2005.
[RFC 1195]
Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and
Dual Environments", 1990.
[RFC 3847]
Shand, M. and L. Ginsberg, "Restart Signaling for
Intermediate System to Intermediate System (IS-IS)", 2004.
[RFC 4971]
Vasseur, JP. and N. Shen, "Intermediate System to
Intermediate System (IS-IS) Extensions for Advertising
Router Information", 2007.
9.2. Informative References
[RBRIDGES]
Perlman, R. and J. Touch, "Transparent Interconnection of
Lots of Links (TRILL): Problem and Applicability
Statement", 2008.
[RFC 1584]
Moy, J., "Multicast Extensions to OSPF", March 1994.
Author's Address
Ayan Banerjee (editor)
Cisco Systems
170 W Tasman Drive
San Jose, CA 95138
US
Email: ayabaner@cisco.com
Banerjee, et al. Expires September 3, 2009 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-21 00:05:04 |