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

Versions: 00

MULTIMOB Working Group                                       D. von Hugo
Internet-Draft                             Deutsche Telekom Laboratories
Intended status: Informational                            Hitoshi Asaeda
Expires: September 7, 2011                               Keio University
                                                           March 7, 2011

         Comparison of Multicast Mobility Route Optimization


   The Multimob WG has defined a basic mobile multicast solution
   leveraging on network localized mobility management, i.e.  Proxy
   Mobile IPv6 protocol.  The basic solution incorporates multicast
   aware routers co-located with the mobility anchor and a proxy
   functionality for group management, i.e.  IGMP/MLD, at the access
   gateway.  Although such a basic solution solves the issue from an
   operational point of view, challenges with respect to optimization,
   e.g. efficient resource utilization, still remain.

   This document attempts to evaluate proposed solutions for the
   chartered work item of "PMIPv6 routing optimizations to avoid tunnel
   convergence problem". A corresponding deployment specific extension
   would cover dynamic and/or automatic tunnel configuration and a
   direct or local routing approach.

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 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."

   The list of current Internet-Drafts can be accessed at

von Hugo, et al.         Expires September 7, 2011              [Page 1]

Internet-Draft     MultiMob Route Optimization Comparison     March 2011

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on September 7, 2011.

Copyright and License 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 BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

von Hugo, et al.         Expires September 7, 2011              [Page 2]

Internet-Draft      MultiMob Route Optimization Comparison    March 2011

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Route Optimized MultiMob Architecture. . . . . . . . . . . . .  4
   4.  Proposed Solutions for Optimized or local Routing. . . . . . .  6
   5.  Adaptation of MBoneD approach. . . . . . . . . . . . . . . . .  8
   6.  Requirements on Solutions  . . . . . . . . . . . . . . . . . . 11
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
  10.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
    10.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
    10.2.  Informative References . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14

von Hugo, et al.         Expires September 7, 2011              [Page 3]

Internet-Draft      MultiMob Route Optimization Comparison    March 2011

1.  Introduction

   The Multimob WG has focuses on documentation of proper
   configuration and usage of existing (specified standard) protocols
   with both mobility and multicast related areas to enable and
   support mobility for multicast services and vice versa.  The current
   'RFC to be' WG document [I-D.ietf-multimob-pmipv6-base-solution]
   describes how to deploy multicast listener functionality in PMIPv6
   [RFC5213] domains according to basic requirements i.e. without
   modifying mobility and multicast protocol standards.  However beside
   aggregation of multiple (downstream) multicast subscriptions at the
   MAG no specific optimizations and efficiency improvements of
   multicast routing for network-based mobility are addressed.  Such an
   operation which considers more efficient resource usage at network
   and nodes may require actual modification and extension of the base

   This draft attempts to compare proposed approaches to include Route
   Optimization and direct local routing support in the basic solution
   and the application of an existing approach from another WG  - which
   can help to reduce the amount of transport resource usage and
   transmission delay.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

   This document uses the terminology defined in [RFC3775], [RFC3376],
   [RFC3810], [RFC5213], [RFC5757].

3.  Route Optimized MultiMob Architecture

   Potential extensions to multimob basic solution would mainly rely on
   IGMPv3/MLDv2 Proxy [RFC4605] support at the mobile access gateway
   (MAG) as proposed in the basic Multimob solution
   [I-D.ietf-multimob-pmipv6-base-solution].  Thus at the MAG of Proxy
   Mobile IPv6 an IGMPv3/MLDv2 Proxy functionality keeps multicast
   state on the subscriptions of the mobile nodes (MNs).  The local

von Hugo, et al.         Expires September 7, 2011              [Page 4]

Internet-Draft      MultiMob Route Optimization Comparison    March 2011

   mobility anchor (LMA) on the other hand keeps an aggregate state and
   thus when receiving multicast data from the outside world, which may
   be either native multicast enabled or not, LMA can forward it to the
   MAG without duplication because MAG takes care of the packet
   duplication before delivering to the different subscribers.  This
   leads to solving the avalanche problem.

   However, IGMPv3/MLDv2 introduces tunnel convergence problem which
   occurs when a given MAG serves MNs that belong to different LMAs and
   MNs subscribe to the same multicast group.  In that case MNs receive
   duplicate multicast data forwarded from more than one LMA.

   The architecture for route optimization and direct routing is shown
   in Figure 1.

                        +----+      +----+
                        |LMA1|      |LMA2|\
                        +----+      +----+ \
                           |          |     \
                           |          |      \
                        ***  ***  ***  ***    \
                       *   **   **   **   *    \
                        *                  *    +-------------+
                       *  Local Routing   *     | Content     |
                        *                  *....| Delivery    |
                       *                  *     | Network     |
                        *   **   **   ***       +-------------+
                         ***  ***  ***
                            ||       ||
                          +----+    +----+
                          |MAG1|    |MAG2|
                          +----+    +----+
                           |  |        |
                           |  |        |
                          MN1 MN2      MN3

           Figure 1: Optimized and local Multicast routing

   The basic approach of multicast traffic forwarding via the MAG-LMA
   tunnel (i.e. in case that a multicast router (MR) is co-located in
   LMA as defined in the base solution

von Hugo, et al.         Expires September 4, 2011              [Page 5]

Internet-Draft      MultiMob Route Optimization Comparison    March 2011

   [I-D.ietf-multimob-pmipv6-base-solution]) may introduce in specific
   situations a tunnel convergence problem and lead to waste of
   network bandwidth usage.  A Multicast Router as assumed here would
   support native multicast operation as e.g. defined in [RFC4607].

4.  Proposed Solutions for Optimized or Local Routing

   Currently discussed aspects of multicast optimization for PMIPv6
   include introduction of a bi-directional Multicast Tunnel (M-Tunnel)
   between LMA and MAG as described in
   [I-D.asaeda-multimob-pmip6-extension].  Separation of mobility entity
   LMA and multicast router allows MAGs to receive multicast packets
   directly and also reduces LMA complexity.  Both mobility entities MAG
   and LMA may be operated as MLD proxy or multicast router.

   For a PMIPv6 domain the establishment of a dedicated multicast tunnel
   is proposed which may either be dynamically set up and released or be
   pre-configured in a static manner.  Contrary to the MAG-LMA tunnel as
   defined in PMIPv6 [RFC5213] the static M-Tunnel is not set up per MN
   but once for all Multicast traffic between a MAG operated as MLD
   proxy.  Alternatively the MAG may be operating as multicast router
   (e.g. PIM-SM router) and thus be able to directly join an existing
   multicast tree (within the PMIPv6 domain) and thus provide direct or
   local routing without including the LMA.  The LMA however is kept
   informed of mutlicast subscriptions to be ready to forward data e.g.
   via the statically pre-configured M-tunnel between MAG and LMA.  Thus
   in case of handover additional delay or packet loss is prevented
   which otherwise might occur before the new MAG has established direct
   routing of multicast data .

   The protocol defines a Proxy Binding Update with multicast extension
   (PBU-M) (new C flag) for the Proxy MLD enabled MAG to request the LMA
   to forward multicast data.  For handover the Context Transfer
   Protocol (CXTP) [RFC4067] or an MN profile may be used and a
   Multicast Context Transfer Data (M-CTD) message is defined to be
   exchanged between MAGs.

   Whereas MAG is envisaged to act either as a multicast router for
   direct local routing or as an MLD proxy forwarding the multicast
   management messages to the corresponding LMA, the LMA can either be
   operated also as an MLD proxy or as a multicast router according to
   the MAG's cofiguration.

von Hugo, et al.         Expires September 4, 2011              [Page 6]

Internet-Draft      Route Optimization  for MultiMob WG       March 2011

   Altogether the approach [I-D.asaeda-multimob-pmip6-extension]
   supports 3 different scenarios:

   (1) MR@MAG and MR@LMA,
   (2) MLD-Proxy@MAG and MLD-Proxy@LMA,
   (3) MLD-Proxy@MAG and MR@LMA,
   in terms of functionalities at MAG and LMA, by proposing protocol
   extensions for PMIPv6 (C-flag in PBU) and CXTP (M-CTD message),

   Another approach to introduce multicast traffic replication
   mechanisms is proposed in [I-D.zuniga-multimob-smspmip].  Here by
   introducing a Dedicated Multicast LMA (DM-LMA) as topological anchor
   point for multicast traffic protocol complexity is reduced in terms
   of time consuming tunnel set-up by definition of pre- or post-
   configured tunnels between LMA and MAG.  This scheme to PMIPv6
   domains uses dedicated LMAs for Unicast (U-LMA) and for Multicast
   (M-LMA) as specific topological anchor point for unicast and
   multicast traffic, respectively, while the MAG remains as an IGMP/MLD
   proxy. The solution is applied to different scenarios which are
   characterised by varying ratio of U-LMA:M-LMA and also introduces a
   hybrid H-LMA simultaneously transporting multicast service to an
   entire group of MNs within a PMIPv6 domain and unicast service to a
   subset of them.

   Thanks to separation of unicast and multicast traffic at LMA in
   specific scenarios a gradual network upgrade of a PMIPv6 domain to
   support multicast functionality and minimized replication of
   multicast packets may take place.  The amount of replicated packets
   will be more limited using this aproach for increasing number of MAGs
   per LMA and MNs per MAG as compared to the basic solution.

   Required enhancements to the Proxy Mobile IPv6 [RFC5213] protocol to
   support the M-LMA architecture are an update of the Binding Update
   List in MAG to enable handling of more than one LMA (i.e. U-LMA and
   M-LMA) serving the mobile node, extension of a mobile node's policy
   profile information to store the IPv6 addresses of both the U-LMA and
   M-LMA, and additional capability of MAG procedures to be able to
   handle simultaneous attachment of a mobile node to both the U-LMA and

   Recently expired draft [I-D.sijeon-multimob-mms-pmip6] describes a
   direct or local routing approach applicable to a network topology
   where multicast content delivery source is located in the same

von Hugo, et al.         Expires September 7, 2011              [Page 7]

Internet-Draft      Route Optimization  for MultiMob WG       March 2011

   network such that the optimal multicast service delivery path is not
   via LMA.

   The support of optimal local (direct) routing uses a direct
   connection between MLD proxy at MAG and a multicast router separated
   from LMA. By making no use of base multimob solution
   [I-D.ietf-multimob-pmipv6-base-solution] this solution proposes to
   save complexity.

5.  Adaptation of AMT

   [I-D.ietf-mboned-auto-multicast] describes an approach of
   the MBONED (Multicast Backbone Deployment) WG which allows
   automatic multicast communication without explicit tunnels (AMT).
   This mechanism can be applied to isolated multicast-enabled sites or
   hosts, attached to a network without native multicast support -
   without need for any manual configuration.  Communication between
   these sites and the backbone is established by AMT gateway and AMT
   relay - similar to MAG and LMA communication. The analogy between AMT
   and PMIP-based Multimob is shown in Figure 2.

   However, compared to the basic multimob solution and the proposed
   extensions summarized in sect. 4, the AMT approach does not introduce
   any further advantage: Either the required tunnel is already
   available via MAG-LMA cooperation or and an additional tunnel has to
   be set up which adds more complexity instead of simplifying things.

   The analogy to the Multimob WG is described in the following:

   Each MAG with multicast subscribing MNs attached behaves as an AMT
   Gateway which has already established via a three way handshake a
   tunnel to an AMT Relay or does so on subcription of a MN - similar to
   an M-Tunnel set-up as proposed in

   A dedicated multicast LMA or a local MR with native multicast support
   behaves like an AMT Relay in that join messages are forwarded within
   the native Multicast environment and on the other hand received
   multicast traffic is subsequently forwarded via the AMT interface to
   the MAG/AMT Gateway.  Such a dedicated multicast DM-LMA is proposed
   by [I-D.zuniga-multimob-smspmip].

von Hugo, et al.         Expires September 4, 2011              [Page 8]

Internet-Draft      Route Optimization  for MultiMob WG       March 2011

   Since between MAG and LMA already a security association may be
   already established according to RFC5213, the handshake mechanism may
   be not required.

   An AMT relay can also provide direct local routing of traffic to the
   requesting MAG independent of any LMA as proposed in

   On the other hand, the situation may be different in client MIPv6 for
   which the AMT approach would add advantage.  A MIPv6 enabled MN
   having the AMT gateway function implemented might result in a large
   functionality set on a usually small, power- and size limited MN and
   thus a reduced lite-AMT version would be a feasible approach.

   However, a generally more complex NEMO [RFC3963] Mobile Router should
   have the capability to host also the AMT Gateway functionality and
   serve a set of nodes (LFN, MNN,...) with multicast traffic so that
   the AMT approach [I-D.ietf-mboned-auto-multicast] may be appropriate
   for such NEMO MultiMob support.

von Hugo, et al.         Expires September 4, 2011              [Page 9]

Internet-Draft     Route Optimization  for MultiMob WG        March 2011

    +---------------+        Internet            +---------------+
    | AMT Site      |                            | Native MCast  |
    |               |                            |               |
    |        +------+----+         AMT      +----+----+ AMT      |
    |        |AMT Gateway|         Anycast  |AMT Relay| Subnet   |
    |        |     +-----+-+       Prefix +-+-----+   | Prefix   |
    |        |     |AMT IF | <------------|AMT IF |   |--------> |
    |        |     +-----+-+              +-+-----+   |          |
    |        +------+----+                  +----+----+          |
    |               |                            |               |
    +---------------+                            +---------------+

    +---------------+        PMIPv6 domain       +---------------+
    | MNs' site     |                            | Native MCast  |
    |               |                            |       or      |
    |        +------+----+                  +----+----+ Internet |
    |        | MLD proxy |                  |MLD proxy|          |
    |        | @   +-----+-+              +-------+/MR|          |
    |        | MAG |PMIP IF| <------------|PMIP IF| @ |--------> |
    |        |     +-----+-+              +-+-----+LMA|          |
    |        +------+----+                  +----+----+          |
    |               |                            |               |
    +---------------+                            +---------------+

    +---------------+        MIPv6 domain        +---------------+
    | NEMO site     |                            | Native MCast  |
    |               |                            |       or      |
    | or     +------+----+                  +----+----+ Internet |
    |        |AMT Gateway|                  |AMT Relay|          |
    | MN     |@    +-----+-+              +-------+   |          |
    |        |     |AMT IF | ------------>|AMT IF |   |--------> |
    |        |MN   |MIP6 IF| <------------|MIP6 IF|   |<-------- |
    |        |or   +-----+-+              +-+-----+   |          |
    |        |NEMO MR    |                  +----+----+          |
    |        +------+----+                       |               |
    |               |                            |               |
    +---------------+                            +---------------+

    Figure 2: Analogy of AMT, PMIPv6, and MIPv6 entities

von Hugo, et al.         Expires September 4, 2011             [Page 10]

Internet-Draft     Route Optimization  for MultiMob WG        March 2011

6.  Conformance with Multimob Requirements

   This section compares specific requirements for extensions
   for optimized routing in multicast mobility solutions discussed
   in the Multimob WG according to issues discussed in the original
   requirements draft [I-D.deng-multimob-pmip6-requirement] with the
   different approaches described above.

   With respect to the performance requirements:

   - PMIPv6 transmission SHOULD realize native multicast forwarding, and
   where applicable conserve network resources and utilize link layer
   multipoint distribution to avoid data redundancy.

   - Multicast mobility SHOULD minimize transport costs on the
   forwarding link, as well as any additional overhead on the multicast
   delivery path.

   the solutions attempt to fulfil the demand and partly also include
   the direct routing approach aiming also towards more resource and
   effort efficient transport.

7.  Security Considerations

   This draft does not introduce additional messages but describes
   work in progress.  Compared to [RFC3376],
   [RFC3810], [RFC3775], and [RFC5213] there have no additional threats
   been introduced.  But as pointed out in
   [I-D.deng-multimob-pmip6-requirement] security is a very crucial
   issue in mobile multicast service such that a multitude of
   participating users is introduced in the PMIPv6 domain. Therefore it
   is required to provide extra security capabilities to protect mobile
   multicast networks from any malicious attempts caused by multicast
   security holes such as denial of service attacks.

   - The multicast service in PMIPv6 MUST NOT degrade the security
   protection of the basic PMIPv6 AAA mechanism.

   - Multicast system architecture MUST provide an admission control
   mechanism to regulate any multicast events.

von Hugo, et al.         Expires September 4, 2011             [Page 11]

Internet-Draft      MultiMob Route Optimization Comparison    March 2011

   - Multicast system architecture MUST be independent of adjacent
   domains such that it shall not affect the adjacent multicast domain
   without permission.

   - Multicast system architecture MUST provide a mechanism to check
   integrity of multicast sources prior to service delivery such that it
   prevents unauthorized source to distribute multicast content.

8.  IANA Considerations

   Whereas this document does not explicitly introduce requests to IANA,
   some of the proposals referenced above (such as
   [I-D.asaeda-multimob-pmip6-extension]) specify flags for mobility
   messages or options.  For details please see those documents.

9.  Acknowledgements

   Discussion with and comments from members of the Multimob WG are
   gratefully acknowledged.

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, October 2002.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

   [RFC3963]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
              Thubert, "Network Mobility (NEMO) Basic Support Protocol",
              RFC 3963, January 2005.

   [RFC4067]  Loughney, Ed., J., Nakhjiri, M., Perkins, C., and R.
              Koodli, "Context Transfer Protocol (CXTP)", RFC 4067, July

von Hugo, et al.         Expires September 4, 2011             [Page 12]

Internet-Draft      MultiMob Route Optimization Comparison    March 2011

   [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, August 2006.

   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP", RFC 4607, August 2006.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

   [RFC5757]  Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast
              Mobility in MIPv6: Problem Statement and Brief Survey",
              RFC 5757, June 2010.

10.2.  Informative References

              Asaeda, H., Seite, P., and J. Xia, "PMIPv6 Extensions for
              Multicast", draft-asaeda-multimob-pmip6-extension-05 (work
              in progress), February 2011.

              Deng, H., Chen, G., Schmidt, T., Seite, P., and P. Yang,
              "Multicast Support Requirements for Proxy Mobile IPv6",
              draft-deng-multimob-pmip6-requirement-02 (work in
              progress), July 2009.

              Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and
              T. Pusateri, "Automatic IP Multicast Without Explicit
              Tunnels (AMT)", draft-ietf-mboned-auto-multicast-10 (work
              in progress), March 2010

              Schmidt, T., Waehlisch, M., and S. Krishnan, "Base
              Deployment for Multicast Listener Support in PMIPv6
              draft-ietf-multimob-pmipv6-base-solution-07 (work in
              progress), December 2010.

von Hugo, et al.         Expires September 4, 2011             [Page 13]

Internet-Draft      MultiMob Route Optimization Comparison    March 2010

              Jeon, S. and Y. Kim, "Mobile Multicasting Support in
              Proxy Mobile IPv6", draft-sijeon-multimob-mms-pmip6-02
              (work in progress), March 2010

              Zuniga, J., Lu, G., and A. Rahman, "Support Multicast
              Services Using Proxy Mobile IPv6",
              draft-zuniga-multimob-smspmip-04 (work in progress),
              October 2010.

Authors' Addresses

   Dirk von Hugo
   Deutsche Telekom Laboratories
   Deutsche-Telekom-Allee 7
   64295 Darmstadt, Germany

   Email: dirk.von-hugo@telekom.de

   Hitoshi Asaeda
   Keio University
   Graduate School of Media and Governance
   5322 Endo
   Fujisawa, Kanagawa  252-8520

   Email: asaeda@wide.ad.jp
   URI:   http://www.sfc.wide.ad.jp/~asaeda/

von Hugo, et al.         Expires September 4, 2011             [Page 14]

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