Network Working Group D. Rao Internet-Draft A. Banerjee Intended status: Standards Track H. Grover Expires: September 7, 2011 Cisco Systems March 6, 2011 IS-IS Extensions to support OTV draft-drao-isis-otv-00 Abstract This document specifies the IS-IS extensions necessary to support OTV [OTV]. The data formats and code points used for the extensions are described. Details regarding the usage of these extensions are described in the OTV specification document. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on September 7, 2011. Copyright Notice Copyright (c) 2011 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Rao, et al. Expires September 7, 2011 [Page 1] Internet-Draft OTV March 2011 Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. TLV, sub-TLV and PDU Extensions to IS-IS for OTV . . . . . . . 3 2.1. Group Address TLV . . . . . . . . . . . . . . . . . . . . 3 2.1.1. Group IPv4 Address sub-TLV . . . . . . . . . . . . . . 4 2.1.2. Group IPv6 Address sub-TLV . . . . . . . . . . . . . . 5 2.2. Multi-Topology aware Port Capability TLV . . . . . . . . . 7 2.2.1. Site Capability sub-TLV . . . . . . . . . . . . . . . 7 2.2.2. Site Group IPv4 sub-TLV . . . . . . . . . . . . . . . 8 2.2.3. Site Group IPv6 sub-TLV . . . . . . . . . . . . . . . 8 2.2.4. Adjacency Server IPv4 sub-TLV . . . . . . . . . . . . 9 2.2.5. Adjacency Server IPv6 sub-TLV . . . . . . . . . . . . 10 2.3. Group Membership Active Source TLV . . . . . . . . . . . . 11 2.3.1. The Group MAC Active Source sub-TLV . . . . . . . . . 11 2.3.2. Group IPv4 Active Source sub-TLV . . . . . . . . . . . 13 2.3.3. Group IPv6 Active Source sub-TLV . . . . . . . . . . . 15 2.4. PDU Extensions to IS-IS . . . . . . . . . . . . . . . . . 17 2.4.1. Multicast Group PDU . . . . . . . . . . . . . . . . . 17 2.4.2. Multicast Group Partial Sequence Number PDU . . . . . 18 2.4.3. Multicast Group Complete Sequence Number PDU . . . . . 18 2.4.4. MGROUP PDU related changes to Base protocol . . . . . 18 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 4. Security Considerations . . . . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 5.1. Codepoints . . . . . . . . . . . . . . . . . . . . . . . . 20 5.2. New Sub-Registry . . . . . . . . . . . . . . . . . . . . . 21 6. Normative References . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Rao, et al. Expires September 7, 2011 [Page 2] Internet-Draft OTV March 2011 1. Overview OTV [OTV] uses Layer-2 addresses carried in a routing protocol to provide a MAC-in-IP solution for extending Layer-2 domains transparently across a L2/L3 core network. To achieve the specified functions of OTV, a control plane is required to exchange reachability information among the different OTV Edge Devices. [OTV] refers to this control plane as the oURP and oMRP (Overlay Unicast Routing Protocol and Overlay Multicast Routing Protocol). As one specific instance, IS-IS [IS-IS] [RFC1195] is used as a means to auto-discover overlay VPN members as well as to exchange Layer-2 unicast and multicast reachability information across the overlay. Thus, IS-IS serves as both the oURP and oMRP. This document specifies a set of TLVs and sub-TLVs to be added to [IS-IS] PDUs, and new PDU types, to support this proposed solution. Some of these TLVs are generic Layer-2 IS-IS extensions being leveraged, and some are specific to OTV. This draft does not propose any new forwarding mechanisms using this additional information carried within IS-IS. 1.1. Terminology The terminology and acronyms defined in [OTV] are used herein with the same meaning. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 2. TLV, sub-TLV and PDU Extensions to IS-IS for OTV This section specifies the extensions for PDUs, TLVs and sub-TLVs as needed by OTV. 2.1. Group Address TLV OTV uses the Group Address (GADDR) TLV that is defined in [isis- trill]. However, the GADDR TLV as used by OTV is carried within a Multicast Group link state PDU instead of within an LSP. The GADDR TLV carries sub-TLVs that in turn advertise multicast group listeners. The new sub-TLVs for this TLV defined for use by OTV are specified in the following subsections. Rao, et al. Expires September 7, 2011 [Page 3] Internet-Draft OTV March 2011 2.1.1. Group IPv4 Address sub-TLV The Group IPv4 Address (GIP-ADDR) sub-TLV is IS-IS sub-TLV type 2 within the GADDR TLV and has the following format: +-+-+-+-+-+-+-+-+ | Type=GIP-ADDR | +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESV | Topology-Id | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESV | VLAN-ID | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Num Group Recs | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GROUP RECORDS (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ................. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GROUP RECORDS (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where each group record is of the form: +-+-+-+-+-+-+-+-+ | 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 sub-TLV. o Topology-Id: This carries the topology-id. o RESV: Must be sent as zero on transmission and is ignored on receipt. o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for Rao, et al. Expires September 7, 2011 [Page 4] Internet-Draft OTV March 2011 all subsequent addresses in this sub-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 sub-TLV. o Group Record: Each group record carries the number of sources. It then has 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 in another sub-TLV of another instance of the Group Address TLV. The GIP-ADDR sub-TLV is carried only within a GADDR TLV and MUST be carried in a link state MGROUP PDU. 2.1.2. Group IPv6 Address sub-TLV The Group IPv6 Address (GIPV6-ADDR) sub-TLV is IS-IS sub-TLV type 3 within the GADDR TLV and has the following format: Rao, et al. Expires September 7, 2011 [Page 5] Internet-Draft OTV March 2011 +-+-+-+-+-+-+-+-+ |Type=GIPv6-ADDR| +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESV | Topology-Id | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESV | VLAN-ID | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Num Group Recs | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GROUP RECORDS (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ................. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GROUP RECORDS (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where each group record is of the form: +-+-+-+-+-+-+-+-+ | 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 Topology-Id: This carries the topology-id. o RESV: Must be sent as zero on transmission and is ignored on receipt. o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for all subsequent addresses in this sub-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 sub-TLV. Rao, et al. Expires September 7, 2011 [Page 6] Internet-Draft OTV March 2011 o Group Record: Each group record carries the number of sources. It then has a 128-bit 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 in another sub-TLV of another instance of the Group Address TLV. The GIPV6-ADDR sub-TLV is carried only within a GADDR TLV and MUST be carried in a link state MGROUP PDU. 2.2. Multi-Topology aware Port Capability TLV OTV uses the Multi-Topology aware Port Capability (MT-PORT-CAP) defined in [isis-layer2]. The sub-TLVs used by OTV are defined in the following sections. 2.2.1. Site Capability sub-TLV The Site Capability sub-TLV (SITE-CAP) is type 250 within the MT- PORT-CAP TLV and carries information about or relevant to the site this edge device belongs to. This is used in OTV to aid in Authoritative Edge Device election. It has the following format: +-+-+-+-+-+-+-+-+ |Type = SiteCap | +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Site ID (6 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cluster ID (2 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|R|R|R|R|R|A|U| (1 byte) +-+-+-+-+-+-+-+-+ o Type: sub-TLV Type, set to Site Capability sub-TLV 250. o Length: The size of the value. o Site Id: The site-id of the site. o Cluster Id: The cluster-id within the site. o R: Must be sent as zero on transmission and is ignored on receipt. o U bit: Denotes if the site is a unicast only site. o A bit: Denotes if the edge device is capable of being an OTV Rao, et al. Expires September 7, 2011 [Page 7] Internet-Draft OTV March 2011 Authoritative Edge Device. The Site Capability sub-TLV is carried only within the MT-PORT-CAP TLV and this is carried in an IIH PDU. There MUST be only one occurrence of this sub-TLV in an IIH PDU. 2.2.2. Site Group IPv4 sub-TLV The Site Group IPv4 sub-TLV (SITE-GRP-IPV4) is type 251 within the MT-PORT-CAP TLV and carries information about the overlays active on this device. This is used in OTV to aid in Authoritative Edge Device election. It has the following format: +-+-+-+-+-+-+-+-+ |Type=SiteGrpIP | +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .................. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: sub-TLV Type, set to Site Group IPv4 sub-TLV 251. o Length: The size of the value. o Value: The list of IPv4 addresses used by the site. The Site Group IPv4 sub-TLV is carried within an IIH PDU. There may be more than one occurrence of this sub-TLV in an IIH PDU. 2.2.3. Site Group IPv6 sub-TLV The Site Group IPv6 sub-TLV (SITE-GRP-IPV6) is type 252 and carries information about the overlays active on this device. This is used in OTV to aid in Authoritative Edge Device election. It has the following format: Rao, et al. Expires September 7, 2011 [Page 8] Internet-Draft OTV March 2011 +-+-+-+-+-+-+-+-+ |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. o Length: The size of the value. o Value: The list of IPv6 addresses used by the site. The Site Group IPv6 sub-TLV is carried within an IIH PDU. There may be more than one occurrence of this sub-TLV in an IIH PDU. 2.2.4. Adjacency Server IPv4 sub-TLV The Adjacency Server IPv4 sub-TLV (ADJ-SVR-IPV4) is type 253 within the MT-PORT-CAP TLV and carries information about the capability of the sites in OTV. It has the following format: +-+-+-+-+-+-+-+-+ |Type = ASIPv4 | +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Adjacency IPv4 Information (1) | (5 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ................. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Adjacency IPv4 Information (N) | (5 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where each adjacency IPv4 information is of the form: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Resv (7bits) |U| (1 byte) +-+-+-+-+-+-+-+-+ o Type: sub-TLV Type, set to Adjacency Server IP sub-TLV 253. Rao, et al. Expires September 7, 2011 [Page 9] Internet-Draft OTV March 2011 o Length: The size of the value, 5*n, where there are n adjacency server information blocks. o IPv4 Address: The IPv4 addresses used by the sites. o Reserved: Must be sent as zero on transmission and is ignored on receipt. o U bit: Denotes if the site is a unicast only site. The Adjacency Server IPv4 sub-TLV is carried within an IIH PDU. There may be more than one occurrence of this sub-TLV in an IIH PDU. 2.2.5. Adjacency Server IPv6 sub-TLV The Adjacency Server IPv6 sub-TLV (ADJ-SVR-IPV6) is type 254 within the MT-PORT-CAP TLV and carries information about the capability of the sites in OTV. It has the following format: +-+-+-+-+-+-+-+-+ |Type = ASIPv6 | +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Adjacency IPv6 Information (1) | (17 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ................. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Adjacency IPv6 Information (N) | (17 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where each adjacency IPv6 information is of the form: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address (16 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Resv (7bits) |U| (1 byte) +-+-+-+-+-+-+-+-+ o Type: sub-TLV Type, set to Adjacency Server IPv6 sub-TLV 254. o Length: The size of the value. o Value: The IPv6 addresses used by the sites. o Reserved: Must be sent as zero on transmission and is ignored on receipt. Rao, et al. Expires September 7, 2011 [Page 10] Internet-Draft OTV March 2011 o U bit: Denotes if the site is a unicast only site. The Adjacency Server IPv6 sub-TLV is carried within an IIH PDU. There may be more than one occurrence of this sub-TLV in an IIH PDU. 2.3. Group Membership Active Source TLV The Group Active Source (GMAS) TLV is IS-IS TLV type 146 and has the u following format: +-+-+-+-+-+-+-+-+ | Type = GMAS | (1 byte) +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-TLVs (variable bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: TLV Type, set to GMAS-TLV 146. 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 MUST be carried within a Multicast Group link state PDU. 2.3.1. The Group MAC Active Source sub-TLV The Group MAC Source (GMAS-MAC) sub-TLV is IS-IS sub-TLV type 4 within the GMAS TLV. It is used in OTV to create multicast distribution trees and has the following format: Rao, et al. Expires September 7, 2011 [Page 11] Internet-Draft OTV March 2011 +-+-+-+-+-+-+-+-+ | Type=GMAS-MAC | (1 byte) +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESV | Topology-Id | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |G|S| R | Vlan ID | (2 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address family | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delivery Group (afi scoped number of bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delivery Source (afi scoped number of bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Num Group Recs | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GROUP RECORDS (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ................. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GROUP RECORDS (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where each group record is of the form: +-+-+-+-+-+-+-+-+ | 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 4 (GMAS-MAC) of length 1 byte. o Length: Total number of bytes contained in the value field. o Topology-Id: This carries the topology-id. o RESV: Must be sent as zero on transmission and is ignored on receipt. Rao, et al. Expires September 7, 2011 [Page 12] Internet-Draft OTV March 2011 o G (1 bit): Delivery Group is set o S (1 bit): Delivery Source is set o R (2 bits) : Must be sent as zero on transmission and is ignored on receipt. o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for all subsequent MAC addresses in this sub-TLV, or the value zero if no VLAN is specified. o Address Family: Describes the Address family of the Delivery Source/Group information. It is set to 1 for IPv4 and 2 for IPv6. o Length: Gives the length of the Delivery Source and Delivery Group field. o Delivery Group: Describes the group used to deliver packets. o Delivery Source: Describes the source address used to deliver packets. o Number of Group Records: This is of length 1 byte and lists the number of group records in this sub-TLV. o Group Record: Each group record has a one byte which carries the number of sources. 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 link state MGROUP PDU. 2.3.2. Group IPv4 Active Source sub-TLV The Group IPv4 Address (GMAS-IP) sub-TLV is IS-IS sub-TLV type 5 within the GMAS TLV. It is used in OTV to create multicast distribution trees and has the following format: Rao, et al. Expires September 7, 2011 [Page 13] Internet-Draft OTV March 2011 +-+-+-+-+-+-+-+-+ | Type=GMAS-IP | (1 byte) +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESV | Topology-Id | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |G|S| R | Vlan ID | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address family | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delivery group (afi scoped number of bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delivery Source (afi scoped number of bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Num Group Recs | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GROUP RECORDS (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ................. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GROUP RECORDS (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where each group record is of the form: +-+-+-+-+-+-+-+-+ | 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 5 (GMAS-IP). o Length: Total number of bytes contained in the value field of the sub-TLV. o Topology-Id: This carries the topology-id. o RESV: Must be sent as zero on transmission and is ignored on Rao, et al. Expires September 7, 2011 [Page 14] Internet-Draft OTV March 2011 receipt. o G (1 bit): Delivery Group is set o S (1 bit): Delivery Source is set o R (2 bits) : Must be sent as zero on transmission and is ignored on receipt. o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for all subsequent MAC addresses in this sub-TLV, or the value zero if no VLAN is specified. o Address Family: Describes the Address family of the Delivery Source/Group information. o Length: Gives the length of the Delivery Source and Delivery Group field. o Delivery Group: Describes the group used to deliver packets. o Delivery Source: Describes the source address used to deliver packets. o Number of Group Records: This is of length 1 byte and lists the number of group records in this sub-TLV. o Group Record: Each group record has a one byte which carries the number of sources. 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 link state MGROUP PDU. 2.3.3. Group IPv6 Active Source sub-TLV The Group IPv6 Active Source (GMAS-IPV6) sub-TLV is IS-IS sub-TLV type 6. It is used in OTV to create multicast distribution trees and has the following format: Rao, et al. Expires September 7, 2011 [Page 15] Internet-Draft OTV March 2011 +-+-+-+-+-+-+-+-+ | Type=GMAS-IPv6| (1 byte) +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESV | Topology-Id | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |G|S| R | Vlan ID | (2 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address family | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delivery group (afi scoped number of bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delivery Source (afi scoped number of bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Num Group Recs | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GROUP RECORDS (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ................. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GROUP RECORDS (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where each group record is of the form: +-+-+-+-+-+-+-+-+ | 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 6 (GMAS-IPV6). o Length: Total number of bytes contained in the value field. o Topology-Id: This carries the topology-id. o RESV: Must be sent as zero on transmission and is ignored on receipt. Rao, et al. Expires September 7, 2011 [Page 16] Internet-Draft OTV March 2011 o G (1 bit): Delivery Group is set o S (1 bit): Delivery Source is set o R (2 bits) : Must be sent as zero on transmission and is ignored on receipt. o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for all subsequent MAC addresses in this sub-TLV, or the value zero if no VLAN is specified. o Address Family: Describes the Address family of the Delivery Source/Group information. o Length: Gives the length of the Delivery Source and Delivery Group field. o Delivery Group: Describes the group used to deliver packets. o Delivery Source: Describes the source address used to deliver packets. o Number of Group Records: This of length 1 byte and lists the number of group records in this sub-TLV. o Group Record: Each group record has one byte which carries the number of sources. 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 link state MGROUP PDU. 2.4. PDU Extensions to IS-IS 2.4.1. Multicast Group PDU This section specifies three new IS-IS PDUs, the Multicast Group (MGROUP) PDU, for carrying a list of attached or joined multicast groups. The Multicast Group Complete Sequence Number (MGROUP-CSNP) PDU and the Multicast Group Partial Sequence Number (MGROUP-PSNP) PDU packets are also defined to be used with the new MGROUP-PDU to perform database exchange on the MGROUP PDU packets. Only Level-1 PDUs are defined. The Multicast Group (MGROUP) PDU can be used to advertise a set of Rao, et al. Expires September 7, 2011 [Page 17] Internet-Draft OTV March 2011 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, 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 sub-TLVs. Furthermore, it MAY carry the Authentication TLV (TLV 10) and the Interested VLANs sub-TLV of the Capability TLV. 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. 2.4.2. Multicast Group Partial Sequence Number PDU The Multicast Group Partial Sequence Number (MGROUP-PSNP) PDU is type 29. The MGROUP-PSNP performs a function analogous to the PSNP but applies to MGROUP-PDUs. 2.4.3. Multicast Group Complete Sequence Number PDU The Multicast Group Complete Sequence Number PDU (MGROUP-CSNP) PDU is type 22. The MGROUP-CSNP performs a function analogous to the CSNP but applies to MGROUP-PDUs. 2.4.4. MGROUP PDU related changes to Base protocol In this section, we describe the changes to the base protocol due to the introduction of the MGROUP, MGROUP-PSNP, MGROUP-CNSP PDUs. 2.4.4.1. Enhancements to the flooding process OTV introduces a second instance of the Update Process which applies to MGROUP-PDUs. Operation of the MGROUP update process is identical to that defined in [IS-IS] but MGROUP-PDUs, MGROUP-PSNPs, and MGROUP- CSNPs are used in place of LSPs, PSNPs, and CSNPs respectively. 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. There need not be any more correlation between the Rao, et al. Expires September 7, 2011 [Page 18] Internet-Draft OTV March 2011 updates of the LSP and the MGROUP-PDU. Similarly, on LAN links the DIS is responsible for sending periodic CSNP transmissions. The DIS in this case 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. 2.4.4.2. Enhancements to Graceful Restart During graceful restart, the normal hello operations as described in RFC 5306 will be followed. The enhancements will take place such that CSNP and PSNP triggers will necessitate a parallel MGROUP-CSNP and MGROUP-PSNP exchange and update process will be triggered in parallel for the MGROUP-PDUs. After the databases containing information from both LSPs and MGROUP-PDUs have been obtained, the restart process is deemed complete. 2.4.4.3. Enhancements to the maximum sequence number reached In the event, LSPs reach the maximum sequence number, ISO/IEC 10589 states the rules for the process to shut down and its duration. With the introduction of the MGROUP-PDU, the same process now applies when LSPs from either database reach the maximum sequence number. 2.4.4.4. Enhancements to SPF The MGROUP-PDU advertises a set of attached, or joined, multicast groups. These groups act as leaves of the advertising nodes. As a result, there are no new requirements of running a SPF if only information within the MGROUP-PDU changes. 3. Acknowledgements The authors would like to thank Dino Farinacci and Les Ginsberg for their input and useful comments on various aspects of the extensions. 4. Security Considerations This document adds no additional security risks to IS-IS, nor does it provide any additional security for IS-IS. Rao, et al. Expires September 7, 2011 [Page 19] Internet-Draft OTV March 2011 5. IANA Considerations This document specifies a set of new IS-IS TLVs and PDU types, which need to be reflected in the IS-IS TLV code-point registry. IANA is requested to allocate the necessary registry code points listed below. 5.1. Codepoints TLV Codepoints Description Type IIH LSP SNP ----------- ---- --- --- --- GMAS 146 - X - Sub-TLV Codepoints MT Port Capability TLV Description Sub-TLV# ----------- -------- SITE-CAP 250 SITE-GRP-IPV4 251 SITE-GRP-IPV6 252 ADJ-SVR-IPV4 253 ADJ-SVR-IPV6 254 Group Address TLV Description Sub-TLV# ----------- -------- GIP-ADDR 2 GIPV6-ADDR 3 IS-IS PDU Codepoints IANA is requested to allocate three new IS-IS PDUs from the IS-IS PDUs registry, namely the MGROUP PDU, the MGROUP-CSNP PDU and the MGROUP-PSNP PDU [suggested PDU values below]. IS-IS PDUs Registry: Mnemonic PDU# Reference -------- ---- --------- MGROUP PDU 19 This document MGROUP-CSNP PDU 22 This document MGROUP-PSNP PDU 29 This document Rao, et al. Expires September 7, 2011 [Page 20] Internet-Draft OTV March 2011 5.2. New Sub-Registry IANA is requested to create a new sub-TLV IS-IS sub-registry for sub- TLVs within the Group Membership Active Source (GMAS) TLV. The codepoints are requested to be allocated as listed below. Registry Name: IS-IS Group Membership Active Source Type Codes Reference: This document Registration Procedures: Expert Review [RFC5226] Registry: Value GMAS Type Code Reference ----- -------------- --------- 0-3 Reserved This document 4 GMAS-MAC This document 5 GMAS-IP This document 6 GMAS-IPV6 This document 4-255 Unassigned This document 6. 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. [OTV] Grover, H., "OTV: Overlay Transport Virtualization, draft-hasmit-otv-01.txt, work in progress", 2010. [isis-layer2] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 Systems, draft-ietf-isis-layer2-11.txt, work in progress", 2011. [isis-trill] Eastlake, D., "TRILL Use of IS-IS, draft-ietf-isis-trill-05.txt, work in progress", 2011. Rao, et al. Expires September 7, 2011 [Page 21] Internet-Draft OTV March 2011 Authors' Addresses Dhananjaya Rao Cisco Systems 170 W Tasman Drive San Jose, CA 95138 US Email: dhrao@cisco.com Ayan Banerjee Cisco Systems 170 W Tasman Drive San Jose, CA 95138 US Email: ayabaner@cisco.com Hasmit Grover Cisco Systems 170 W Tasman Drive San Jose, CA 95138 US Email: hasmit@cisco.com Rao, et al. Expires September 7, 2011 [Page 22]