IP Multicast Use Case Analysis for PMIPv6.based Distributed Mobility Management
draft-sfigueiredo-multimob-use-case-dmm-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Sergio Figueiredo , Rui L. Aguiar, Seil Jeon | ||
| Last updated | 2012-03-12 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-sfigueiredo-multimob-use-case-dmm-01
MULTIMOB Group S. Figueiredo
Internet Draft R. L. Aguiar
Intended status: Standards Track Universidade de Aveiro
Expires: August 12, 2012 S. Jeon
Instituto de Telecomunicacoes
March 12, 2012
IP Multicast Use Case Analysis for PMIPv6.based Distributed Mobility
Management
draft-sfigueiredo-multimob-use-case-dmm-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.
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 August 12, 2012.
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
Figueiredo, et al. Expires August 12, 2012 [Page 1]
Internet-Draft Use Cases for Multicast DMM March 2012
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.
Abstract
As mobile networks are moving towards distributed mobility management,
the application of IP multicast is needed to provide efficient
content delivery on the network. This document describes use cases
when IP multicast is applied on PMIPv6-based DMM, and analyzes
problems focused on user plane issues.
Table of Contents
1. Introduction...................................................3
2. Conventions and Terminology....................................3
3. Use Cases Description..........................................4
3.1. Multicast listener support................................4
3.1.1. MLD-P in MAR.........................................4
3.1.1.1. Duplicated Traffic..............................5
3.1.1.2. Non-optimal routing.............................6
3.1.2. Multicast Router in MAR..............................7
3.2. Multicast sender support..................................7
3.2.1. MLD-P in MAR.........................................7
3.2.1.1. Triangular routing..............................8
3.2.2. Multicast Router in MAR.............................10
4. IANA Considerations...........................................11
5. Security Considerations.......................................11
6. References....................................................11
6.1. Normative References.....................................11
6.2. Informative References...................................11
Figueiredo, et al. Expires August 12, 2012 [Page 2]
Internet-Draft Use Cases for Multicast DMM March 2012
1. Introduction
As a consequence of the forthcoming multimedia avalanche, several
optimization mechanisms are being considered towards efficient and
resilient mobile networks. As analyzed in [DDMM-MI], current IP
mobility management solutions have limitations in supporting
efficient management and deployment. Thus, several proposals aiming
at the distribution of the mobility management functions (e.g [DDMM-
FP] were presented. The problems resulting from the application of
mobility solutions in multicast traffic are known, affecting its
efficiency and leading to non-negligible service disruption, reported
among others ([IPMM][RFC5757]). Nevertheless, it is still not clear
how the change from centralized to distributed mobility solutions may
affect IP multicast support.
This document briefly describes use cases of IP multicast in a
PMIPv6-based DMM environment, and analyses consequent problems. Both
listener and sender perspective are studied, with either MLD Proxy or
Multicast Router functionality deployed at the Mobility Access Router
(MAR).
2. Conventions and 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 [RFC5213], [RFC6275],
and [RFC3810], and [RFC4601]. Specifically, the definition of PMIPv6
domain is reused from [RFC5213] and reproduced here for completeness.
- Mobility Access Router (MAR): A router with the capability of
acting both as a mobility anchor and as an access router, in a per
flow basis.
- Previous Mobility Access Router (P-MAR): The MAR where the MN was
attached to previously to the network-layer mobility process, and
that may be acting as an anchor for one or multiple flows.
- New Mobile Access Gateway (N-MAR): The MAR to which the MN is
currently attached, providing the access functionality and thus
delivers all the flows destined to the MN.
- Multicast Listener Discovery Proxy (MLD-P): An entity following
[RFC4605].
Figueiredo, et al. Expires August 12, 2012 [Page 3]
Internet-Draft Use Cases for Multicast DMM March 2012
3. Use Cases Description
This draft focuses on describing problems that may occur when
deploying IP multicast on a general PMIPv6-derived DMM architecture.
As there is not yet a fully specified unicast DMM protocol, the
unicast DMM concept used in this document is assumed as follows: MAG
and an LMA functionalities defined in [RFC5213] are equipped within a
same physical entity, called MAR. A MAR provides tunnel-based
forwarding to provide a home network prefix (HNP)-based flow with the
necessary IP session continuity whenever the MN moves to another MAR.
We separate the use cases in multicast listener and multicast
sender support.
3.1. Multicast listener support
3.1.1. MLD-P in MAR
Once a MN initially attaches to the P-MAR (as shown in Figure 1), it
receives a home prefix address, which will be associated with
communications started at that MAR. Detecting the new logical link,
the P-MAR transmits to it a general MLD Query message, to which the
MN will not yet reply. Thus, the P-MAR adds the downstream logical
link to the MLD-P instance with uplink to the multicast
infrastructure. When the MN intends to start receiving the multicast
session, it will send an unsolicited MLD Report. On receiving the
latter message, the MLD-P tries to join the multicast channel(s) by
sending an aggregated MLD Report (with other MN's interests) through
the MLD-P upstream interface. When the joining procedure ends,
multicast data is transmitted through the same interface.
Figueiredo, et al. Expires August 12, 2012 [Page 4]
Internet-Draft Use Cases for Multicast DMM March 2012
+----------------+
| Multicast |
| Infrastructure |
+----------------+
*
* (S,G)
*
+----------+ +----------+
| P-MAR |---------------| N-MAR |
| |***************| |
| (MLD-P) |---------------| (MLD-P) |
+----------+ +----------+
* *
* *
+------+ +------+
| MN | -----> | MN |
+------+ +------+
Figure 1 Multicasting architecture using distributed mobility
management
When the MN moves from P-MAR, the N-MAR is required to establish a
tunnel for IP session continuity of the flows being sent towards the
MN's HNP assigned by the P-MAR. This implies that N-MAR determines
the MNs previous HNPs, being the exact method through which this is
achieved out of scope of this document. Following the operation of
the MLD-P [RFC4605], after the bidirectional tunnel establishment,
the following process takes place. First, the N-MAR sends a General
MLD Query, and verifies whether the MN is admissible for multicast
sessions. If so, the MLD-P at the N-MAR adds the downstream interface
corresponding to the MN, and configures the upstream interface
towards the MN's P-MAR. Like in PMIPv6 base solution for multicast
support [RFC6224], this is simple and applicable as a network-based
multicast DMM approach. However, this approach leads to a couple of
relevant issues.
3.1.1.1. Duplicated Traffic
One of those problems is duplicated traffic, a result of the tunnel
convergence problem occurring in [RFC6224]. As shown in Figure 2, MN1
and MN3, which moved from MAR1 and MAR3, respectively, are currently
located at the MAR2. Through respective established tunnels, they
receive multicast packets of the same channel through different
anchoring MARs. This causes duplicated traffic, converging to the
MAR2, with the magnitude of replicated traffic being much bigger than
that of PMIPv6. This consideration is done assuming that the number
Figueiredo, et al. Expires August 12, 2012 [Page 5]
Internet-Draft Use Cases for Multicast DMM March 2012
of MARs in future DMMdomains will be much larger than that of LMAs at
core level within a PMIPv6 domain.
As referred, when a MN first subscribes multicast content, its
current MAR's MLD-P will forward its subscription to the multicast
infrastructure. As such, an extra duplication factor may occur, if
the subscription being done is already being received from one or
multiple tunnels due to other listeners (refer to MN2 from Figure 2
for an example).
+----------------+
| Multicast Tree | *
+----------------+ *
* * *
* * *
* * *
(S,G) * (S,G) * * (S,G)
* * *
+----------+ (-->) +----------+ (<--) +----------+
| MAR1 |---------| MAR2 |---------| MAR3 |
| |*********| |*********| |
| (MLD-P) |---------| (MLD-P) |---------| (MLD-P) |
+----------+ Tun.1 +----------+ Tun.2 +----------+
* * *
* * *
* * *
+---+ move +---+ +---+ +---+ move +---+
|MN1| ---> |MN1| |MN2| |MN3| <--- |MN3|
+---+ +---+ +---+ +---+ +---+
(<--/-->) : direction of the multicast packet flow
Figure 2 Data replication
3.1.1.2. Non-optimal routing
Another issue is non-optimal routing (Figure 3). If we consider a
significantly large domain, there is the possibility that the
multicast packets need to traverse a long distance, depending on the
setup of the upstream interface of MLD-P instance, even if the
current MAR is connected to the multicast infrastructure. If an
operator wants to deploy a MLD-P instance with the upstream interface
towards multicast source or multicast routing network, for each MAR,
this issue doesn't happen. Such an approach is extremely simple and
Figueiredo, et al. Expires August 12, 2012 [Page 6]
Internet-Draft Use Cases for Multicast DMM March 2012
mobility-agnostic, but there may occur media synchronization issues
and service disruption during handoff.
+----------------+
| Multicast |
| Infrastructure |
+----------------+
*
* (S,G)
*
+----------+ +----------+
| P-MAR |------ ------| N-MAR |
| |****** ... ******| |
|(MLD-P) |------ ------| (MLD-P) |
+----------+ +----------+
* *
* *
+------+ +------+
| MN | -----> | MN |
+------+ +------+
Figure 3 Non-optimal routing problem
3.1.2. Multicast Router in MAR
TBD
3.2. Multicast sender support
In order to provide sender multicasting support, a MAR may be
required to act as MLD-P or multicast router. Depending on the
equipped functions, we describe issues relative to multicast sender
support.
3.2.1. MLD-P in MAR
In order for the multicast content to reach the multicast tree, the
MLD-P SHOULD configure its upstream interface towards a MR [PM-HOME].
In the case of MR or MAR, it MAY act as the Rendezvous Point (RP) but
Figueiredo, et al. Expires August 12, 2012 [Page 7]
Internet-Draft Use Cases for Multicast DMM March 2012
cause frequent multicast tree reconstruction and associated service
disruptions whenever the MN moves.
+------+ +----------------+
| RP |---------| Multicast |
+------+ | Infrastructure |
* +----------------+
* (S,G) |
* |
+----------+ +----------+
| P-MAR |----------| N-MAR |
| |**********| |
| (MLD-P) |----------| (MLD-P) |
+----------+ +----------+
* *
* *
+------+ +------+
| S | ----> | S |
+------+ +------+
Figure 4 Multicast sender mobility
3.2.1.1. Triangular routing
When a source is transmitting a multicast session and a mobility
process takes place, i.e the session is anchored through another MAR
(MAR1 in Figure 5), then multicast data will be sent through the
mobility tunnel between N-MAR (MAR2) and P-MAR (MAR1). A listener
(L1) that subscribed to the source's channel as is attached at the
same MAR (MAR2) will receive the multicast content from multicast
infrastructure. Therefore the traffic will traverse a non-optimal
route between the source and the listener.
Figueiredo, et al. Expires August 12, 2012 [Page 8]
Internet-Draft Use Cases for Multicast DMM March 2012
+------+ +----------------+
| RP |*********| Multicast |
+------+ | Infrastructure |
* +----------------+
* (S,G) *
* *
+----------+ +----------+
| MAR1 |-------| MAR2 |
| |*******| |
| (MLD-P) |-------| (MLD-P) |
+----------+ +----------+
* * *
* * *
+------+ move +------+ +-----+
| S | ---> | S | | L1 |
+------+ +------+ +-----+
Figure 5 Triagular routing after source mobility
The same problem also occurs in the opposite process, i.e. if a
multicast source starts transmitting multicast content at a MAR, and
a listener moves to the same MAR while receiving the source's content
(Figure 6).
+------+ +----------------+
| RP |*********| Multicast |
+------+ | Infrastructure |
* +----------------+
* (S,G) *
* *
+----------+ +----------+
| MAR1 |-------| MAR2 |
| |*******| |
| (MLD-P) |-------| (MLD-P) |
+----------+ +----------+
* * *
* * *
+------+ +----+ move +----+
| S | | L1 | <--- | L1 |
+------+ +----+ +----+
Figure 6 Triangular routing after listener mobility
Figueiredo, et al. Expires August 12, 2012 [Page 9]
Internet-Draft Use Cases for Multicast DMM March 2012
When the source and the listener are within a same MAR (MAR2)if both
the source and listener try to start the session and receive it,
respectively at MAR2, the traffic will be optimally sent to the
listener. As the traffic reaches the MLD-P via the downstream
interface to which the source is attached, it will be sent through
the interface to which the listener sent the MLD Report. However, if
the source and the listener move to different MARs, the traffic will
traverse the following non-optimal path, even though they share a
common MAR2:
Source -> MAR1 -> MAR2 -> Multicast Tree -> MAR2 -> MAR3
This problem is depicted in Figure 7.
+----------------+
| Multicast Tree |
+----------------+
* *
* *
* *
* *
* *
+----------+ (-->) +----------+ (-->) +----------+
| MAR1 |---------| MAR2 |---------| MAR3 |
| |*********| |*********| |
| (MLD-P) |---------| (MLD-P) |---------| (MLD-P) |
+----------+ Tun.1 +----------+ Tun.2 +----------+
* * * *
* * * *
* * * *
+---+ move +---+ +---+ move +---+
| S | <--- | S | | L | --> | L |
+---+ +---+ +---+ +---+
(<--/-->) : direction of the multicast packet flow
Figure 7 Non-optimal routing due to mobile sender
3.2.2. Multicast Router in MAR
TBD
Figueiredo, et al. Expires August 12, 2012 [Page 10]
Internet-Draft Use Cases for Multicast DMM March 2012
4. IANA Considerations
This document makes no request of IANA.
5. Security Considerations
TBD
6. References
6.1. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC6275] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
[RFC3810] R. Vida, and L. Costa, "Multicast Listener Discovery
Version 2 (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.
[RFC4601] B. Fenner, M. Handley, H. Holbrook, and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
6.2. Informative References
[RFC5757] T. Schmidt, M. Waehlisch, G. Fairhurst, Multicast Mobility
in Mobile IP Version 6 (MIPv6): Problem Statement and Brief
Survey, RFC 5757, February 2010.
Figueiredo, et al. Expires August 12, 2012 [Page 11]
Internet-Draft Use Cases for Multicast DMM March 2012
[RFC6224] T. Schmidt, M. Waehlisch, S. Krishnan, "Base Deployment
for Multicast Listener Support in PMIPv6 Domain,", RFC
6224, April 2011.
[DDMM-FP] P. Bertin, S. Bonjour, and J.-M., Bonnin, "A Distributed
Dynamic Mobility Management Scheme Designed for Flat IP
Architectures," Proc. of NTMS 2008. , November 2008.
[DDMM-MI] H. A. Chan, H. Yokota, J. Xie, P. Seite, D. Liu,
"Distributed and Dynamic Mobility Management in Mobile
Internet: Current Approaches and Issues", Journal of
Communications, vol. 6, no. 1, pp. 4-15, February 2011.
[IPMM] I. Romdhani, M. Kellil, and H. Lach, "IP Mobile Multicast :
Challenges and Solutions," IEEE Communications Surveys &
Tutorials, vol. 6, no. 1, pp. 18-41, 2004.
[PM-HOME] S. Jeon, N. Kang, and Y. Kim, "Mobility Management based on
Proxy Mobile IPv6 for Multicasting Services in Home
Networks," IEEE Transactions on Consumer Electronics (TCE),
vol. 55, no. 3, pp. 1227-1232, August 2009.
Figueiredo, et al. Expires August 12, 2012 [Page 12]
Internet-Draft Use Cases for Multicast DMM March 2012
Authors' Addresses
Sergio Figueiredo
Universidade de Aveiro
3810-193 Aveiro, Portugal
E-mail: sfigueiredo@av.it.pt
Seil Jeon
Instituto de Telecomunicacoes
Campus Universitario de Santiago
3810-193 Aveiro, Portugal
E-mail: seiljeon@av.it.pt
Rui L. Aguiar
Universidade de Aveiro
3810-193 Aveiro, Portugal
E-mail: ruilaa@ua.pt
Figueiredo, et al. Expires August 12, 2012 [Page 13]