One document matched: draft-drao-isis-otv-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 03:05:24 |