Network Working Group Seil Jeon
Internet-Draft Younghan Kim
Intended status: Standards Track Soongsil University, Korea
Expires: January 11, 2012 July 11, 2011
PMIPv6 Multicasting Support using Native Infrastructure
draft-sijeon-multimob-direct-routing-pmip6-01.txt
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. The list of current Internet-Drafts is at
http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
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 11, 2012.
Jeon, et al. Expires January 11, 2012 [Page 1]
Internet-Draft PMIPv6 Multicasting Support July 11, 2011
Copyright 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 Simplified 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.
Jeon, et al. Expires January 11, 2012 [Page 2]
Internet-Draft PMIPv6 Multicasting Support July 11, 2011
Abstract
To support IP multicasting in PMIPv6 domain, [RFC6424] has been
determined as a base solution. This solution requires all the LMA to
forward multicast packets to MAG via PMIPv6 tunnel. This approach
creates a tunnel convergence problem. To resolve the issue, the
current MULTIMOB WG charter is trying to draw a solution about how to
separate multicasting routing from a mobility anchor. To address the
issue, we propose the local routing approach that makes the direct
connection between MAG and multicast router. The advantages of the
proposed local routing solution are compared with the base solution
and dedicated LMA approach. In addition, we present the applicability
of local routing solution depending on several constraints.
Table of Contents
1. Introduction.....................................................4
2. Terminology and Functional Components............................5
3. Local Routing Solution...........................................6
3.1. Architecture.................................................6
3.2. Handover Procedure...........................................7
4. Comparison with Base Solution, Dedicated LMA, and Local Routing..8
4.1. Tunnel Convergence...........................................8
4.2. Complexity in LMA............................................8
4.3. Packet Overhead..............................................8
4.4. Another Advantage............................................9
5. Applicability....................................................9
6. Message Header...................................................9
6.1. MLD Query....................................................9
6.2. MLD Report..................................................10
6.3. Multicast Packet............................................10
7. IANA Considerations.............................................11
8. Security Considerations.........................................11
9. References......................................................11
9.1. Normative References........................................11
9.2. Informative References......................................12
Authors' Addresses.................................................13
Jeon, et al. Expires January 11, 2012 [Page 3]
Internet-Draft PMIPv6 Multicasting Support July 11, 2011
1. Introduction
PMIPv6 is a network-based IP mobility protocol that requires no host
stack involvements; it provides enhanced mobility performance
compared to host-based approaches like MIPv6, FMIPv6. However,
current PMIPv6 specification does not explicitly address the method
of multicasting communications [RFC5213].
To support multicasting in PMIPv6 domain, the base solution proposes
deployment option [RFC6424], which places multicast routing on LMA.
MAG receives a multicast stream from LMA by using PMIPv6 tunnel. It
is simply derived from PMIPv6 specification and requires no
modification to PMIPv6 components and MNs. However, the base solution
introduces a tunnel convergence issue in case a MAG receives the same
multicast packets from more than one LMA. This causes severe network
bandwidth. To avoid a tunnel convergence problem, the current
MULTIMOB WG charter is trying to d a solution on how to separate
multicasting routing from the mobility anchor. As potential
techniques, two kinds of approaches have been presented: a dedicated
mobility anchor and local routing.
The concept of dedicated LMA is to assign dedicated multicasting LMA
to each MAG. This approach resolves tunnel convergence issues but
introduces tunnel avalanche problem because M-LMA needs to replicate
data streams to all MAGs. It imposes a heavy burden on the M-LMA to
process and forward tunnel packets. Additionally, it makes severe
packet tunneling overhead.
In this draft, we propose a local routing solution that a MAG
receives multicast packets directly from MR without any tunnel. This
solution can completely solve tunnel-related performance issues by
placing MLD proxy on a MAG and allowing multicast connectivity
between the MAG and MR. With the description of local routing
operation, we present the comparisons of a few of candidate solutions
in terms of performance. In addition, we also check the applicability
of local routing depending on several constraints.
Jeon, et al. Expires January 11, 2012 [Page 4]
Internet-Draft PMIPv6 Multicasting Support July 11, 2011
2. Terminology and Functional Components
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.
o Mobile Node (MN)
o Previous Mobile Access Gateway (P-MAG) - The MAG that manages
mobility related signaling for a MN before handover.
o New Mobile Access Gateway (N-MAG) - The MAG that manages mobility
related signaling for the MN after handover
o Multicast Router (MR)
o MLD Proxy (M-Proxy)
Jeon, et al. Expires January 11, 2012 [Page 5]
Internet-Draft PMIPv6 Multicasting Support July 11, 2011
3. Local Routing Solution
3.1. Architecture
Multicast Tree
:
: || - PMIPv6 Tunnel
+----------+ +----------+ | - Multicast Data Path
| LMA | | MR |
+----------+ +----------+
||\\ /|
|| \\ / |
|| \\ / |
|| \\ / |
|| \\/ |
|| / \\ |
|| / \\ |
|| / \\ |
+----------+ +----------+
| P-MAG | | N-MAG |
|(M-Proxy) | |(M-Proxy) |
+----------+ +----------+
: :
+------+ +------+
| MN | -----> | MN |
+------+ +------+
Figure 1. Direct routing solution for PMIPv6 Multicasting
Figure 1 shows the proposed local routing architecture using native
multicasting infrastructure [I-D.deng-multimob-pmip6-requirement]. To
forward IGMP/MLD signaling and multicast packets, a MLD proxy
function defined in [RFC4605], SHOULD be placed on a MAG. This
solution is much simpler than the base solution and easy to deploy
because multicasting functions are totally separated from mobility
anchor by using a native multicasting infrastructure.
Jeon, et al. Expires January 11, 2012 [Page 6]
Internet-Draft PMIPv6 Multicasting Support July 11, 2011
3.2. Handover Procedure
Multicast
MN P-MAG N-MAG LMA MR Tree
| | | | | |
| | | | | |
|<----------|<-- Multicast Data--------------|<-------|
| | . | | | |
| | . | | | |
| | . | | | |
Link->| Handover | | | |
Disconnected Detection | | | |
| | | | | |
| | | | | |
| | MN Attachment | | |
| | | | | |
| | | | | |
|------ Rtr. Sol. ----->| | | |
| | | | | |
|<----- MLD Query ------| | | |
| | | | | |
|------ MLD Report ---->| | | |
| | | Aggregated | |
| | |--- MLD Report ---->| |
| | | | | |
| | | | | |
|<----------------------|<-- Multicast Data--|<-------|
| | | | | |
| | | | | |
| | | Proxy | | |
| | |--Binding->| | |
| | | Update | | |
| | | | | |
| | | Proxy | | |
| | |<-Binding--| | |
| | | Ack. | | |
| | | | | |
Figure 2. Handover procedure in direct routing architecture
Figure 2 shows the handover operation in local routing architecture.
When an MN hands off to the N-MAG from the P-MAG, the N-MAG detects
Jeon, et al. Expires January 11, 2012 [Page 7]
Internet-Draft PMIPv6 Multicasting Support July 11, 2011
the newly arrived MN and transmits an MLD query message to the MN.
After receiving the MLD query message, the MN sends an MLD report
message that includes the multicast group information. The N-MAG then
sends an aggregated MLD report message to the MR. When the N-MAG
receives the multicast packets from the MR, it then simply forwards
them without tunnel encapsulation. The N-MAG updates the MN's
location information to the LMA by exchanging PBU/PBA signaling
messages.
4. Comparison with Base Solution, Dedicated LMA, and Local Routing
In this section, we compare the direct routing with the base solution
[RFC6424] and dedicated LMA [I-D.zuniga-multimob-smspmip] in terms of
performance, ease of deployment, and other factors.
4.1. Tunnel Convergence
In the base solution, the MR function is combined with LMA. Thus, all
the packets are delivered to MNs through PMIPv6 tunnel between MAG
and LMA, which raises the tunnel convergence problem. because a MAG
may receive the same multicast packets from several LMAs. Dedicated
LMA and the proposed direct routing have different approaches;
however, they can avoid the tunnel convergence issue.
4.2. Complexity in LMA
In the tunnel-based approaches, a LMA needs to deal with MLD
signaling, join/leave procedure, and tunnel packet processing (i.e.,
encapsulating/decapsulating and tunnel packet lookup) as well as the
role of mobility anchor. When using a dedicated entity, these
complexities can be reduced but cannot be avoided completely. On the
other hand, the direct routing is absolutely not affected by these
complexities.
4.3. Packet Overhead
Using native multicasting infrastructure, local routing does not make
tunneling overhead for multicast data delivery while tunnel-based
approaches require 40 bytes of IP tunnel header per packet. According
as packet arrival rate increases, the overhead becomes much severe.
Jeon, et al. Expires January 11, 2012 [Page 8]
Internet-Draft PMIPv6 Multicasting Support July 11, 2011
4.4. Another Advantage
When we consider that MNs move to non-PMIPv6 domains from PMIPv6
domains as described in [I-D.von-hugo-multimob-future-work], the
direct routing approach can provide a compatible method because it
does not depend on PMIPv6 tunnel for multicasting operation.
5. Applicability in Visited Network
If a multicast listener is in visited network, the local routing can
be applied on the condition that there are a multicast peering
entities, e.g., content delivery network (CDN), inter-domain
multicast routing like BGMP [RFC3913] or MBGP [RFC4765] in visited
network. At that time, the multicast channel used in home network MAY
be different in visited network therefore, the listener MAY need to
wait a time for joining the channel informed from visited network but
this latency can be reduced through handover optimization technique
with multicast context transfer.
In particular, the source in which the multicast listener is
interested and the receiver are in same visited network, the local
routing is used efficiently than tunnel-based multicast transmission
technique using home subscription because local routing provides much
optimized routing path for delivering multicast data transmission
regardless of the number of channels and receivers.
6. Message Formats
This section describes source and destination address of MLD
signaling messages. The interface A-B means that an interface on node
A, which is connected to node B.
6.1. MLD Query
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface | Source Address | Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MR-MAG | MR link local | [RFC2710], [RFC3810] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAG-MN | MAG link local | [RFC2710], [RFC3810] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jeon, et al. Expires January 11, 2012 [Page 9]
Internet-Draft PMIPv6 Multicasting Support July 11, 2011
6.2. MLD Report
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface | Source Address | Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN-MAG | MN link local | [RFC2710], [RFC3810] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAG-MR | MAG link local | [RFC2710], [RFC3810] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.3. Multicast Packets
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface | Source Address | Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MR-MAG | Streaming Source Addr. | Multicast Group Addr. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAG-MN | Streaming Source Addr. | Multicast Group Addr. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jeon, et al. Expires January 11, 2012 [Page 10]
Internet-Draft PMIPv6 Multicasting Support July 11, 2011
7. IANA Considerations
TBD.
8. Security Considerations
This document does not discuss any special security concerns in
detail. The protocol of this document is built on the assumption that
all participating nodes are trusted each other as well as there is no
adversary who modifies/injects false messages to corrupt the
procedures.
9. References
9.1. Normative References
[RFC2710] S. Deering, W. Fenner, B. Harberman, "Multicast Listener
Discovery (MLD) for IPV6", IETF RFC 2710, October 1999.
[RFC3810] R. Vida, and L. Costa, "Multicast Listener Discovery
Version(MLDv2) for IPv6", IETF RFC 3810, June 2004.
[RFC5213] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, and
B. Patil, "Proxy Mobile IPv6", IETF RFC 5213, August 2008.
[RFC4605] B. Fenner, H. He, B. Haberman, and H. Sandick, "Internet
Group Management Protocol (IGMP) / Multicast Listener
Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD
Proxying")", IETF RFC 4605, August 2006.
[RFC6424] T. Schmidt, M. Waehlisch, and S. Krishnan, "Base
Deployment for Multicast Listener Support in PMIPv6
Domains", IETF RFC 6424, April 2011.
Jeon, et al. Expires January 11, 2012 [Page 11]
Internet-Draft PMIPv6 Multicasting Support July 11, 2011
9.2. Informative References
[RFC3913] D. Thaler, "Border Gateway Multicast Protocol (BGMP):
Protocol Specification," IETF RFC 3913, September 2004.
[RFC4765] T. Bates, R. Chandra, D. Katz, and Y. Rekhter,
"Multiprotocol Extensions for BGP-4," IETF RFC 4765,
January 2007.
[I-D.deng-multimob-pmip6-requirement]
H. Deng, T. Schmidt, P. Seite, and P. Yang, "Multicast
Support Requirements for Proxy Mobile IPv6", draft-deng-
multimob-pmip6-requirement-02.txt (work in progress), July
2009.
[I-D.zuniga-multimob-smspmip]
J. C. Zuniga, A. Rahman, L. M. Contreras, C. J. Bernardos,
and I. Soto, "Support Multicast Services Using Proxy Mobil
IPv6," draft-zuniga-multimob-smspmip-05.txt (work in
progress), March 2011.
[I-D.von-hugo-multimob-future-work]
D. von Hugo, H. Asaeda, B. Sarikaya, and P. Seite,
"Evaluation of further issues on Multicast Mobility:
Potential future work for WG MultiMob", draft-von-hugo-
multimob-future-work-02.txt (work in progress), Juney
2010.
Jeon, et al. Expires January 11, 2012 [Page 12]
Internet-Draft PMIPv6 Multicasting Support July 11, 2011
Authors' Addresses
Seil Jeon
Soongsil University
4F Hyungnam Engineering Bldg. 424, Sangdo-Dong,
Dongjak-Gu, Seoul 156-743 Korea
Phone: +82-2-820-0841
E-mail: sijeon@dcn.ssu.ac.kr
Younghan Kim
Soongsil University
11F Hyungnam Engineering Bldg. 1107, Sangdo-Dong,
Dongjak-Gu, Seoul 156-743 Korea
Phone: +82-2-820-0904
E-mail: yhkim@dcn.ssu.ac.kr
Jeon, et al. Expires January 11, 2012 [Page 13]