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]