MULTIMOB Working Group Luis M. Contreras
Internet Draft Carlos J. Bernardos
Intended status: Experimental Ignacio Soto
Expires: April 16, 2010 UC3M
October 15, 2009
Multicast service delivery in PMIPv6 domains
draft-contreras-multimob-msd-00.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 April 16, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Contreras, et al. Expires April 15, 2010 [Page 1]
Internet-Draft Multicast in PMIPv6 domains October 2009
Abstract
A new working group, Multimob, has been chartered for providing an
implementation of multicast service distribution to multicast
listeners as they move in currently defined Proxy Mobile IPv6
(PMIPv6) domains according to RFC 5213 [1]. No protocol modifications
or extensions are considered at this stage.
Several proposals [2, 3, 4] have been already presented to face this
issue. This contribution sums up some of the previous ideas extending
them when necessary to overcome some limitations existing on such
solutions.
Table of Contents
1. Introduction.................................................2
2. Conventions and terminology..................................3
3. Overview.....................................................3
4. Unicast and multicast service delivery integration...........4
5. Local Mobility Anchor (LMA) operation........................5
6. Mobile Access Gateway (MAG) operation........................5
6.1. MAG operation as MLD proxy..............................5
6.2. MAG operation as multicast router.......................5
7. Multicast traffic hand-off process...........................6
7.1. Newly-attached MN interrogation.........................6
7.2. Multicast context transfer among MAGs...................7
7.3. pMAG-assisted handover..................................8
7.3.1. Multicast flow encapsulation......................11
7.3.2. Multicast flow delivery to the MN from the nMAG...12
8. Security Considerations.....................................12
9. IANA Considerations.........................................12
10. References.................................................12
10.1. Normative References..................................12
10.2. Informative References................................13
11. Acknowledgments............................................13
1. Introduction
A new working group, Multimob, has been chartered for providing an
implementation of multicast service distribution to multicast
listeners as they move in currently defined Proxy Mobile IPv6
(PMIPv6) domains according to RFC 5213 [1]. No protocol modifications
or extensions are considered at this stage.
Contreras, et al. Expires April 15, 2010 [Page 2]
Internet-Draft Multicast in PMIPv6 domains October 2009
This draft takes as starting point some existing contributions [3, 4,
5] to define a comprehensive architecture for multicast traffic
delivery in a PMIPv6 domain, introducing a new mechanism to allow
fast handover of the multicast flow, thus minimising multicast
service disruption when the multicast mobile listener moves across
the network.
2. Conventions and terminology
This document uses the terminology referring to PMIPv6 components as
defined in [1].
3. Overview
In currently defined PMIPv6 solution [1] two main entities, named
Local Mobility Anchor (LMA) and Mobile Access Gateway (MAG), are in
charge of managing both Mobile Node (MN) mobility and traffic
delivery from/to the MN.
The LMA plays a central role in the unicast traffic delivery from/to
the MN due that it is responsible of guaranteeing that the MN is
reachable through the PMIPv6 domain by means of announcing an
available route towards the MN, and forwarding traffic to it. By
contrast, it plays a passive role in the mobility process, just
pointing out to the MAG which acts as next-hop router to reach the
MN.
On the other hand, the MAG's main role is to manage the MN node
mobility within the PMIPv6 domain, notifying to the LMA the MN's
current location as it moves within the PMIPv6 domain. Respect to the
unicast traffic delivery, the MAG behaves as a passive element, just
forwarding the MN's terminating traffic on the point-to-point link
connecting both the MAG and the MN, or forwarding the traffic
originated in the MN to the LMA as default router.
The case for multicast traffic is slightly different to the unicast
one. The IP destination address of multicast packets does not
identify the receiver, so the LMA would need additional information
to be able to forward the multicast flow to the MNs requiring such
content. In order to manage multicast traffic terminated on an MN,
the LMA would need to keep the multicast status for every MN
subscribing to a content. Nevertheless, the MAG is the element placed
as first-hop router for the MNs, and thus, the MAG is the element
Contreras, et al. Expires April 15, 2010 [Page 3]
Internet-Draft Multicast in PMIPv6 domains October 2009
which directly receives the MLD signalling messages coming from the
MNs. It is the element better positioned in the network to maintain
the MN multicast status.
As consequence of that, in this draft the LMA is considered to manage
unicast traffic terminating on the MN, whereas the MAG is considered
to manage the multicast one, either if it plays the role of an MLD
proxy or a fully-enabled multicast router.
This draft takes as starting point some existing contributions [3, 4,
5] to define a comprehensive architecture for multicast traffic
delivery in a PMIPv6 domain, extending them in three ways:
1. An integrated vision of multicast service delivery together with
unicast standard process.
2. The extension of the MAG role to also consider it to be a fully
enabled multicast router.
3. A new proposal for minimising multicast service disruption on the
handover event between MAGs.
4. Unicast and multicast service delivery integration
This draft considers that every MN demanding multicast services is
previously registered in the PMIPv6 domain based on a unicast IP
address as stated in [1]. This registration can be required for
several purposes such as remote management, billing, etc.
As the registration is required by the network before any multicast
service is provided, any MLD message originated by the MN will be
discarded until the registration process is finished. This fact also
prevents the network from accepting any subscription request or leave
sent by the MN during the handover process.
In the same way, any subscription request or leave sent by the MN
after a detachment procedure is initiated, will be discarded by the
network, not being taken into account for multicast traffic
management purposes.
Contreras, et al. Expires April 15, 2010 [Page 4]
Internet-Draft Multicast in PMIPv6 domains October 2009
5. Local Mobility Anchor (LMA) operation
As stated above, the LMA will not play any specific role in the
multicast traffic management.
6. Mobile Access Gateway (MAG) operation
As stated above, the MAG will play a central role in the multicast
traffic management. The MAG will keep the multicast status of every
MN connected to it, and it will handle the multicast traffic
accordingly to the MLD messages received on each point-to-point link.
Depending on the functionality deployed on the MAG, it is possible to
consider the MAG as an MLD proxy or as a multicast router.
6.1. MAG operation as MLD proxy
When the MAG operates as MLD proxy it is in charge of summarizing the
MN's subscription requests and delivering them towards the multicast
router that can be reached through the configured proxy's upstream
interface.
Conceptually, this scenario corresponds to the one described in
Figure 1 of [5].
In this draft, just one MLD proxy instance is considered to be
running in the MAG, and as consequence, just one interface can be
defined as upstream interface.
The multicast router connected to the MLD proxy upstream interface
could be any router in the network, even one of the routers acting as
LMA. In such case, the upstream interface could be defined over the
tunnel between the MAG and the LMA, once that tunnel has been set up.
6.2. MAG operation as multicast router
When a MAG operates as multicast router, it will send PIM messages to
build the multicast tree that distributes the content required by a
certain MN, if such content is not being received yet on the MAG.
Contreras, et al. Expires April 15, 2010 [Page 5]
Internet-Draft Multicast in PMIPv6 domains October 2009
Some content (the most popular one according to audience metrics or
estimations) could be permanently subscribed at MAG to minimize the
signalling involved in the establishment and pruning processes of the
multicast tree leafs reaching the MAG.
One of the routers participanting in the multicast distribution tree
can be one of the routers that acts as LMA in the PMIPv6 domain. In
that case, the multicast distribution tree could be extended over the
tunnel between MAG and LMA, once that tunnel has been set up.
7. Multicast traffic hand-off process
As the MN moves and connects to different access networks with the
same or different wireless access technology, the network should be
able to guarantee the delivery of the traffic following the MN
movement.
In the case of the multicast traffic, as seen above, the MAG entities
have the knowledge about the multicast status (group subscription) of
the MNs attached to them. MAG nodes contain enough information to
support the handover process minimising multicast service disruption.
We describe below some alternatives [4, 5] to facilitate multicast
service handover, including a new proposal.
7.1. Newly-attached MN interrogation
This method, proposed in [4], is based on the fact that MAG entities
running an MLD instance have the capability of interrogating mobile
hosts to obtain multicast memberships. In this case, an MN entering a
new access network under responsibility of a new MAG will be
interrogated by the new MAG, which sends an MLD Query towards the MN.
Once the MLD Query is received, the MN will provide information about
active memberships it has, if any. The MAG will get in this way
knowledge of the multicast status for this newly-attached MN.
A number of pros and cons can be identified for this method.
Pros:
o The MAG entity does not require any additional functionality as it
already implements MLD capabilities.
Contreras, et al. Expires April 15, 2010 [Page 6]
Internet-Draft Multicast in PMIPv6 domains October 2009
o The application of this method can be easily integrated within the
MN registration process.
Cons:
o Any new MN attaching the nMAG is interrogated, independently if it
maintains or not an active multicast session at that time.
o The signalling process wastes resources over the air interface.
7.2. Multicast context transfer among MAGs
This method, introduced in [5], proposes to trigger a context
transfer process of the MN multicast status from the previous MAG
(pMAG) to the new MAG (nMAG). As a previous step, the pMAG should
predict the path the MN follows as it moves, to correctly identify
the candidate nMAG to support the MN connection.
A number of pros and cons can be identified for this method.
Pros:
o There is no additional signalling process over the air interface.
o The context transfer method is an standardized process as per [2].
Cons:
o The MAG entity requires new functionality to support multicast
traffic handovers.
o As predictive method, there is no total guarantee of success (the
multicast context could not reach nMAG in all cases).
o Coordination problems could arise in case of vertical handovers.
Contreras, et al. Expires April 15, 2010 [Page 7]
Internet-Draft Multicast in PMIPv6 domains October 2009
7.3. pMAG-assisted handover
This new proposal considers the fact that the MN keeps the same IP
address in the PMIPv6 domain, thus the MN will be always reachable
and traceable from the LMA as it moves from one wireless point of
attachment to another.
The pMAG maintains the multicast status of an MN reconnecting to a
nMAG. Before the detachment process, the multicast traffic reaching
the MN passes through the pMAG. So, once a pMAG receives a Proxy
Binding Ack (PBA) message from the LMA confirming that the MN has
been detached from its point-to-point link, the pMAG can be able to
temporally forward via the LMA a copy of the multicast content within
an unicast flow towards the new location of the MN, once it is
registered again in some point of the network. In case the MN is not
registered again, the copy will be silently discarded in the LMA
until timer expiration.
The timer duration has to be long enough to cover the registration
process and the content subscription at the nMAG (triggered by
periodic MLD reports from the MN). Once the timer expires, the pMAG
deletes the MN multicast status state and stops the unicast flow that
encapsulates the multicast content.
Figure 1 presents the interaction between pMAG, LMA and nMAG.
Contreras, et al. Expires April 15, 2010 [Page 8]
Internet-Draft Multicast in PMIPv6 domains October 2009
MN pMAG nMAG MR LMA
| | | | |
1) |<--------------- Multicast Data ---| |
| | | | |
MN detaches | | | |
| MN detachment event | | |
| | | | |
2) | |---- Proxy Binding Update -------->|
| | | | |
3) | |<--- Proxy Binding Acknowledge ----|
| | | | |
4) | |-- Mcast flow encapsulation ------>|
| | | | |
5) | | |-Proxy Binding Update->|
| | | | |
6) | | |<--Proxy Binding Ack.--|
| | | | |
7) | | |<- Mcast flow fwd -----|
| | | | |
8) |<--- Multicast Data ---| |
| | | |
| | |-MLDReport>|
| | | |
| | | |->(PIM join)
| | | |
| | | |->(S,G)
| | | |
9) |<--------------- Multicast Data ---|
| | | |
| | | |
Figure 1. pMAG-assisted handover
Each step of the process is described as follows:
1) A registered MN is receiving a multicast content which has been
previously subscribed by standard MLD request from the MN to the
currently serving MAG, pMAG. The pMAG keeps the multicast status
state of the MN.
2) The MN perceives a better radio link and decides to initiate a
handover process over a radio access controlled by a new MAG,
nMAG. As consequence, pMAG determines a detach event corresponding
Contreras, et al. Expires April 15, 2010 [Page 9]
Internet-Draft Multicast in PMIPv6 domains October 2009
to this MN, and updates the attachment status of this MN to the
LMA by sending a Proxy Binding Update message. From this moment,
pMAG would discard any new MLD Report message coming from the MN
requesting new content subscription.
3) The LMA confirms the reception of the detach process notification
by sending a Proxy Binding Acknowledge message to the pMAG.
4) After reception of the PBA message, the pMAG encapsulates the
multicast flow being served to the MN prior to the detachment
event, and temporally forwards it to the LMA. The reason for this
is that the MN keeps its IP address through the PMIPv6 domain, and
it will be always reachable through the LMA, as soon as the MN is
registered again by the nMAG. During the time that the MN is not
reachable by the LMA, the LMA will silently discard the
encapsulated multicast flow sent by the pMAG.
The encapsulation method is described later in this draft.
A timer is set up by pMAG to control the duration of multicast
flow forwarding via the LMA. The timer value must be at least the
maximum time to cover the MN registration process at the MAG and
the refreshment of the group membership by the MLD instance at the
MN.
5) The MN triggers an attachment process in a different MAG, nMAG.
This nMAG signals the LMA with the new mobility status of the MN.
6) The LMA confirms the new attachment, and configures the routing
table accordingly to forward incoming traffic to the MN through
the nMAG. At this time, any MLD messages coming from the MN are
accepted by the nMAG.
7) Once the MN is reachable again, the LMA forwards the encapsulated
multicast traffic originally subscribed by the MN to the nMAG.
8) The nMAG decapsulates the originally subscribed multicast flow and
sends it over the point-to-point link connecting both the nMAG and
the MN. With the information contained in the flow, the nMAG is
able to build the multicast status of the MN. Additionally, in
case the nMAG currently does not have a subscription to the
required content, it can trigger a content subscription on behalf
of the MN to set up the delivery tree to the nMAG.
If the MN sends MLD messages to leave originally subscribed
multicast content, the encapsulated multicast flow coming from the
pMAG wil be silently discarded until timer expiration.
Contreras, et al. Expires April 15, 2010 [Page 10]
Internet-Draft Multicast in PMIPv6 domains October 2009
9) The delivery tree reaches nMAG. The multicast content is directly
served by the multicast tree. The encapsulated multicast flow
coming from the pMAG will be silently discarded until timer
expiration.
A number of pros and cons can be identified for this method.
Pros:
o There is no additional signalling process over the air interface.
o The multicast traffic is sent towards the MN immediately after the
new registration.
Cons:
o The MAG entity require new functionality to support multicast
traffic handovers.
o The network temporally supports more traffic.
7.3.1. Multicast flow encapsulation
The originally subscribed multicast traffic has to be encapsulated
from the pMAG to the LMA to forward it to the MN as it moves. The
format of the tunnelled flow considered in this draft is the one
already described in Figure 1 of reference [3], but with different
addressing considerations. Briefly, the format proposed here is as
follows:
1. One external tunnel, with source address pMAG's Proxy-CoA, and
destination address LMA Address (LMAA).
2. One internal tunnel, with source address pMAG's Proxy-CoA, and
destination address MN-HoA.
3. The multicast flow being received by the MN, with source address
the IP address of the source injecting the multicast content to
the network, and destination address the multicast IP address of
the group subscribed by the MN.
Once these packets reach the LMA, if a routing entry already exists
pointing out to the MN through the nMAG, the external tunnel
addressing is modified accordingly: the source address is the LMAA,
whereas the destination address is the nMAG's Proxy-CoA.
Contreras, et al. Expires April 15, 2010 [Page 11]
Internet-Draft Multicast in PMIPv6 domains October 2009
7.3.2. Multicast flow delivery to the MN from the nMAG
Here the same behaviour described in section 5 of reference [3] is
proposed for the nMAG.
After receiving the forwarded original multicast flow from pMAG, the
nMAG will analyze the internal tunnel header. In case the source
address is a Proxy-CoA address of any neighbouring MAG in the domain,
and the destination address is the one of the MN, MN-HoA, the nMAG
will determine that a second tunnel exists. The nMAG will remove the
internal header and will deliver the original multicast content as is
(with multicast source and group addresses) to the MN on the point-
to-point link.
In this way, the MN is guaranteed to receive the original subscribed
multicast flow as before the handover process.
This mechanism implies that any MAG within a PMIPv6 domain has to be
aware of the Proxy-CoA addresses of the neighbouring MAGs in the
domain, to be able to determine the existence of the second
(internal) tunnel. The maximum number of IP addresses to take into
account would be then equal to the number of MAGs in the domain.
8. Security Considerations
None.
9. IANA Considerations
This document makes no request of IANA.
10. References
10.1. Normative References
[1] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, and B.
Patil, "Proxy Mobile IPv6", RFC 5213, Augurst 2008.
Contreras, et al. Expires April 15, 2010 [Page 12]
Internet-Draft Multicast in PMIPv6 domains October 2009
[2] J. Loughney, M. Nakhjiri, C. Perkins, and R. Koodli, "Context
Transfer Protocol (CXTP)", RFC 4067, July 2005.
10.2. Informative References
[3] S. Krishnan, B. Sarikaya and TC. Schmidt, "Proxy Mobile IPv6
Basic Multicast Support Solution", draft-krishnan-multimob-
pmip6basicmcast-solution-00, (work in progress), July 2009.
[4] TC. Schmidt, M. Waehlisch, B. Sarikaya, and S. Krishnan, "A
Minimal Deployment Option for Multicast Listeners in PMIPv6
Domains", draft-schmidt-multimob-pmipv6-mcast-deployment-01,
(work in progress), June 2009.
[5] S. Jeon, Y. Kim, and J. Lee, "Mobile Multicasting Support in
Proxy Mobile IPv6", draft-sijeon-multimob-mms-pmip6-00, (work
in progress), July 2009.
11. Acknowledgments
The research of Carlos J. Bernardos leading to these results has
received funding from the European Community's Seventh Framework
Programme (FP7/2007-2013) under grant agreement n. 214994 (CARMEN
project), and from the Ministry of Science and Innovation of Spain,
under the QUARTET project (TIN2009-13992-C02-01).
Authors' Addresses
Luis M. Contreras
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Email: luisc@it.uc3m.es
Contreras, et al. Expires April 15, 2010 [Page 13]
Internet-Draft Multicast in PMIPv6 domains October 2009
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Email: cjbc@it.uc3m.es
Ignacio Soto
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Email: isoto@it.uc3m.es
Contreras, et al. Expires April 15, 2010 [Page 14]