Internet DRAFT - draft-zhang-pim-muiimp
draft-zhang-pim-muiimp
PIM Working Group Hong-Ke Zhang
Internet Draft Shuai Gao
Intended status: Standards Track Beijing Jiaotong University
Expires: November 24, 2015 T C.Schmidt
HAW Hamburg
Bo-hao Feng
Fei Song
Beijing Jiaotong University
May 25, 2015
Multi-Upstream Interfaces IGMP/MLD Proxy
draft-zhang-pim-muiimp-02.txt
Abstract
In this document, followed by the idea mentioned in [1] and
subsequently updated in [2], an IGMP/MLD proxy with multiple
upstream interfaces called MUIIMP is proposed and analyzed. The
MUIIMP inherits the basic rule of the IGMP/MLD proxy but extends
with multiple upstream interfaces. To avoid data redundancy, each
upstream interface of an MUIIMP device MUST NOT send or subscribe to
the same data simultaneously.
Requirements Language
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].
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress".
Zhang et al. Expires November 24, 2015 [Page 1]
Internet-Draft Multi-Upstream Interfaces IGMP/MLD Proxy May 2015
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on November 24, 2015.
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 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....................................................3
2. Terminology.....................................................3
3. MUIIMP Operation................................................4
3.1. The selection of default upstream interface................5
3.2. Report of downstream subscriptions on upstream interfaces..5
3.3. Handover of the upstream interface.........................6
4. Use Case in PMIPv6 Environment..................................6
5. Security Considerations.........................................9
5. IANA Considerations.............................................9
6. References......................................................9
Authors' Addresses................................................11
Acknowledgment....................................................11
Zhang et al. Expires November 24, 2015 [Page 2]
Internet-Draft Multi-Upstream Interfaces IGMP/MLD Proxy May 2015
1. Introduction
RFC 4605 [3] specifies an IGMP/MLD proxy mechanism for forwarding
based solely upon IGMP/MLD membership information in scenarios where
multicast routing is not available. According to RFC 4605, an
IGMP/MLD proxy performs the router portion of the IGMP/MLD protocol
[4-5] on its downstream interfaces, and the host portion of the
IGMP/MLD protocol on its single upstream interface.
The IGMP/MLD proxy mechanism can effectively expand the scope of the
multicast and greatly simplify the implementation of edge devices.
However, the IGMP/MLD proxy may appear inefficiency in some
specific scenarios due to the limitation of single upstream
interface. For example, in PMIPv6 multicast environment, multiple
IGMP/MLD proxy instances need to be deployed at the MAG in RFC 6224
[6], which may lead to tunnel convergence problem. In addition,
there are also requirements to extend the IGMP/MLD proxy to support
multiple upstream interfaces with the emergence of multi-homing.
It is noted that the idea about multiple upstream interfaces for
IGMP/MLD proxy was first put forward in the draft [1] to improve the
performance of multicast source mobility. Subsequently, the Multimob
working group draft [2] describes the multi-upstream interfaces
IGMP/MLD proxy in detail. Considering the multiple upstream
interfaces extension is not only required for mobile multicast
sources scenarios, this document is presented here.
In this document, an IGMP/MLD proxy with multiple upstream
interfaces called MUIIMP is proposed and described. The MUIIMP
inherits the basic rule of the IGMP/MLD proxy but extends with
multiple upstream interfaces. To avoid data redundancy, each
upstream interfaces of an MUIIMP device MUST NOT send or subscribe
to the same data simultaneously. Additionally, the MUIIMP is
designed to support local multicast listeners and senders.
2. Terminology
Upstream Interface: A proxy device's interface in the direction of
the root of the tree.
Downstream Interface: Each of a proxy device's interfaces that is not
in the direction of the root of the multicast tree.
Default Upstream Interface: An upstream interface which is by
default associated with each downstream node subscribing or sending
specific channel (group address prefix) or special multicast state.
Zhang et al. Expires November 24, 2015 [Page 3]
Internet-Draft Multi-Upstream Interfaces IGMP/MLD Proxy May 2015
3. MUIIMP Operation
The MUIIMP not only inherits the basic rule of the IGMP/MLD proxy
but also extends with multiple upstream interfaces. A MUIIMP device
has one or more upstream as well as downstream interfaces, which may
be any type interfaces, including physical or logical interfaces.
The MUIIMP performs the router portion of the IGMP/MLD protocol on
its downstream interfaces, and the host portion of IGMP/MLD on its
upstream interfaces. The MUIIMP device MUST NOT perform the router
portion of IGMP/MLD on its upstream interfaces.
The MUIIMP device maintains a database for multicast listeners
consisting of the merger of all subscriptions on any downstream
interface. To avoid the redundant multicast traffic, the proxy device
should initiate unique traffic subscriptions. Besides, a policy list
recording the default upstream interface for the downstream nodes is
held for the selection of the upstream interface.
According to the role of the downstream nodes, the operation process
of the MUIIMP device is described as follows:
1) Multicast listener on the downstream interface
Multicast listener reports are group-wise aggregated by the IGMP/MLD
proxy. The aggregated report is issued to the upstream interface
based on the subscriptions as well as the policy list. When
receiving the IGMP/MLD subscriptions on the downstream interface,
the MUIIMP decides whether to send the IGMP/MLD membership reports
on the corresponding default upstream interface based on the
membership database. The detailed membership subscriptions lookup
and report decisions will be discussed in Section 3.2.
When receiving packets on its upstream interfaces, the MUIIMP
forwards the traffic to all the downstream interfaces based upon the
downstream interfaces' subscriptions.
2) Multicast source on the downstream interface
Once receiving packets on its downstream interface, the MUIIMP
forwards the traffic to the corresponding default upstream interface
as well as all the downstream interfaces other than the incoming
interface based upon the downstream interfaces' subscriptions.
The (first) multicast router(s) operating multicast routing protocol
like PIM-SM [7] connected to the outside multicast domain should be
configured to treat the multicast source inside the MUIIMP domain
Zhang et al. Expires November 24, 2015 [Page 4]
Internet-Draft Multi-Upstream Interfaces IGMP/MLD Proxy May 2015
being directly connected. Otherwise, it will discard the data due to
the failure of the direct connection check.
3.1. The selection of default upstream interface
Typically, the choice of the default upstream interface is based on
the policy list maintained at the MUIIMP.
The expression of the policy list is like below:
(node prefix, multicast group address/multicast state, upstream
interface)
Here, node prefix represents the address prefix of the node on the
downstream interface that may be a multicast listener or multicast
source. The multicast group address indicates the channel that the
multicast listener is subscribing or the multicast source is
publishing, while the multicast state is only valid for listeners
indicating the state about both multicast source and multicast group
they are subscribing.
In other words, in the MUIIMP, the multicast group address/multicast
state and the node prefix will act as rules to select the default
upstream interface. Alternate configurations (e.g., the MAG-LMA
tunnel interface in the PMIPv6 environment) MAY be applied.
3.2. Report of downstream subscriptions on upstream interfaces
In order to avoid the redundant multicast traffic, the proxy device
MUST NOT send the same multicast subscription record on different
upstream interfaces simultaneously. specifically, we recommend the
following rules when receiving an IGMP/MLD subscription on the downstream
interface.
1) If the received IGMP/MLD subscription is new and has not been
subscribed by other downstream multicast listeners, the proxy
device SHOULD initiate the IGMP/MLD subscription on the
corresponding default upstream interface.
2) If there exists the same IGMP/MLD subscription which has already
been subscribed by other downstream multicast listeners, the proxy
device SHOULD not initiate extra IGMP/MLD subscription.
3) If there exist IGMP/MLD subscriptions which have already
included the received IGMP/MLD subscription, the proxy device
SHOULD not initiate extra IGMP/MLD subscription.
Zhang et al. Expires November 24, 2015 [Page 5]
Internet-Draft Multi-Upstream Interfaces IGMP/MLD Proxy May 2015
4) If there exist overlapping subsets between the received IGMP/MLD
subscription and the current IGMP/MLD subscriptions, the proxy
device SHOULD initiate the IGMP/MLD subscription on the
corresponding default upstream interface excluding the overlapping
subsets that have been subscribed before.
All subscriptions sent on the same upstream interface SHOULD be
merged according to the merging rule specified in RFC 4605. In
addition, the local multicast source should be excluded in the final
subscriptions to avoid replicated multicast traffic from outside.
3.3. Handover of the upstream interface
If an upstream interface fails for some reason, such as the deletion
of the tunnel interface in mobile environment, the handover of the
upstream interface should be performed. Generally, all the
subscriptions sent on the previous invalid upstream interface are
transferred to the new valid upstream interfaces which are chosen
among the default upstream interfaces of the corresponding
downstream nodes. The choice may be made based on the predefined
policy (e.g., the interface priority, the number of listeners, the
lowest IP address). An alternative may be applied by the MUIIMP
device itself according to the traffic monitored or some strategies
configured by the operator.
4. Use Case in PMIPv6 Environment
With the development of the Mobile IP-like protocols (such as, MIPv6,
PMIPv6 and DMM), combining multicast with mobile protocols has been
widely discussed. One way is to deploy traditional IGMP/MLD proxy at
the gateway of mobile nodes [2,6], but there are some drawbacks like
the detour routing and tunnel convergence problem. MUIIMP can be
used to optimize the behavior of multicast mobility as well as to
support the multi-homing/multi-interface for both the mobile nodes
and the fixed nodes. Requirements for an IGMP/MLD proxy with
multiple interfaces have been proposed in the draft [8], covering a
variety of application scenarios. In this section, a use case in
PMIPv6 environment is presented to illustrate how the MUIIMP works.
The basic deployment of MUIIMP in PIMPv6 networks is shown in Figure
1, in which there are three mobile nodes (MNs) belonging to
different LMAs and attaching under the same MAG. Let's adopt the
scheme in RFC 6224 [6] and assume that the default upstream
interface for each MN in Figure 1 is the tunnel interface from the
MAG to the corresponding LMA. In real environment, the MN may also
express its preference on upstream interface selection by other
means. Detailed multicast related information of each MN is depicted
Zhang et al. Expires November 24, 2015 [Page 6]
Internet-Draft Multi-Upstream Interfaces IGMP/MLD Proxy May 2015
in Table 1. We assume that MN1, MN2 and MN3 attach at the MAG in
sequence.
+-------------------------+
| Multicast Domain | ------------
+-------------------------+ |
/ | \ |
+-------+ +-------+ +-------+ |
| LMA-1 | | LMA-2 | | LMA-3 | |
+-------+ +-------+ +-------+ |
\\ || // |
\\ || // |
\\ ||IF-B // |
\\ || // |
\\ || // |
IF-A \\ || // IF-C |
+---------+ +-----+
MUIIMP | M A G | -----IF-D-------- | M R |
+---------+ +-----+
/ | \
MN-1 MN-2 MN-3
Figure 1: The basic deployment of MUIIMP in PIMPv6 networks
Zhang et al. Expires November 24, 2015 [Page 7]
Internet-Draft Multi-Upstream Interfaces IGMP/MLD Proxy May 2015
+----+-----+--------+---------------------+-----------------+
|Node| LMA | Type | Multicast Channel | Default U-IF |
+----+-----+--------+---------------------+-----------------+
| | | | (m1,EXCLUDE,{}) | |
| | | |---------------------| |
|MN-1|LMA-1|Receiver| (m2,EXCLUDE,{}) | IF-A |
| | | |---------------------| |
| | | | (m3,INCLUDE,{a}) | |
+----+-----+--------+---------------------+-----------------+
| | | | (m1,EXCLUDE,{}) | |
| | | |---------------------| |
|MN-2|LMA-2|Receiver| (m2,INCLUDE,{b}) | IF-B |
| | | |---------------------| |
| | | | (m3,EXCLUDE,{}) | |
+----+-----+--------+---------------------+-----------------+
| | |Receiver| (m1,EXCLUDE,{}) | |
|MN-3|LMA-3|--------|---------------------| IF-C |
| | | Source | m2 | |
+----+-----+--------+---------------------+-----------------+
Table 1: Detailed information of each MN
The operation of the MUIIMP is described as follows:
1) MN1 firstly subscribes (m1,EXCLUDE,{}), (m2,EXCLUDE,{}) and
(m3,INCLUDE,{a}), the MUIIMP initiates the corresponding IGMP/MLD
subscription through the IF-A.
Zhang et al. Expires November 24, 2015 [Page 8]
Internet-Draft Multi-Upstream Interfaces IGMP/MLD Proxy May 2015
2) When MN2 (as well as MN3) subscribes (m1,EXCLUDE,{}), since there
exists the same IGMP/MLD subscription through the IF-A, the MUIIMP
will not initiate extra IGMP/MLD subscription.
3) When MN2 subscribes (m2,INCLUDE,{b}), since (m2,EXCLUDE,{}) has
been subscribed, the MUIIMP does not initiate extra IGMP/MLD
subscription.
4) When MN2 subscribes (m3,EXCLUDE,{}), since (m3,INCLUDE,{a}) has
been subscribed through the IF-A, the MUIIMP will send IGMP/MLD
subscription of (m3,EXCLUDE,{a}) through the IF-B.
5) When MN3 acts one of the sources for m2, traffic from MN3 are
transmitted to the downstream interface towards MN1 as well as the
IF-C. Besides, IGMP/MLD subscription of (m2,EXCLUDE,{}) sent by
the MUIIMP through the IF-A is modified as (m2,EXCLUDE,{MN3}).
6) When MN1 hands over, the tunnel interface IF-A will be deleted
and the MUIIMP needs to deal with this scenario because the
subscriptions of MN2 and MN3 was sent through the IF-A previously.
Here, IF-B and IF-C, as the default upstream interfaces of MN2 and
MN3, are two candidate upstream interfaces for m1 subscription.
Then, the predefined customized policy can be used to select a new
U-IF from the candidate upstream interfaces. As for
(m2,INCLUDE,{b}) and (m3,EXCLUDE,{}), they are only subscribed by
the MN2, thus, the IF-B will be selected as the new U-IF for them.
It is worth noting that the fixed node (FN) connecting to the MAG can
be regarded as an MN that never handovers. The default upstream
interface of FN can be an interface adjacent to multicast domain,
like the IF-D in Figure 1.
5. Security Considerations
This document does not contain any security considerations.
6. Security Considerations
There are presently no IANA considerations with this document.
7. References
[1] H. Zhang, Z. Yan, S. Gao, L. Wang, Q. Wu and H. Li, "Multicast
Source Mobility Support in PMIPv6 Network", draft-zhang-
multimob-msm-03, July 2011.
[2] T C. Schmidt, S. Gao, H. Zhang and M. Waehlisch, "Mobile
Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6)
Domains", draft-ietf-multimob-pmipv6-source-03, February 2013.
Zhang et al. Expires November 24, 2015 [Page 9]
Internet-Draft Multi-Upstream Interfaces IGMP/MLD Proxy May 2015
[3] B. Fenner, H. He, B. Haberman and H. Sandick, "Internet Group
Management Protocol (IGMP) / Multicast Listener Discovery
(MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC
4605, August 2006.
[4] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A.
Thyagarajan, "Internet Group Management Protocol, Version3",
RFC 3376, October 2002.
[5] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004.
[6] T. Schmidt, M. Waehlisch and S. Krishnan, "Base Deployment
forMulticast Listener Support in Proxy Mobile IPv6 (PMIPv6)
Domains", RFC 6224, April 2011.
[7] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2000.
[8] LM. Contreras, CJ. Bernardos and JC. Zuniga, "Extension of the
MLD proxy functionality to support multiple upstream
interfaces", draft-contreras-multimob-multiple-upstreams-01,
February 2013.
Zhang et al. Expires November 24, 2015 [Page 10]
Internet-Draft Multi-Upstream Interfaces IGMP/MLD Proxy May 2015
Authors' Addresses
Hong-Ke Zhang
National Engineering Lab for NGI Interconnection Devices
Beijing Jiaotong University, Beijing, China
Email:hkzhang@bjtu.edu.cn
Shuai-Gao
National Engineering Lab for NGI Interconnection Devices
Beijing Jiaotong University, Beijing, China
Email:shgao@bjtu.edu.cn
Thomas C. Schmidt
HAW Hamburg
Berliner Tor 7
Hamburg 20099
Germany
Email: schmidt@informatik.haw-hamburg.de
URI: http://inet.cpt.haw-hamburg.de/members/schmidt
Bo-Hao Feng
National Engineering Lab for NGI Interconnection Devices
Beijing Jiaotong University, Beijing, China
Email:11111021@bjtu.edu.cn
Fei-Song
National Engineering Lab for NGI Interconnection Devices
Beijing Jiaotong University, Beijing, China
Email:fsong@bjtu.edu.cn
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Zhang et al. Expires November 24, 2015 [Page 11]
