Internet DRAFT - draft-kellil-multimob-partial-mcast
draft-kellil-multimob-partial-mcast
MULTIMOB Group M. Kellil
Internet Draft M. Boc
Intended status: Informational C. Janneteau
Expires: May 16, 2013 CEA LIST
November 16, 2012
Group Communications in a PMIPv6 Domain with Partial Deployment of
Multicast
<draft-kellil-multimob-partial-mcast-00.txt>
Status of this Memo
This Internet-Draft is submitted 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 April 16, 2013.
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.
Kellil et al. Expires May 16, 2013 [Page 1]
Internet-Draft Group Communications in PMIPv6 November 2012
Abstract
Various approaches have been proposed to support multicast in PMIPv6
domains. However, the problem of partial deployment of multicast in
the PMIPv6 domain has not been considered. In particular, the
proposed approaches typically assume that all the MAGs of the PMIPv6
domain are multicast-capable. The present work aims at carrying out
the case where some of the PMIPv6 domain's MAGs are not necessarily
multicast-capable.
Table of Contents
1. Introduction ................................................ 3
2. Proposed Solution ........................................... 3
2.1. Assumptions ............................................ 3
2.2. Node Subscription ...................................... 5
2.2.1. Option 1 - Non multicast-capable MAG .............. 5
2.2.2. Option 2 - Configurable MAG ....................... 7
2.2.3. Option 3 - Multicast-capable MAG .................. 8
2.3. Data Forwarding ........................................ 8
2.3.1. Option 1 - Non multicast-capable MAG .............. 9
2.3.2. Option 2 - Configurable MAG ....................... 9
2.3.3. Option 3 - Multicast Capable MAG .................. 9
2.4. Node Handover .......................................... 9
2.5. Node Unsubscription .................................... 9
2.5.1. Option 1 - Non multicast-capable MAG ............. 10
2.5.2. Option 2 - Configurable MAG ...................... 10
2.5.3. Option 3 - Multicast-Capable MAG ................. 10
3. Security Considerations .................................... 10
4. IANA Considerations ........................................ 10
5. References ................................................. 10
5.1. Normative References................................... 10
5.2. Informative References ................................ 11
6. Acknowledgments ............................................ 11
Kellil et al. Expires May 16, 2013 [Page 2]
Internet-Draft Group Communications in PMIPv6 November 2012
1. Introduction
The present work seeks into addressing the case of partial
deployment of multicast in PMIPv6 domains while enabling end-to-end
group communications.
The proposed approach may be useful for network operators that may
be reluctant in deploying multicast in the whole PMIPv6 domain for
different reasons like deployment cost, security policy/access
control constraints, service provisioning constraints, QoS, etc. For
such operators, the present approach may represent a good short/mid-
term multicast deployment strategy in PMIPv6 (for an experimental
purpose, for instance).
Various approaches have been proposed to support multicast in PMIPv6
domains. They all assume that multicast is supported in the whole
PMIPv6 domain. For instance, the document [RFC 6224] describes some
techniques for deploying multicast listener functions in Proxy
Mobile IPv6 domains without modifying mobility and multicast
protocol standards. In the proposed solution, the LMA implements the
function of the designated multicast router, MLD querier, and
optionally an MLD proxy. According to MLD reports received from a
MAG (on behalf of the MNs), the LMA manages multicast forwarding
states at its corresponding downstream tunnel interfaces. Also, the
MAG performs MLD proxy functions. A MAG that does not support
multicast operations will discard MN's subscription message. This
solution does not address the case of a partial deployment of
multicast in the PMIPv6 domain (e.g., scenarios where some MAGs of
the PMIPv6 domain do not support multicast operations). Also, other
approaches like [Saada2012] [Hui2012] seek into optimizing mobility
of multicast receivers in terms of handover latency and tunneling
overhead at the MAG, yet such approaches do not solve the problem of
partial deployment of multicast in the PMIPv6 domain.
2. Proposed Solution
2.1. Assumptions
The solution leverages SIP protocol [RFC 3261] to enable the LMA
storing information about active multicast groups. Therefore, it is
assumed that a SIP framework is deployed over the PMIPv6 domain. In
this framework the LMA plays the role of a SIP proxy. This proxy is
of a stateful type so as it can maintain states of active multicast
groups and associated MNs. Also, the SIP server is present in the
SIP framework, yet the SIP server will not be discussed in this
document because it is not directly involved in the functional
Kellil et al. Expires May 16, 2013 [Page 3]
Internet-Draft Group Communications in PMIPv6 November 2012
scheme of the present approach. In addition, the MN is assumed to
perform standard PMIPv6 operations for network attachment and
handover [RFC 5213].
Also, the MN is assumed to be a multicast-capable node (multicast
receiver) as well as a SIP client. However, the MN is not aware of
any possible multicast capability on the MAG. This avoids the
modification of Neighbor Discovery protocol [RFC 4861].
Also, the LMA is assumed to be a multicast anchor point in that it
implements the operations defined in RFC 6224 (MLD Querier, optional
MLD proxy, and multicast router). The LMA also manages a multicast
subscription list (MSL) that has the following structure:
<mcast @>, <MN-ID>, <MN @>, <MAG @>, <MAG cap>
There may be multiple MAGs in the PMIPv6 domain. Some of these MAGs
are multicast-capable whereas others are standard PMIPv6 MAGs. Also,
some of these standard PMIPv6 MAGs may be configured with a mapping
that associates a UDP port number to one or more multicast
addresses. In view of that, three types of MAG are to be considered:
non multicast capable MAG, configurable MAG, and multicast-capable
MAG.
o Non multicast capable MAG (NM): in this option the MAG supports
conventional PMIPv6 operations only, as per RFC 5213.
o Configurable MAG (CM): a MAG that supports conventional PMIPv6
operations and stores a structure that maps an input UDP port
number to a multicast address. In addition, it is capable of
forwarding multicast packets to the MNs attached to its network.
The MAG's input UDP port number is known in advance by both the
MAG and LMA.
o Multicast capable MAG (MM): a MAG that supports multicast
operations as indicated in RFC 6224.
Also, in this solution it is assumed that the LMA knows the
capability of each MAG in terms of multicast support. Also, it is
assumed that each time the LMA receives a PBU message from a MAG, it
internally checks for MAG's capability.
To store the information on the MAG capability in terms of multicast
support, the standard PMIPv6 binding cache structure may need to be
modified so as each MAG address will be associated (e.g., will be
pointing) to a MAG capability value NM, CM, or MM.
Kellil et al. Expires May 16, 2013 [Page 4]
Internet-Draft Group Communications in PMIPv6 November 2012
2.2. Node Subscription
First, the MN attaches to the PMIPv6 network using the standard
procedure defined in RFC 5213 (cf. figure 1). Once the MN has
configured its IP address, it initiates the group subscription
procedure, by sending a SIP invite message to the LMA, which acts as
a SIP proxy. The SIP invite message includes the multicast address of
the desired group as well as the MN-ID.
When the LMA receives the SIP invite message from MN, it stores the
MN-ID and multicast address in its multicast subscription list (MSL).
It is worth mentioning that since the LMA holds the couple "<MN-ID>,
<MAG @>" in its binding cache as well, the present solution proposes
that each time the LMA notices that a new MN has registered through a
standard PMIPv6 procedure, it checks whether this MN is registered in
the MSL list. If so, the LMA then checks if the said MSL entry
includes the MN's MAG address. If the MAG address does not exist,
the LMA will add it in the MSL entry. If MN's MAG address is already
in the MSL list, no further operation is needed in the MSL entry.
In addition to its registration with the LMA, the MN sends an
(unsolicited) MLD Report message on its link, without caring, though,
whether the MAG is multicast-capable or not. These options are
discussed in what follows.
2.2.1. Option 1 - Non multicast-capable MAG
When the LMA receives a PBU message from a MAG and notices that the
said MAG is not multicast-capable, it checks whether the MN-ID
included in the PBU message is registered in one of the entries of
its multicast subscription list (MSL). If so, the LMA updates the
associated MSL entry with the MAG's IP address, and attaches to the
multicast tree on behalf of the MN (cf. figure 2). In addition, the
LMA establishes a double IP tunneling towards the MN (besides the
LMA's standard PMIPv6 tunnel). The inner tunnel will end at the MN's
IP address, and the outer tunnel will end at MAG's IP address. Of
course, this double IP tunneling is transparent to the MAG, since the
inner header includes MN's IP address, while the outer tunnel
(obviously) terminates at the MAG's PMIPv6 tunnel interface.
If the MN-ID is not in the MSL list, no multicast-specific operation
is needed on the LMA. On the other hand, when the MAG receives MN's
Report, it will ignore it.
Kellil et al. Expires May 16, 2013 [Page 5]
Internet-Draft Group Communications in PMIPv6 November 2012
+-----+ +-----+ +-----+
| MN | | MAG | | LMA |
+-----+ +-----+ +-----+
| | |
MN Attached | |
| | |
| MN Attached Event from MN/Network |
| (Acquire MN-Id and Profile) |
| | |
|--- Rtr Sol --------->| |
| | |
| |--- PBU ------------->|
| | |
| | Accept PBU
| | (Allocate MN-HNP(s), Setup BCE and
| | Tunnel)
| | |
| |<------------- PBA ---|
| | |
| Accept PBA |
| (Set Up Tunnel and Routing) |
| | |
| | MN-Id is in MSL
| | &
| | MAG not
| | mcast-capable is TRUE
| | &
| | update MSL entry with
| | MAG' IP address
| | &
| | attach mcast tree
| | --------------------- |
|======================|====== Double Tunnel===|
| | --------------------- |
| | |
|<--------- Rtr Adv ---| |
| | |
IP Address | |
Configuration | |
| | |
| Join (G) | |
| -------------------->| |
| ignore |
| | |
Figure 1 PMIPv6-based MN's Group Join Procedure - Case of Non-
Multicast Capable MAG
Kellil et al. Expires May 16, 2013 [Page 6]
Internet-Draft Group Communications in PMIPv6 November 2012
2.2.2. Option 2 - Configurable MAG
When the LMA receives a PBU message from a MAG and notices that the
said MAG is a configurable MAG, it checks whether the MN-ID included
in the PBU message is registered in one of the entries of its
multicast subscription list (MSL). If so, the LMA updates the
associated MSL entry with the MAG's IP address, and attaches to the
multicast tree on behalf of the MN (cf. figure 3). In addition, the
LMA establishes a unicast tunnel towards the MAG (besides the
standard PMIPv6 tunnel) and sets a dedicated destination port number
to the said tunnel. In a preferred setting, there is a common tunnel
(and thus a common port number) between LMA and MAG for all the
multicast addresses. The use of one tunnel (and thus one port
number) between LMA and MAG per multicast address is kept optional.
If the MN-ID is not in the MSL list, no multicast-specific operation
is needed on the LMA. On the other hand, when the MAG receives MN's
MLD Report, it will ignore it.
+-----+ +-----+ +-----+
| MN | | MAG | | LMA |
+-----+ +-----+ +-----+
| | |
MN Attached | |
| | |
| MN Attached Event from MN/Network |
| (Acquire MN-Id and Profile) |
| | |
|--- Rtr Sol --------->| |
| | |
| |--- PBU ------------->|
| | |
| | Accept PBU
| | (Allocate MN-HNP(s), Setup BCE and
| | Tunnel)
| | |
| |<------------- PBA ---|
| | |
| Accept PBA |
| (Set Up Tunnel and Routing) |
| | |
| |== Bi-Dir Tunnel(1)===|
|<--------- Rtr Adv ---| |
| | |
IP Address | |
Configuration | |
| | MN-Id is in MSL
| | &
Kellil et al. Expires May 16, 2013 [Page 7]
Internet-Draft Group Communications in PMIPv6 November 2012
| | Configurable MAG
| | is TRUE
| | &
| | update MSL entry with
| | MAG' IP addres
| | &
| | attach mcast tree
| | |
| | |
| |== Bi-Dir Tunnel(2)===|
| | dst_port_nb= port_x
| | for Bi-Dir Tunnel(2)
| | |
| | |
| Join (G) | |
| -------------------->| |
| ignore |
| | |
Figure 2 PMIPv6-based MN's Group Join Procedure - Case of
Configurable MAG
2.2.3. Option 3 - Multicast-capable MAG
When the LMA receives a PBU message from a MAG and notices that the
said MAG is multicast-capable, it checks whether the MN-ID included
in the PBU message is registered in one of the entries of its
multicast subscription list (MSL). If so, the LMA updates the
associated MSL entry with the MAG' IP address, and carries on the
rest of the MN registration operation according to RFC 6224 (i.e.,
receive and process aggregated MLD Reports (or Aggregated Join
message) from the MAG, attach to the multicast tree on behalf of the
MN, establish appropriate tunnel with the MAG).
If the MN-ID is not in the MSL list, no multicast-specific operation
is needed on the LMA. On the other hand, when the MAG receives MN's
MLD Report, it will process it according to RFC 6224 specification
(MLD Reports aggregation and forwarding to LMA).
2.3. Data Forwarding
When the LMA receives a multicast packet, it checks its MSL list for
the entries that match the packet's multicast address. For each
matching entry, the LMA checks whether the associated MAG is
multicast-capable or not.
Kellil et al. Expires May 16, 2013 [Page 8]
Internet-Draft Group Communications in PMIPv6 November 2012
2.3.1. Option 1 - Non multicast-capable MAG
If the MAG is not multicast-capable, the LMA will utilize a double-
tunneling to send the multicast packet towards the MN. The outer IP
header of the tunnel includes MAG's address as a destination. The
inner IP header of the tunnel includes MN's IP address so as
multicast packet forwarding from LMA to MN via the MAG will be
transparent to the said MAG.
When the MAG receives the multicast packet from the LMA via its
PMIPv6 tunnel interface, it removes the outer header and forwards the
resulting packet to the MN (as per RFC 5213).
2.3.2. Option 2 - Configurable MAG
If the MAG is configurable, the LMA will tunnel the multicast packet
towards the MAG using the dedicated UDP port number.
When the MAG receives the multicast packet from the LMA via a
dedicated input UDP port, it removes the outer header and forwards
the resulting (multicast) packet on its downstream interface.
2.3.3. Option 3 - Multicast Capable MAG
Data forwarding procedure in option 3 is similar to that of RFC
6224.
2.4. Node Handover
MN handover to a new network associated to a new MAG: nMAG is quite
similar to that of the MN subscription phase (option 1, option 2 &
option 3), excluding the SIP procedure, which of course is not
needed for the handover phase. In addition, the LMA in the MN
handover phase has to update the associated MSL entry with the nMAG'
IP address (this update is done when the LMA checks the PBU's MN-ID
in the MSL list). Furthermore, in the handover phase there may be no
need to (re)build the multicast path (from the multicast tree)
towards the LMA (since the said path is (normally) already built).
2.5. Node Unsubscription
When an MN wishes to leave a multicast group, it notifies the LMA
via SIP Bye message and sends an MLD Exclude/Done on its link. The
SIP message contains the multicast address of the group to be left
by MN as well as the MN-ID.
Kellil et al. Expires May 16, 2013 [Page 9]
Internet-Draft Group Communications in PMIPv6 November 2012
When the LMA receives the SIP Bye message, it checks MN's ID and the
multicast address against the MSL entries. If an entry is found, the
LMA removes it and updates the multicast routing state accordingly
(ex. the LMA removes the multicast forwarding state for the said
multicast address if no more MNs are associated to this multicast
address).
On the MAG's side, however, three options are to be distinguished.
2.5.1. Option 1 - Non multicast-capable MAG
When a non-multicast capable MAG receives an MLD Exclude/Done
message, it ignores it.
2.5.2. Option 2 - Configurable MAG
When a configurable MAG receives an MLD Exclude/Done message, it
ignores it.
2.5.3. Option 3 - Multicast-Capable MAG
When a multicast-capable MAG receives an MLD Exclude/Done message,
the rest of the procedure follows RFC 6224's operations (if
necessary, update of the MAG's membership database and transmission
of MLD Exclude/Done via the MAG-to-LMA interface towards the LMA,
which then terminates multicast forwarding).
3. Security Considerations
The security considerations are the same as that covered by [RFC
6224] and [RFC 3261].
4. IANA Considerations
If this solution is to be pursued, IANA would be kindly requested to
reserve a default port to be used in the case of configurable MAG.
5. References
5.1. Normative References
[RFC 5213] Gundavelli, S. et al., "Proxy Mobile IPv6", RFC 5213,
August 2008.
Kellil et al. Expires May 16, 2013 [Page 10]
Internet-Draft Group Communications in PMIPv6 November 2012
[RFC 3810] Vida, R. et al., "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004.
[RFC 6224] Schmidt, T. et al., "Base Deployment for Multicast
Listener Support", RFC 6224, April 2011.
[RFC 3261] Rosenberg, J. et al., " SIP: Session Initiation
Protocol", RFC 3261, June 2002.
5.2. Informative References
[Saada2012] Asaeda, H. et al., "Multicast Routing Optimization by
PIM-SM with PMIPv6", Internet Draft, March 2012, (Work
in Progress).
[Hui2012] Hui, M. et al, "Fast Handover for Multicast in Proxy
Mobile IPv6", Internet Draft, March 2012, (Work in
Progress).
[RFC 4861] Narten, T. et al. "Neighbor Discovery for IP version 6
(IPv6)", RFC 4861, September 2007.
6. Acknowledgments
The work presented in this document has been supported by the
European Celtic project MEVICO which aims researching the network
aspects of the 3GPP LTE-mobile broadband network for its evolution
in the mid-term in 2011-2014.
Kellil et al. Expires May 16, 2013 [Page 11]
Internet-Draft Group Communications in PMIPv6 November 2012
Authors' Addresses
Mounir Kellil
CEA, DRT, LIST, Communicating Systems Laboratory,
Point Courrier 173, Gif-sur-Yvette, F-91191 France
Email : mounir.kellil@cea.fr
Mathias Boc
CEA, DRT, LIST, Communicating Systems Laboratory,
Point Courrier 173, Gif-sur-Yvette, F-91191 France
Email: mathias.boc@cea.fr
Christophe Janneteau
CEA, DRT, LIST, Communicating Systems Laboratory,
Point Courrier 173, Gif-sur-Yvette, F-91191 France
Email: christophe.janneteau@cea.fr
Kellil et al. Expires May 16, 2013 [Page 12]
