One document matched: draft-liu-multimob-multicast-receiver-mobility-00.txt
Multimob working group Hui Liu
Internet Draft Huawei Technologies Co.,Ltd.
Category: Informational
Created: June 14, 2009
Expires: December 2009
Multicast Receiver Mobility (MultiReM) Architecture
draft-liu-multimob-multicast-receiver-mobility-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 August 15, 2009.
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.
Liu. Expires December 14, 2009 [Page 1]
Internet-Draft Multicast Receiver Mobility June 2009
Abstract
This document proposes the architecture and solution options for
multicast receiver mobility. The discussions are restricted only to
the receiver mobility with the assumption that the multicast source
and network are stationary while the receiver is in the moving state.
The suggestions are given on how to integrate mobile IP and fixed
multicast protocols to provide the feasible solutions, which
involves the aspects of mobile receiver registration, group
membership management, tunnel or optimal multicast routing, and
handover optimization.
Conventions used in this document
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].
Table of Contents
1. Introduction.................................................2
2. Overview of Mobile Receiver Multicast........................3
3. Architecture Aspects of Mobile Receiver Multicast............5
3.1. Network Entities........................................5
3.2. Address Configuration and Registration Process..........6
3.3. Tunnel Mechanism Considerations.........................7
3.4. Group Membership Management.............................7
3.5. Multicast Tree Construction and Data Forwarding.........8
3.6. Handover Considerations................................10
3.7. Authentication and Accounting..........................15
4. Considerations for Different MIP Protocols..................15
4.1. MIPv4..................................................15
4.2. MIPv6 and DSMIPv6......................................17
4.3. PMIPv6.................................................18
5. Security Considerations.....................................19
6. Acknowledgments.............................................19
7. References..................................................19
7.1. Normative References...................................19
7.2. Informative References.................................20
Authors' Addresses.............................................21
1. Introduction
This document intends to provide the architecture which allows a
node to receive multicast service via multicast when it is in the
Liu. Expires December 14, 2009 [Page 2]
Internet-Draft Multicast Receiver Mobility June 2009
moving state. Only receiver mobility scenario is considered, with
the intended service model of mobile IPTV applications. The
multicast source mobility and network mobility are not within the
scope of this document.
The proposed scheme aims to be compatible with existing Mobile IP
and fixed network IP multicast protocols and tries to integrate them
efficiently to get a feasible solution. Least restrictions should
be put on the underlying network, whose address family could be IPv4
or IPv6 and whose access network could be of any link types (3GPP,
WLAN or WIMAX).
The document is organized as: Section 2 gives the overview of mobile
receiver multicast. Section 3 discusses various aspects of its
architecture and solution options. Section 4 illustrates the
special considerations for different MIP protocols.
2. Overview of Mobile Receiver Multicast
IP Multicast mobility provides multicast service delivery when the
network and/or terminals are in the moving state. It enhances the
unicast mobile IP with multicast capability. If multicast service
is not subscribed, the unicast mobile IP protocols should be used
for tracking and managing of the mobile host, thus MIP protocols
(MIPv4 [1], MIPv6 [2](or DSMIP [16]) and PMIPv6 [3],and etc.) should
be used in multicast mobility architecture to establish
communication relationships among the mobile node (MN), the
correspondent node (CN), and the access nodes on the home and
foreign network.
Receiver multicast mobility has the particularities that the
receiver doesn't send packets towards its CN counterpart - the
multicast source, and the multicast source does not send packets
directly to the receiver's address but to the multicast group
address instead, thus there isn't direct communication relationship
between the receiver and the multicast source and the binding
processing between them is not required. Multicast receiver
mobility shares with the unicast application the common process for
MN and network discovery, address configuration, registration and
binding between the MN and the home network.
MIP makes use of tunnel for MN and CN to communicate through Home
Agent and of route optimization for them to communicate directly.
The tunnel mechanism has the efficiency and reliability problems and
the route optimization eliminates the drawback by introducing
additional signaling support between the CN and the MN. For mobile
Liu. Expires December 14, 2009 [Page 3]
Internet-Draft Multicast Receiver Mobility June 2009
multicast tunnel method [1][2], the home agent is responsible for
joining the multicast tree on behalf of the receiver. The receiver
sends the group membership report through the tunnel to the home
agent and the home agent tunnels the group query and the multicast
data to the receiver. It is obvious that the efficiency issue for
tunnel is even worse in multicast than in the unicast case because
multicast data is usually of high volume (such as video provision in
IPTV), which requires the optimal multicast route method (belonging
to ''remote subscription'' [17] categories) to be pursued.
The multicast route optimization should be based on the multicast
routing architecture. The route optimization of receiver mobile
multicast is described as: the receiver sends group join to the
access node on the foreign network, and the access node directly
constructs the multicast tree on the foreign network, as mentioned
in [18][19][20][21][22].
The adoption of multicast route optimization or the multicast tunnel
mechanism should be independent of the unicast communication
mechanism on the receiver, while it should depend on the capability
of and the policy configured on the receiver and the foreign access
network. If the receiver node itself doesn't want to rely on the
foreign access node for multicast traffic forwarding, or current
foreign network does not support or configured not to use optimal
multicast routing, then tunnel mechanism could be adopted.
Otherwise if the access network is configured to use multicast route
optimization, then more efficient data delivery could be implemented.
Whether the multicast tree is constructed on the foreign network or
on the home network, the multicast routing mechanism should be the
same as that of fixed network multicast. This is because they share
the common features that only the source sends data towards the
receiver and there isn't any multicast control packets exchanged
directly between the source and the receiver. Thus it is feasible
to reuse currently deployed fixed network multicast routing
protocols. The protocols could be PIM-SM [4], PIM-SSM [5], MPLS
p2mp RSVP-TE [6], MPLS p2mp LDP [23], and etc., depending upon the
provider's choices.
Handover issues must be considered carefully in mobile receiver
multicast solution, because as the receiver connects to the new
access network, the completion of configuration and establishment of
new multicast forwarding states may require long process time and
possibly interrupt the multicast data transmission. Thus the
handover procedures should be optimized or accelerated to reduce or
avoid multicast packet loss.
Liu. Expires December 14, 2009 [Page 4]
Internet-Draft Multicast Receiver Mobility June 2009
As a summary, the general architecture of multicast receiver
mobility can be described as follows: it makes use of MIP protocols
to make registration and binding of the receiver on the home network,
of IGMP/MLD protocols to join and leave a group, of multicast
routing protocols to construct multicast trees between the source
and the receiver on home or foreign network. The tunnel and routing
optimization mechanism should both be provided. Besides, special
consideration should be put on how to realize seamless multicast
reception during handover. The extensions of the above protocols
and definition of a new protocol may be made if they are necessary
to improve the performance, and attention should be taken in order
not to introduce interoperability problems.
3. Architecture Aspects of Mobile Receiver Multicast
3.1. Network Entities
Regardless of the type of multicast routing protocols adopted, the
mobile multicast network includes the following entities:
- Multicast source. It sends data to a multicast group with the
destination address of the packet set to multicast group address.
- First-hop router. It connects directly with the multicast source
network.
- Last-hop router. It connects directly with the multicast receiver
network and functions as the leaf node of the multicast tree. It
receives and processes the group membership reports from the
receiver and initiates multicast routing protocol procedures towards
the upstream router to construct the multicast tree. Sometimes the
switches and routers supporting IGMP/MLD-Proxy [7] also act as the
last hop, when the tree is set up simply by IGMP/MLD proxy messages.
- Intermediate router. It constructs the multicast tree between the
first-hop and the last-hop by multicast routing protocol (or IGMP
proxy protocol).
- Root node. It is a Rendezvous Point (RP) node in some cases [4]
and is the first-hop router in other cases [5][6][23].
For multicast receiver mobility, all the above entities are
stationary. The last hop router is the leaf-node of the multicast
tree and may or may not coexist with network-side MIP access node
(defined in different MIP protocols as different entities as shown
below) which takes the duty of mobile management such as detection
Liu. Expires December 14, 2009 [Page 5]
Internet-Draft Multicast Receiver Mobility June 2009
and configuration of the mobile receiver. For convenience of
illustration, it is assumed in the following parts that the
multicast tree last-hop and the mobile IP access node are located on
the same node.
IPTV networks usually deploy video server on the edge of the network.
The multicast tree is constructed (sometimes statically) between the
server and the program source and the program content may be pre-
pushed to the server. The receiver connects to the server and after
the subscription downloads the content from the server. In this
case the server is the last hop of the receiver.
The access node of the receiver on the home network is the home
agent in MIPv4 and (DS)MIPv6, or Local Mobility Anchor (LMA) in
PMIPv6. For (DS)MIPv6 and MIPv4 of co-located mode, there is no
definite entity defined on the foreign network engaged in the MIP
signaling processing, then the access router on the foreign network
functions as the mobile multicast access node. In other cases, the
foreign agent of MIPv4 (of foreign-agent mode) and Mobile Access
Gateway (MAG) of PMIPv6 is used. For convenience of reference, this
document generally refers to these access nodes as mobile multicast
agent. They are specifically referred to as Multicast Home Agent
(MHA) on the home network and Multicast Foreign Agent (MFA) on the
foreign network.
3.2. Address Configuration and Registration Process
The receiver mobility multicast scheme has no restrictions on the
address types adopted by the mobile receiver and the access network.
They could be IPv4-only, IPv6-only or dual stack. To use which type
of addresses depends on the policy of the provider or on the
customer's service profile.
If MIPv4 or (DS)MIPv6 is used, the mobile receiver uses home address
on home network and Care-of Address (CoA) on the foreign network.
The acquisition and configuration of the addresses and the binding
of them on the MHA should share the same procedures as those adopted
in the MIP protocols. The CoA can be generated by MFA advertisement
or by external assignment method (such as DHCP [8][9] and etc.),
with more detailed explanation in [1][2]. After obtaining the CoA,
the receiver should register on the MHA to establish binding
relationship between its CoA and home address. PMIPv6 has the
differences that the address configured on the foreign network is
home-network prefixed and registration binding operations of the
receiver take place between MFA and MHA not involving the MN.
Liu. Expires December 14, 2009 [Page 6]
Internet-Draft Multicast Receiver Mobility June 2009
MIP protocols (MIPv4, MIPv6 or DSMIPv6, PMIPv6 and etc.) can be used
to implement the registration and binding. The related registration
request and registration acknowledgment messages (Registration
Request and Registration Reply for MIPv4, Binding Update and Binding
Acknowledgement for (DS)MIPv6, and Proxy Binding Update and Proxy
Binding Acknowledgement for PMIPv6) could be transmitted via MFA or
directly between the receiver and the MHA, depending on different
MIP protocol adopted. These messages can be extended to carry the
option or flag for mobile multicast capability negotiation as they
are transmitted.
3.3. Tunnel Mechanism Considerations
In tunnel mechanism, the MHA will take the duty of group membership
management and multicast tree joining. All the traffic will be sent
or received through the tunnel to or from the MHA.
When MIPv4 is used, the endpoints of the tunnel are the MHA and the
CoA of the receiver. If the CoA is registered through the MFA, then
MFA terminates the tunnel, or if the CoA is registered directly with
the MHA (in the co-located mode), then the receiver itself
terminates the tunnel. In other cases, the tunnel endpoints are
generally the MHA and the receiver for (DS)MIPv6, and are the MHA
and MFA for PMIPv6. Thus for different MIP protocols, the endpoint
of the tunnel on the home network is the MHA, and the endpoint of
the tunnel on the foreign network can be either the MFA or the
receiver.
The tunnel could be statically created and deleted, or could be
established dynamically when needed. The encapsulation type could
be IP-in-IP, GRE and minimal encapsulation as discussed in [1][2][3].
The address type of the outer and inner IP address could be of IPv4
or IPv6 according to the address type adopted by the receiver and
the provider network.
3.4. Group Membership Management
The mobile receiver uses group management protocol IGMP (for IPv4)
[10][11] and MLD (for IPv6) [12][13] to join a multicast group,
which could be an ASM group or SSM group. Among the various
versions of the protocol, IGMPv3, MLDv2, and their simplified
versions LW-IGMPv3 and LW-MLDv2 [24] are suggested to be used
because they support source-specific group join mode, which is
useful in efficient multicast provision. Besides, the protocols
also provide the capability to implement explicit tracking (not
Liu. Expires December 14, 2009 [Page 7]
Internet-Draft Multicast Receiver Mobility June 2009
available in their early versions), which helps improve fast leave
capability.
Normal IGMP or MLD procedure is used for receiver to send group
report and for mobile multicast agent to query the receiver. For
tunnel mechanism, these reports and queries are sent through the
tunnel between the MHA and the MFA or between the MHA and the
receiver. For multicast routing optimization, these messages will
be exchanged between the MFA and the receiver directly. The IGMP
and MLD packet should be destined to link-local address and their
TTL field should be set to 1. The setting of the destination
address of the query and report should follow the rules prescribed
in IGMP or MLD protocols.
3.5. Multicast Tree Construction and Data Forwarding
If the receiver is on the home network, or it is on the foreign
network while using the tunnel mechanism, then MHA will engage in
the construction of the multicast tree. The MHA exchanges multicast
routing packets with upstream intermediate multicast routers with
normal multicast routing procedures. The multicast routing protocol
could be of any type mentioned in section 2.
After receiving the multicast data, if the receiver is on the home
network, the MHA will deliver them to the receiver directly. If the
receiver is on the foreign network, the MHA will encapsulate them in
the tunnel and send them to the tunnel endpoint of the foreign
network, which may be MFA or receiver itself according to the kind
of the MIP protocol adopted. In the former case, the MFA will de-
capsulate the tunneled data and forward them to the receiver.
If the receiver is on the foreign network while using multicast
route optimization, then MFA will engage in the construction of the
multicast tree. The MFA will exchange multicast routing packets
with upstream intermediate multicast routers on the foreign network.
After receiving the multicast data, the MFA will deliver them to the
receiver directly.
As the summary of the features illustrated above, an example of
multicast receiver mobility architecture is shown in figure 1. The
lines between the blocks are bidirectional. With the assumption
that MHA coexists with multicast Last hop, the multicast routing
protocol is running among multicast source, intermediate routers
(omitted in the figure), and MHA, MFA1, MFA2 and MFA3 entities.
IGMP/MLD message should be exchanged between the receivers and the
Liu. Expires December 14, 2009 [Page 8]
Internet-Draft Multicast Receiver Mobility June 2009
multicast last hop (MHA and MFAs) and will be transmitted through
tunnel if tunnel mechanism is used.
Receivers R1, R2 and R3 use multicast tree constructed on home
network to forwarding multicast traffic. They correspond
respectively to the cases when the receiver is on home network (MIP
registration is not required), when MIP registration takes place
directly between the receiver and the MHA (MIPv6, DSMIPv6 or Co-
located MIPv4), and when MIP registration involves the MFA's
processing (PMIPv6 or Foreign-Agent-Advertised MIPv4). R4 and R5
utilize optimal multicast routing with the multicast tree
constructed on foreign network through MFA2 and MFA3. The difference
between R4 and R5 cases lies in which kind of MIP protocol is
supported. For R4 the MIP is running via MFA2 (PMIPv6 or Foreign-
Agent-Advertised MIPv4) and for R5 MFA3 does not involve the MIP
signaling processing (MIPv6, DSMIPv6 or Co-located MIPv4). The MIP
in brackets for R3 and R4 cases indicates that the MIP between the
receiver and the MFA is optionally supported, corresponding to
PMIPv6 (not supported) and Foreign-Agent mode MIPv4 (supported)
respectively.
Multicast routing
+------+ protocol +-----+ IGMP/MLD +----+
|source| -------... -------- | MHA |----------| R1 |
+------+ / +-----+ \ +----+
multicast| \multicast / / | \
routing : :routing / / |MIP& \MIP&tunneled
protocol: :protocol /MIP / |Tunneled \IGMP/MLD
| \ / / |IGMP/MLD \
+----+ +----+ / +-----+ +----+
|MFA3| |MFA2| | | MFA1| | R2 |
+----+ +----+ | +-----+ +----+
| | | |
IGMP/MLD| IGMP/MLD|(MIP) | |IGMP/MLD(MIP)
| | | |
+----+ +----+ | +----+
| R5 | | R4 | | | R3 |
+----+ +----+ MIP| +----+
| |
|--------------------|
Figure 1 Protocol Packets Exchanged in Multirem Architecture
Liu. Expires December 14, 2009 [Page 9]
Internet-Draft Multicast Receiver Mobility June 2009
The multicast data forwarding flow is shown in figure 2. R1 is on
home network thus is expected to receive native multicast data from
MHA, which is completely the same as that of the fixed network
multicasting. For tunnel mechanism, the data is forwarded from
source to MHA and then to R2 or R3. R2 uses (DS)MIPv6 or Co-located
mode MIPv4 for registration and R3 uses PMIPv6 or Foreign-Agent mode
MIPv4. R4 receives multicast data with optimal multicast routing
regardless of the MIP protocols adopted.
1)multicast data arrive
from source to MHA via
multicast tree constructed 2)From MHA
+------+ on home network +-----+ to R1 +----+
|source|------//--------> | MHA | -------> | R1 |
+------+ +-----+ +----+
6)multicast | | \
data arrive : 4)through Tunnel | \3) through tunnel
to MFA2 via | from MHA to MFA1| \ from MHA to R2
tree on \|/ \|/ _\|
foreign +----+ +-----+ +----+
network |MFA2| | MFA1| | R2 |
+----+ +-----+ +----+
| |
7)From MFA2| |
to R4 | 5)From MFA1 |
\|/ to R3 \|/
+----+ +----+
| R4 | | R3 |
+----+ +----+
Figure 2 Multicast Data Forwarding Diagram
3.6. Handover Considerations
The receiver could be in three states during handover. Firstly the
receiver did not join any group and is not receiving any multicast
data, then the multicast process is not needed and unicast MIP is
Liu. Expires December 14, 2009 [Page 10]
Internet-Draft Multicast Receiver Mobility June 2009
used to make tracking of the receiver. Secondly, the receiver may
previously have not received from any group, but subscribes to a
group during the handover. Because generally there is no real-time
requirement when the receiver initially makes group subscription,
the process should be the same with that without handover. In the
last case, the receiver continues multicast receiving during
handover, which is much more prone to packet loss, because the
receiver needs to make connection to the new network, to undergo the
configuration, registration and binding of its new address, and to
wait the multicast delivery on the new network. The above series of
processes require a specific period of time. If the receiver fails
to keep the connection to the previous link before the new data path
is established, the packet loss will be inevitable. This section
only discusses the third case about how to smooth the handover when
receiver is in the receiving state.
FMIP [14][15] improves the handover performance by shortening the
initial configuration time to accelerate handover process and by
establishing supplement data tunnel between the previous and new
access routers to reduce packet loss. For multicast reception, a
similar process may also be needed because of the high-throughput
feature in multicast data transmission. For example, the address
configuration delay could be reduced by advertising new network
address by previous MFA (pMFA) as described in FMIP protocol.
3.6.1 Handover in Tunnel mechanism
The registration and binding process is initiated after the receiver
acquires its new address on the foreign network and thereafter the
multicast data should be delivered by the MHA to the new foreign
network quickly. Because the MHA should have knowledge of multicast
reception state of the receiver on the new network to decide whether
to send traffic to the new network or not, the group membership
information on the new network needs to be delivered to the MHA as
soon as possible.
MIPv6 has the requirement that ''the mobile mode must not tunnel
group control packets until (1) the mobile node has a binding in
place at the home agent, and (2) the latter sends at least one
multicast group membership control packet via the tunnel'' [2]. If
this requirement is strictly followed in MIP protocols, the receiver
should wait for the registration acknowledgment and the group query
before sending its group report, which means the MHA after
registration immediately sends group query through the new tunnel.
To minimize the time consumed by this process, the group query of
the MHA could be bound together with the registration acknowledgment
Liu. Expires December 14, 2009 [Page 11]
Internet-Draft Multicast Receiver Mobility June 2009
message with the latter extended to carry the information provided
by a query to the receiver. The method has the advantage of
reduction of process time and number of packets.
If above requirement is not strictly followed and if the receiver is
permitted to send group report even before the completion of the
registration and the arriving of the query, it is also possible to
combine the group report with the registration request message to
shorten the multicast delivery. In this case, the registration
request message could be extended to carry the necessary information
provided by the report to the MHA [21][22].
3.6.2 Handover in Route Optimization
For the routing optimization mechanism, after the registration, the
new MFA (nMFA) will take the duty of data forwarding based on the
optimal multicast routing on the foreign network. If formerly there
isn't any multicast forwarding path on the nMFA for this group, the
latency introduced by the registration plus the construction of new
multicast tree branches could be considerable.
In different scenarios there may be different measures to shorten
this handover delay. For example, if the MHA currently is just on
the multicast tree for this group, it can deliver the multicast
traffic to the MFA or the receiver immediately after the completion
of registration process, even if the new access network uses
multicast optimization. After receiving the new optimal multicast
data, the reception from the tunneled data should be terminated.
This process is similar to the handover of tunnel mechanism and to
quicken this process, combination of the registration messages with
group query or report can also be adopted, as illustrated in section
3.6.1.
In some cases if the MFA is endowed with greater right, the new MFA
could join multicast tree immediately after connecting to the
receiver, not waiting for the registration acknowledgement of the
MHA. If the multicast data arrives before the returning of the
registration acknowledgment, the MFA should buffer the traffic and
wait for the registration acknowledgement of MHA to trigger the
multicast forwarding.
3.6.3 Hybrid Handover
There should be no limitation that a uniform mechanism must be taken
when the receiver is moving from an access network to another. That
Liu. Expires December 14, 2009 [Page 12]
Internet-Draft Multicast Receiver Mobility June 2009
is, the receiver could use tunnel and then use optimal multicast
routing to receive multicast traffic and vice versa.
During this hybrid network handover, if route optimization is
adopted in the new access network, the receiver takes the process of
registering on the MHA, sending group report towards the nMFA, and
receiving the new multicast data from the nMFA.
If tunnel mechanism is adopted in the new network, the receiver
should follow the procedures of registering and sending group
reporting on the MHA, receiving the multicast traffic from the new
tunnel. The detailed process of both cases of hybrid handover
should be the same as those described in 3.6.1 and 3.6.2.
3.6.4 FMIP Tunnel During Handover
FMIP [14][15] provides another measure to avoid or reduce packet
loss during handover. Because the data is still available on the
previous MFA (pMFA) and the receiver is or will be connectable on
the new MFA (nMFA), the tunnel between these two MFAs can be used to
deliver data through the tunnel from the pMFA to the nMFA and then
to the receiver.
Here steps of predictive mode multicast FMIP are used to demonstrate
the process. After the detection of the new network, the receiver
could solicit its nCoA and nMFA information through sending RtSolPr
to and receiving PrRtAdv from pMFA. Then the receiver sends FBU
message to pMFA to request the multicast tunnel. The pMFA and nMFA
exchange HI and HACK messages and after FBack sent by the pMFA the
multicast data is tunneled from the pMFA to the nMFA. Finally the
receiver triggers the reception of the data from the nMFA by sending
UNA message.
FMIP is a transitional solution to optimizing handover process. It
does not engage in the registration of the mobile receiver and could
be deployed with all kinds of MIP protocols (i.e. MIPv4, MIPv6 or
DSMIPv6, PMIPv6 [25] and etc.) with multicast capability support.
It is possible that group membership information could be carried in
extended FMIP messages to trigger multicast reception through FMIP
tunnel as illustrated in [26].
3.6.5 Termination of Duplicate Multicast Traffic
In different handover scenarios mentioned in previous sections, the
receiver is possibly receiving at the same time from both the new
and previous network when it is connected to both links and possibly
Liu. Expires December 14, 2009 [Page 13]
Internet-Draft Multicast Receiver Mobility June 2009
receives redundant traffic. Normally at this time the old path
should be torn down as quickly as possible to reduce unnecessary
traffic.
It is possible to let the previous forwarding entity to wait for a
specific period of time before stopping the previous traffic. But
sometimes this predetermined time interval might not meet the
complicated handover situations. Further, if the previous and new
forwarders do not coexist (e.g. in optimal multicast routing
handover cases), it is impossible for the previous forwarder to know
the exact time when the new traffic arrives at the receiver.
One solution to this is to inform the previous forwarder the ceasing
of data delivery by some kind of control message. Even though a new
message particular for this purpose could be defined, it is also
possible to make use of an IGMP/MLD group leave packet. This
IGMP/MLD packet to terminate redundant multicast traffic is
different from the normal IGMP Leave or MLD Done message for their
purpose is to inform the end of redundant traffic rather than to de-
subscribe from the group. If it is possible, the source address of
this IGMP/MLD control packet could be set to the receiver's previous
network address to distinguish it from a normal group de-
subscription leave packet. On receiving this control message, the
previous forwarding entity should stop forwarding multicast traffic
and possibly take other procedures such as pruning from the
multicast tree if there is no other multicast receiver attached to
its link.
3.6.6 Moving Back and Forth during Handover
When a receiver is moving back and forth during handover, it may
connect an access node then disconnect it, or may disconnect and
then reconnect it, described as ''ping-pong mobility'' in [18]. For
the latter case, when the disconnection occurs, the access node may
prune the multicast forwarding path. If after a while, when the
receiver moves back and reconnects to the access node, the multicast
forwarding path has to be re-established, with additional signaling
delay.
To overcome this shortcoming, the access nodes during handover could
choose to preserve for a specified period of time the forwarding and
other related states for the receiver even though the receiver is
out of reach. If within this time interval the receiver moves back
into the access node's range, the multicast data could be delivered
to the receiver quickly. For tunnel mechanism, the forwarding
states should be preserved by the MHA and for route optimization
Liu. Expires December 14, 2009 [Page 14]
Internet-Draft Multicast Receiver Mobility June 2009
they should be preserved by MFA. This measure can be used to
improve the multicast handover performance but can be deployed by
both the unicast and multicast applications.
3.7. Authentication and Accounting
The authentication is used to check the validity of the message
originator in multicast mobility architecture. The authentication
can be carried out anytime and anywhere and on any entities
depending on the policy deployed by the network providers. The
provider according to the trust level of the entities determines
what kind of security mechanism should be put on these entities when
they exchange their messages. The authentication probably happens
when a receiver initially connects to the access nodes of home or
foreign network, when the receiver registering its binding on its
MHA, when the receiver registers on its MFA, or when the pMFA and
nMFA decide to use the tunnel for fast handover. There should be no
restrictions on the authentication mechanism adopted. They could be
taken by other protocols or could be carried in the messages within
multicast mobility architecture, which are not discussed in this
document.
The accounting of multicast receiver could be implemented out-band
of multicast data transfer. The MHA and MFA as the direct data
forwarder to the receiver could take the duty of collecting
accounting data and could send them actively to the accounting
server or other network entities, or passively in response of the
queries. The implementation methods should depend on the deployment
policy of the provider and are not discussed within this document.
4. Considerations for Different MIP Protocols
4.1. MIPv4
MIPv4 defines two different communication modes according to whether
the CoA is assigned by the foreign agent or by other external
mechanism. They are discussed in section 4.1.1 and 4.1.2.
4.1.1 When CoA advertised by foreign agent
In this mode an entity of foreign agent involves in the MIPv4
signaling procedures and it should be the MFA in multicast receiver
mobility architecture.
The receiver takes normal fixed-network multicast procedures on home
network. On foreign network, after the receiver obtains its CoA, it
Liu. Expires December 14, 2009 [Page 15]
Internet-Draft Multicast Receiver Mobility June 2009
registers through the MFA the binding of this CoA on MHA by MIPv4
signaling. If tunneling is used, the MFA encapsulates the
receiver's IGMP report and tunnels it to the MHA and the MHA queries
periodically the group membership of the receiver through the tunnel
to the MFA. The MHA on receiving the report joins the multicast
tree on the home network and after receiving the multicast data
sends them through the tunnel towards the MFA. The MFA decapsulates
the queries and the multicast data and forwards them to the receiver.
The endpoints of the tunnel are MHA and MFA, with outer layer
addresses set to the interface addresses of the MHA and the home
address of the receiver. The inner sources of the report and query
should be respectively the home address of the receiver and
interface address of MHA. The inner destination address of the
report and query should be set as the IGMP protocols describe.
If optimal multicast is used, the IGMP group reports will be
processed and IGMP queries will be sent by the MFA (if it is the
last-hop), which will join the multicast tree on the foreign network.
After receiving the multicast data, the MFA forwards them to the
receiver.
The receiver and the MFAs can use IPv4 version of FMIP [14] and its
extension to facilitate the fast handover, as described in section
3.6.4.
4.1.2 Co-located CoA
In this mode the receiver and the home agent communicate directly
and there is no such an entity as the foreign agent. Thus the
access node on the foreign network is regarded as the MFA in the
multicast mobility.
The co-located CoA is configured by other external mechanism such as
DHCP. The registration of this CoA is directly between the receiver
and the MHA by MIPv4 signaling. For tunnel mechanism, after the
registration and binding, if the receiver wants to subscribe a
multicast group, it sends the IGMP report directly to the MHA
through the tunnel to the MHA. The MHA joins the multicast tree on
the home network and after receiving the multicast data, tunnels
them directly to the receiver.
The endpoints of the tunnel are MHA and the receiver, with outer
layer addresses set to the interface addresses of the MHA and the
CoA of the receiver. The inner source of the report and query
should be the home address of the receiver and interface address of
Liu. Expires December 14, 2009 [Page 16]
Internet-Draft Multicast Receiver Mobility June 2009
MHA. The inner destination address of the report and query should be
set as the IGMP protocols describe.
If optimal multicast route is used, the access node on the foreign
network should act as MFA and should be engaged in the multicast
tree construction on the foreign network. This access node after
receiving the multicast data, will deliver them to the receiver.
The receiver should use its CoA when communicating with its MFA if
MFA is ignorant of the receiver's home address. In this case the
address setting rule should be the same as that of fixed network
multicast.
The receiver and the MFAs can use IPv4 version of FMIP [14] and its
extension to facilitate the fast handover, as described in section
3.6.4.
4.2. MIPv6 and DSMIPv6
MIPv6 resembles the co-located mode of MIPv4 for the receiver
communicates directly with the home agent without the signaling
participation of the access node on the foreign network, as
described in section 4.1.2. The receiver use traditional IPv6
address configuration method (stateless or stateful) to obtain the
CoA address on foreign network and use MIPv6 signaling to make the
registration and binding between the CoA and home address on the
home agent. Both tunnel and optimal multicast routing can be used
and the address setting method for group membership message and
multicast data should follow the principles given in MIPv6 and MLD
protocols.
FMIPv6 [15] is used and may be extended implementing multicast fast
handovers as illustrated in section 3.6.4.
DSMIPv6 supplements MIPv6 with accessing of IPv4 public and private
foreign networks besides the IPv6 one. The basic communication
mechanism is the same as that of MIPv6. For DSMIPv6 the binding of
home and CoA addresses are established for both IPv6 and IPv4 types
and the tunnel should be set according to the types of access
network. In tunnel mechanism, the inner group membership management
should use MLD protocol. The address setting of tunneled packet
should follow the rules given by DSMIPv6 and MLD protocols.
If optimal multicast routing is used, the receiver after
registration sends group report to MFA. It is reasonable that MLD
will be used on IPv6 foreign network and IGMP shall be used on IPv4
network between the receiver and the MFA.
Liu. Expires December 14, 2009 [Page 17]
Internet-Draft Multicast Receiver Mobility June 2009
If the handover takes place between IPv6 foreign networks then is
FMIPv6 [15] or its extension should be used for multicast fast
handover. While for IPv4 networks the FMIPv4 [14] could be used.
4.3. PMIPv6
In PMIPv6, the receiver itself does not engage in the PMIP signaling
and LMA and MAG are respectively the MHA and the MFA counterparts in
the receiver mobile multicast. Besides, there is no permanent home
address and the receiver's address obtained on the foreign network
is home-network prefixed. The MAG has a proxy CoA address to
communicate by bidirectional tunnel with the LMA. The receiver
obtains its CoA at the current point of attachment and then the MAG
will register the binding relationship for it on the LMA by PMIP
signaling. Even if PMIP only defines tunnel mechanism, it is also
possible to use multicast route optimization.
In tunnel mechanism, if the receiver wants to join a multicast group,
it sends group report towards MAG and the MAG will encapsulate the
MLD report and tunnel it to the LMA. The LMA queries the receiver
through the tunnel from LMA to MAG and LMA initiates the tree join
operation. After receiving the multicast data, the LMA tunnels them
to the MAG and MAG will decapsulate and forward them to the receiver.
The outer layer addresses of tunneled packet should be set to the
Proxy-CoA of MAG and the interface address of LMA. When the
receiver sends the MLD report, its source address should be set to
the home-network prefixed address of the receiver. The source
address of the query should be the address of the LMA. The
destination addresses of the report and the query are set according
to MLD protocols.
If optimal multicast routing is used, the MAG after receiving the
group report will initiate the multicast tree construction on the
foreign network. After receiving the multicast data, the MAG will
deliver them to the receiver. The receiver uses home-linked address
when communicating with the MAG. The address setting rule for MLD
messages and the multicast data should be the same as that of fixed-
network multicast.
Fast handover for PMIPv6 (e.g FPMIPv6 [25]) or its extension can be
used to reduce possible multicast data loss during handover.
Liu. Expires December 14, 2009 [Page 18]
Internet-Draft Multicast Receiver Mobility June 2009
5. Security Considerations
The security mechanism particular for MultiRem will be considered in
the later version of the draft.
6. Acknowledgments
The author appreciates multimob mail list participants for their
contributions to this document. Special thanks should be given to
Behcet Sarikaya for his valuable comments for it.
7. References
7.1. Normative References
[1] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[3] Gundavelli, S, Ed., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[4] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
Specification (Revised)", RFC 4601, August 2006.
[5] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP",
RFC 4607, August 2006.
[6] R. Aggarwal, D. Papadimitriou, S. Yasukawa, et. al., "Extensions
to RSVP-TE for Point-to-Multipoint TE LSPs", RFC 4875, May 2007.
[7] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet
Group Management Protocol (IGMP) / Multicast Listener Discovery
(MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC4605,
August 2006.
[8] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[9] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C. and
M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 3315, July 2003.
Liu. Expires December 14, 2009 [Page 19]
Internet-Draft Multicast Receiver Mobility June 2009
[10] Fenner, W., "Internet Group Management Protocol, Version 2",
RFC 2236, November 1997.
[11] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version 3", RFC
3376, October 2002
[12] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999.
[13] Vida, R. and L. Costa, "Multicast Listener Discovery Version
2(MLDv2) for IPv6", RFC 3810, June 2004.
[14] R. Koodli and C. Perkins, " Mobile IPv4 Fast Handovers", RFC
4988, October 2007
[15] R. Koodli, "Fast Handovers for Mobile IPv6", RFC 5268, October
2007.
7.2. Informative References
[16] H. Soliman, "Mobile IPv6 Support for Dual Stack Hosts and
Routers", draft-ietf-mext-nemo-v4traversal-10.txt, April 7, 2009
[17] Romdhani, I., Kellil, M., and H. Lach, "IP Mobile Multicast:
Challenges and Solutions", IEEE Comm. Surveys 6(1), 2004.
[18] Deng, H., Schmidt, T., Seite, P., and P. Yang, "Multicast
Support Requirements for Proxy Mobile IPv6", draft-deng-multimob-
pmip6-requirement-00.txt (work in progress), November 2007.
[19] F. Xia, B. Sarikaya, "Hybrid Subscription for Multicast
Reciever Mobility in MIPv6", draft-xia-multimob-hybrid-00.txt (work
in progress), November 2007
[20] Hong-ke Zhang, Jian-feng Guan, Hua-chun Zhou, Ying Zhu,
"Multicast Routing in Proxy Mobile IPv6", draft-zhang-netlmm-pmipv6-
mcast-00.txt(work in progress), September 2008
[21] H. Asaeda, P. Seite, J. Xia, "PMIPv6 Extensions for Multicast",
draft-asaeda-multimob-pmip6-extension-00(work in progress), October
2008
[22] Y. K. Zhao and P. Seite, "The Solution for Pmipv6 Multicast
Service", draft-zhao-multimob-pmip6-solution-02.txt, October 2008
Liu. Expires December 14, 2009 [Page 20]
Internet-Draft Multicast Receiver Mobility June 2009
[23] I. Minei, K., Kompella, I. Wijnands, and B. Thomas, "Label
Distribution Protocol Extensions for Point-to-Multipoint and
Multipoint-to-Multipoint Label Switched Paths", draft-ietf-mpls-ldp-
p2mp-05.txt, May 2008.
[24] Liu, H., Cao, W., and H. Asaeda, "Lightweight IGMPv3 and MLDv2
Protocols", draft-ietf-mboned-lightweight-igmpv3-mldv2-03.txt (work
in progress), June 2008
[25] H. Yokota, K. Chowdhury, B. Patil, F. Xia, " Fast Handovers for
Proxy Mobile IPv6", draft-ietf-mipshop-pfmipv6-04.txt (work in
progress), May 2009
[26] Xia, F. and B. Sarikaya, "FMIPv6 extension for Multicast
Handover", draft-xia-mipshop-fmip-multicast-01 (work in progress),
March 2007
Authors' Addresses
Hui Liu
Huawei Technologies Co.,Ltd
KuiKe Building, No.9 Xinxi Rd.,
Hai-Dian District
Beijing, 100085
P.R. China
Email: liuhui47967@huawei.com
Liu. Expires December 14, 2009 [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-24 17:27:40 |