[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

    PIM Working Group                                         Hong-Ke Zhang
    Internet Draft                                                Shuai Gao
    Intended status: Standards Track            Beijing Jiaotong University
    Expires: January 13, 2014                                   T C.Schmidt
                                                                HAW Hamburg
                                                                Bo-hao Feng
                                                                 Li-Li Wang
                                                Beijing Jiaotong University
                                                              July 14, 2013
    
    
                     Multi-Upstream Interfaces IGMP/MLD Proxy
                           draft-zhang-pim-muiimp-01.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 January, 2014                 [Page 1]
    

    Internet-Draft  Multi-Upstream Interfaces IGMP/MLD Proxy      July 2013
    
    
       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 January, 2014.
    
    Copyright Notice
    
       Copyright (c) 2012 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
       6. References......................................................9
       Authors' Addresses................................................11
       Acknowledgment....................................................11
    
    
    
    
    
    
    
    
    
    
    
    
    Zhang et al.            Expires January, 2014                 [Page 2]
    

    Internet-Draft  Multi-Upstream Interfaces IGMP/MLD Proxy      July 2013
    
    
      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 extend the multicast
       scope and greatly simplify the implementation of edge devices.
       However,  the  IGMP/MLD  proxy  may  exhibit  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 result in 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 firstly proposed 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 January, 2014                 [Page 3]
    

    Internet-Draft  Multi-Upstream Interfaces IGMP/MLD Proxy      July 2013
    
    
      3. MUIIMP Operation
    
       The MUIIMP inherits the basic rule of the IGMP/MLD proxy but 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. In order to avoid the redundant multicast traffic, the
       proxy device should initiate unique traffic subscriptions. Besides,
       a policy list that records the default upstream interface for the
       downstream nodes is held for the selection of upstream interface.
    
       According to the role of the downstream nodes, the operation of the
       MUIIMP device will be 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 are 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
    
       When 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 January, 2014                 [Page 4]
    

    Internet-Draft  Multi-Upstream Interfaces IGMP/MLD Proxy      July 2013
    
    
       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 which is 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 word, 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
    
       To avoid the redundant multicast traffic, the proxy device MUST NOT
       send the same multicast subscription record on different upstream
       interfaces simultaneously. In detail, 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  exists  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 January, 2014                 [Page 5]
    

    Internet-Draft  Multi-Upstream Interfaces IGMP/MLD Proxy      July 2013
    
    
       4) If there exists 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 January, 2014                 [Page 6]
    

    Internet-Draft  Multi-Upstream Interfaces IGMP/MLD Proxy      July 2013
    
    
       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 January, 2014                 [Page 7]
    

    Internet-Draft  Multi-Upstream Interfaces IGMP/MLD Proxy      July 2013
    
    
       +----+-----+--------+---------------------+-----------------+
    
       |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 January, 2014                 [Page 8]
    

    Internet-Draft  Multi-Upstream Interfaces IGMP/MLD Proxy      July 2013
    
    
       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
    
       To be done.
    
      6. 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 January, 2014                 [Page 9]
    

    Internet-Draft  Multi-Upstream Interfaces IGMP/MLD Proxy      July 2013
    
    
       [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 January, 2014                [Page 10]
    

    Internet-Draft  Multi-Upstream Interfaces IGMP/MLD Proxy      July 2013
    
    
    Authors' Addresses
    
       Hong-Ke Zhang, Shuai-Gao, Bo-Hao Feng, Li-Li Wang
       National Engineering Lab for NGI Interconnection Devices
       Beijing Jiaotong University, Beijing, China
    
       Phone: +861051684274
       Email:hkzhang@bjtu.edu.cn
             shgao@bjtu.edu.cn
             11111021@bjtu.edu.cn
             liliwang@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
    
    
    
    Acknowledgment
    
       Funding for the RFC Editor function is currently provided by the
       Internet Society.
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    Zhang et al.            Expires January, 2014                [Page 11]
    

Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/