IGMPv3/MLDv2 Message Extension
draft-venaas-pim-igmp-mld-extension-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Mahesh Sivakumar , Stig Venaas , Zheng Zhang | ||
| Last updated | 2019-11-04 | ||
| Replaced by | draft-ietf-pim-igmp-mld-extension, draft-ietf-pim-igmp-mld-extension, RFC 9279 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-venaas-pim-igmp-mld-extension-00
Network Working Group M. Sivakumar
Internet-Draft Juniper Networks
Intended status: Standards Track S. Venaas
Expires: May 7, 2020 Cisco Systems, Inc.
Z. Zhang
ZTE Corporation
November 4, 2019
IGMPv3/MLDv2 Message Extension
draft-venaas-pim-igmp-mld-extension-00
Abstract
IGMP and MLD protocols are extensible, but no extensions have been
defined so far. This document provides a well-defined way of
extending IGMP and MLD, including a new extension type to distinguish
between different extensions. This document also defines an
extension for use with IGMP and MLD over BIER, that allows for
identifying the sender. This will in turn enable MLD (resp. IGMP)
to be used in the BIER multicast flow overlay.
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 https://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 May 7, 2020.
Copyright Notice
Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Sivakumar, et al. Expires May 7, 2020 [Page 1]
Internet-Draft IGMPv3/MLDv2 message extension November 2019
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Proposed MLD/IGMP Extension . . . . . . . . . . . . . . . . . 3
3.1. Multicast Listener Query Extension . . . . . . . . . . . 4
3.2. Version 2 Multicast Listener Report Extension . . . . . . 5
3.3. IGMP Membership Query Extension . . . . . . . . . . . . . 6
3.4. IGMP Version 3 Membership Report Extension . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
In this document, we describe a generic method to extend IGMPv3
[RFC3376] and MLDv2 [RFC3810] messages to accommodate information
other than what is contained in the current message formats. This is
done by introducing an extension-type field in the message formats to
indicate the application for which the extension is done. This will
be followed by the actual value of the extension.
Bit Index Explicit Replication (BIER [RFC8279]) defines a new
architecture for optimal forwarding of multicast packets through a
multicast domain without requiring a protocol for explicitly bulding
multicast distribution trees while obviating the need for
intermediate nodes to maintain any per-flow state. Forwarding in the
BIER network is accomplished by having ingress routers construct a
bit mask indicating the set of egress routers in the BIER domain
interested in receiving the packet.
New technologies (such as BIER) can use MLD (resp. IGMP) as an
overlay protocol, in order to collect the ingress and egress nodes
for multicast flows in a multicast domain (such as a BIER domain)
[I-D.ietf-bier-mld]. That draft makes use of an extension to IGMP/
MLD, defined in this document, to have additional info identifying
the BIER sender of the message. This allows the IGMP/MLD overlay to
know exactly who is interested in receiving flows. It can
potentially also be used for other purposes such as logging to
Sivakumar, et al. Expires May 7, 2020 [Page 2]
Internet-Draft IGMPv3/MLDv2 message extension November 2019
capture information regarding the sender of the message. The
extension will be part of additional data as mentioned in [RFC3810]
Section 5.1.12 (resp. [RFC3376] Section 4.1.10) for query messages
and [RFC3810] Section 5.2.12 (resp. [RFC3376] Section 4.2.11) for
report messages.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Proposed MLD/IGMP Extension
The proposed MLD (resp. IGMP) extension for BIER will contain the
same information as the PTA tunnel identifier in [RFC8556] and is
shown in Figure 1. Note that, as defined in the MLD (resp. IGMP),
existing implementations are supposed to ignore this additional data.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Extension Type | Sub-domain ID | BFR-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BFR-Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BFR-Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: MLD/IGMP Extension Data for BIER
o Extension Type: The first octet will introduce an IGMP/MLD
extension type for BIER. This would mean that if we need to
extend MLD (resp. IGMP) messages for other purposes, the type can
tell us what the extension represents. What follows is the
information needed for BIER overlay. For BIER the value here will
be as assigned by IANA.
o Sub-domain-id: The second field is a single octet, containing a
BIER sub-domain-id (see [[RFC8279]]). This indicates the BIER
sub-domain of the router originating the message.
Sivakumar, et al. Expires May 7, 2020 [Page 3]
Internet-Draft IGMPv3/MLDv2 message extension November 2019
o BFR-id: The next field is a two-octet field containing the BFR-id,
in the specified sub-domain, of the router originating the
message.
o BFR-prefix: The last field is the BFR-prefix (see [[RFC8279]]) of
the router that is originating the message. The BFR-prefix will
either be a /32 IPv4 address or a /128 IPv6 address.
3.1. Multicast Listener Query Extension
The MLD query format with the proposed extension is shown below
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 = 130 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Response Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
* *
| |
* Multicast Address *
| |
* *
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resv |S| QRV | QQIC | Number of Sources (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
* *
| |
* Source Address [1] *
| |
* *
| |
+- -+
| |
* *
| |
* Source Address [2] *
| |
* *
| |
+- . -+
. . .
. . .
Sivakumar, et al. Expires May 7, 2020 [Page 4]
Internet-Draft IGMPv3/MLDv2 message extension November 2019
+- -+
| |
* *
| |
* Source Address [N] *
| |
* *
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Extension Type | Extension Value |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: MLD Query Extension
3.2. Version 2 Multicast Listener Report Extension
The MLD report format with the proposed extension is shown below
Sivakumar, et al. Expires May 7, 2020 [Page 5]
Internet-Draft IGMPv3/MLDv2 message extension November 2019
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 = 143 | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Nr of Mcast Address Records (M)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [1] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [2] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. . .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [M] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Extension Type | Extension Value |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: MLD Report Extension
3.3. IGMP Membership Query Extension
The IGMP query format with the proposed extension is shown below
Sivakumar, et al. Expires May 7, 2020 [Page 6]
Internet-Draft IGMPv3/MLDv2 message extension November 2019
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 = 0x11 | Max Resp Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resv |S| QRV | QQIC | Number of Sources (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address [1] |
+- -+
| Source Address [2] |
+- . -+
. . .
. . .
+- -+
| Source Address [N] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Extension Type | Extension Value |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IGMP Query Extension
3.4. IGMP Version 3 Membership Report Extension
The IGMP report format with the proposed extension is shown below
Sivakumar, et al. Expires May 7, 2020 [Page 7]
Internet-Draft IGMPv3/MLDv2 message extension November 2019
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 = 0x22 | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Number of Group Records (M) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Group Record [1] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Group Record [2] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. . .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Group Record [M] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Extension Type | Extension Value |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: IGMP Report Extension
4. Security Considerations
This document extends MLD (resp. IGMP) message formats for a BIER
overlay. As such, there is no impact on security or changes to the
considerations in [RFC3810] and [RFC3376].
5. IANA Considerations
This document requests that IANA assign a new registry entry for the
MLD (resp. IGMP) extension-types.
Sivakumar, et al. Expires May 7, 2020 [Page 8]
Internet-Draft IGMPv3/MLDv2 message extension November 2019
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
<https://www.rfc-editor.org/info/rfc3376>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004,
<https://www.rfc-editor.org/info/rfc3810>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>.
[RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S.,
and A. Dolganow, "Multicast VPN Using Bit Index Explicit
Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April
2019, <https://www.rfc-editor.org/info/rfc8556>.
6.2. Informative References
[I-D.ietf-bier-mld]
Pfister, P., Wijnands, I., Venaas, S., Wang, C., Zhang,
Z., and M. Stenberg, "BIER Ingress Multicast Flow Overlay
using Multicast Listener Discovery Protocols", draft-ietf-
bier-mld-02 (work in progress), July 2019.
Authors' Addresses
Sivakumar, et al. Expires May 7, 2020 [Page 9]
Internet-Draft IGMPv3/MLDv2 message extension November 2019
Mahesh Sivakumar
Juniper Networks
64 Butler St
Milpitas CA 95035
USA
Email: sivakumar.mahesh@gmail.com
Stig Venaas
Cisco Systems, Inc.
Tasman Drive
San Jose CA 95134
USA
Email: stig@cisco.com
Zheng(Sandy) Zhang
ZTE Corporation
No. 50 Software Ave, Yuhuatai Distinct
Nanjing 210000
China
Email: zhang.zheng@zte.com.cn
Sivakumar, et al. Expires May 7, 2020 [Page 10]