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
<draft-von-hugo-multimob-ro-compa-00.txt>
Abstract
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.
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
http://www.ietf.org/1id-abstracts.html.
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
http://www.ietf.org/shadow.html
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
protocol.
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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),
respectively.
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
M-LMA.
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
[I-D.asaeda-multimob-pmip6-extension].
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
[I-D.sijeon-multimob-mms-pmip6].
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
2005.
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
[I-D.asaeda-multimob-pmip6-extension]
Asaeda, H., Seite, P., and J. Xia, "PMIPv6 Extensions for
Multicast", draft-asaeda-multimob-pmip6-extension-05 (work
in progress), February 2011.
[I-D.deng-multimob-pmip6-requirement]
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.
[I-D.ietf-mboned-auto-multicast]
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
[I-D.ietf-multimob-pmipv6-base-solution]
Schmidt, T., Waehlisch, M., and S. Krishnan, "Base
Deployment for Multicast Listener Support in PMIPv6
Domains",
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
[I-D.sijeon-multimob-mms-pmip6]
Jeon, S. and Y. Kim, "Mobile Multicasting Support in
Proxy Mobile IPv6", draft-sijeon-multimob-mms-pmip6-02
(work in progress), March 2010
[I-D.zuniga-multimob-smspmip]
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
Japan
Email: asaeda@wide.ad.jp
URI: http://www.sfc.wide.ad.jp/~asaeda/
von Hugo, et al. Expires September 4, 2011 [Page 14]