BIER Working Group IJ. Wijnands
Internet-Draft P. Pfister
Intended status: Standards Track Cisco Systems
Expires: April 21, 2016 October 19, 2015
Generic Multicast Router Election on LAN's
draft-wijnands-bier-mld-lan-election-00.txt
Abstract
When a host is connected to multiple multicast capable routers, each
of these routers is a candidate to process the multicast flow for
that LAN, but only one router should be elected to process it. This
document proposes a generic multicast router election mechanism using
Internet Group Management Protocol (IGMP) and Multicast Listener
Discovery (MLD) that can be used by any Multicast Overlay Signalling
Protocol (MOSP). Having such generic election mechanism removes a
dependency on Protocol Independent Multicast (PIM).
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 April 21, 2016.
Copyright Notice
Copyright (c) 2015 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
Wijnands & Pfister Expires April 21, 2016 [Page 1]
Internet-Draft Generic Multicast Router Election on LAN's October 2015
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. Terminology and Definitions . . . . . . . . . . . . . . . . . 3
3. Specification of Requirements . . . . . . . . . . . . . . . . 4
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Receiver side . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Sender side . . . . . . . . . . . . . . . . . . . . . . . 5
5. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
9. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Hosts connected to Local Area Networks (LAN) use Internet Group
Management Protocol (IGMP) [RFC4605] or Multicast Listener Discovery
(MLD) [RFC3810] to report their interest in a particular multicast
flow. A multicast flow is identified by a Group or a combination of
Group and Source address. Routers connected to a LAN listen to these
membership reports and signal that information to the Multicast
Overlay Signalling Protocol (MOSP). When a host is connected to
multiple routers, each of these routers is a candidate to forward the
multicast flow onto that LAN, but only one of them should forward the
packets for a given flow to avoid duplication of Multicast packets.
A similar requirement exists for hosts that are sending multicast
traffic and are connected to multiple routers on a LAN. If multiple
routers accept the multicast packets from the LAN, duplication may
occur and/or routing loops may be created.
Protocol Independent Multicast (PIM) [RFC4601] is a MOSP and has a
built-in mechanism to elect a Designated Router (DR) on the receiver
LAN and a Designated Forwarder (DF) on the senders LAN. The DR/DF
election avoids duplication and looping of multicast packets. Other
existing or candidate MOSPs, like Border Gateway Protocol (BGP)
[RFC6514], Multi-point Label Distribution Protocols (mLDP) [RFC6826],
Locator ID Seperation Protocol (LISP) [RFC6830] and IGMP/MLD
[I-D.pfister-bier-mld] have no embedded LAN DR/DF election mechanism.
These MOSPs still rely on PIM to perform DR/DF election on LANs.
With the introduction of mLDP and Bit Indexed Explicit Replication
(BIER) [I-D.ietf-bier-architecture], there is no dependency on PIM to
Wijnands & Pfister Expires April 21, 2016 [Page 2]
Internet-Draft Generic Multicast Router Election on LAN's October 2015
transport multicast packets through the network. Having a dependency
on PIM just for DR/DF election is undesirable if PIM is not selected
as the MOSP. This document proposes a generic DR/DF election which
can be used by any MOSP without having a dependency on PIM. It
potentially allows for different MOSPs to coexistence on single LANs.
2. Terminology and Definitions
Readers of this document are assumed to be familiar with the
terminology and concepts of the documents listed as Normative
References. For convenience, some of the more frequently used terms
appear below.
LAN:
Local Area Network.
IGMP:
Internet Group Management Protocol.
MLD:
Multicast Listener Discovery.
mLDP:
Multipoint LDP.
PIM:
Protocol Independent Multicast.
ASM:
Any Source Multicast.
RP:
The PIM Rendezvous Point.
LISP:
Locator ID Seperation Protocol.
BIER:
Bit Indexed Explicit Replication.
MOSP:
Multicast Overlay Signalling Protocol. This is a protocol that is
(potentially) capable of announcing multicast flow membership
across the network between multicast routers. For example PIM,
mLDP, BGP, IGMP, MLD and LISP.
Wijnands & Pfister Expires April 21, 2016 [Page 3]
Internet-Draft Generic Multicast Router Election on LAN's October 2015
3. Specification of Requirements
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 [RFC2119].
4. Problem Statement
In the following sections we describe the requirements for DR/DF
election in more detail for hosts that are multicast senders and
receivers connected to multiple routers on a single LAN.
4.1. Receiver side
Consider the network below in Topology1.
+---- MOSP ----+
LAN2
( R3 ) -|
LAN1 / |
S H1-|-( R1 )--( R2 ) |- H2 (joined G)
\ |
( R4 ) -|
Figure 1
Suppose that H2 on LAN2 is joining a multicast Group G. The MOSP
runs between R1, R3 and R4. Both R3 and R4 will receive the IGMP/MLD
report, but only one of these should become the DR. One might
consider that this problem can be detected and resolved by the MOSP.
The MOSP could be enhanced to allow R1 to detect that both R2 and R4
are connected to the same LAN, and select only to forward the
multicast flow to R3. That would solve the problem in the above
topology, but would fail in the topology below:
+---- MOSP ----+
LAN2
( R3 ) -|
LAN1 / |
S H1-|-( R1 )--( R2 ) |- H2 (joined G)
\ |
( R4 ) -|
|
- LAN3
|
H3 (joined G)
Figure 2
Wijnands & Pfister Expires April 21, 2016 [Page 4]
Internet-Draft Generic Multicast Router Election on LAN's October 2015
Consider that H3 on LAN3 joined the same multicast Group G. Since H3
is singly connected to R4, router R1 needs to forward the multicast
flow to R4 in order for H3 to receive the packets. R4 does not have
enough information to determine whether or not to forward on LAN2 for
H2 when it receives the multicast packets due to H3. In other words,
R4 needs DR state to avoid sending packets to H2 on LAN2.
4.2. Sender side
Consider the network below in Topology3.
+---- MOSP ----+
LAN1
|- ( R1 )
| \ LAN2
S H1 -| ( R3 ) -- ( R4 ) -|- H2 (joined G)
| /
|- ( R2 )
Figure 3
H1 is directly connected via a LAN1 to R1 and R2. H2 joins a
multicast Group G, without specifying the Source. This is called Any
Source Multicast (ASM). The MOSP signals R4s interest in Group G to
R1 and R2. Note that there is no PIM deployed in this network and
there is no Rendezvous Point (RP) that is a target for this receiving
this Group membership. R4 has no information which routers in this
network have multicast packets to sent for this Group. Since this is
ASM, there may be multiple senders for this Group and H2 wants to
receive them all. For that reason, R4 will use the MOSP to announce
the membership to all edge nodes in the network (R1 and R2). This
poses a potential problem since R1 and R2 are both directly connected
to the Source S. If both R1 and R2 will forward the multicast
packets to R4, H2 will receive duplicate packets. This is a problem
that only occurs when a Source is dually connected to two or more
routers connected to the BIER domain. This problem can be resolved
by doing a Designated Forwarder (DF) election, similar to the DR
election. If R1 and R2 are aware they are directly connected, an
election will cause only one of them to forward the multicast packets
into the BIER domain for a given (S,G) flow.
5. Proposal
As explain in Section 4, it is desirable to have a generic DR/DF
election mechanism that can be used for existing and candidate MOSPs.
Also, if a mix of MOSPs is used in the network, it is not obvious
which MOSP is responsible for electing the DR/DF. If a single DR/DF
is to be elected, and each MOSP does its own election, the MOSPs have
Wijnands & Pfister Expires April 21, 2016 [Page 5]
Internet-Draft Generic Multicast Router Election on LAN's October 2015
to negotiate among each other who will be responsible for DR/DF on a
LAN. Independent of the MOSP, a single router connected to the LAN
should be elected. It seems inefficient and unpractical to have each
MOSP implement its own DR/DF election mechanism.
There is a process in the router that all the MOSPs depend on, that
is the IGMP/MLD process. The DR/DF election is typically based on
the Group address or Group and Source address of the multicast flow.
This information is available in the IGMP/MLD process. In this
document we propose to enhance the IGMP/MLD protocol to allow a DR/DF
election among multicast routers connected to a LAN. As soon as a
router is elected as DR/DF, it can select the MOSP that will be
responsible to deliver the multicast flow to this router, and onwards
onto the LAN(s).
IGMP/MLD has support for electing a Membership Querier based on the
lowest IP address of the multicast routers sending out Membership
Queries. It would be possible to use the elected Membership Querier
as the DR/DF on a LAN. However, the authors believe that the
Membership Querier procedures are not robust and extensible enough to
be used DR/DF election on LANs. For example, if a new multicast
router becomes active on a LAN, it will immediately assume the role
of a Membership Querier, which can lead to duplication and/or looping
of packets if also used as DR/DF. This duplication/looping will last
until it learns about other Membership queriers with a lower IP
address. Having two Membership queriers on the LAN has limited
impact on the IGMP/MLD protocol it self, it would only cause more
Membership Reports to be received.
The exact procedures to form a neighborship between IGMP/MLD routers
will added in a later revision of this document.
6. Security Considerations
TBD.
7. IANA Considerations
TBD.
8. Acknowledgments
Many thanks to Neale Ranns and Greg Shepherd for their comments on
this draft.
Wijnands & Pfister Expires April 21, 2016 [Page 6]
Internet-Draft Generic Multicast Router Election on LAN's October 2015
9. Normative References
[I-D.ietf-bier-architecture]
Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and
S. Aldrin, "Multicast using Bit Index Explicit
Replication", draft-ietf-bier-architecture-02 (work in
progress), July 2015.
[I-D.pfister-bier-mld]
Pfister, P., Wijnands, I., and M. Stenberg, "BIER Ingress
Multicast Flow Overlay using Multicast Listener Discovery
Protocols", draft-pfister-bier-mld-00 (work in progress),
July 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004,
<http://www.rfc-editor.org/info/rfc3810>.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601,
DOI 10.17487/RFC4601, August 2006,
<http://www.rfc-editor.org/info/rfc4601>.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605,
August 2006, <http://www.rfc-editor.org/info/rfc4605>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<http://www.rfc-editor.org/info/rfc6514>.
[RFC6826] Wijnands, IJ., Ed., Eckert, T., Leymann, N., and M.
Napierala, "Multipoint LDP In-Band Signaling for Point-to-
Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6826, DOI 10.17487/RFC6826, January 2013,
<http://www.rfc-editor.org/info/rfc6826>.
Wijnands & Pfister Expires April 21, 2016 [Page 7]
Internet-Draft Generic Multicast Router Election on LAN's October 2015
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013,
<http://www.rfc-editor.org/info/rfc6830>.
Authors' Addresses
IJsbrand Wijnands
Cisco Systems
De Kleetlaan 6a
Diegem 1831
Belgium
Email: ice@cisco.com
Pierre Pfister
Cisco Systems
Paris
France
Email: pierre.pfister@darou.fr
Wijnands & Pfister Expires April 21, 2016 [Page 8]