MAGMA Working Group Greg Daley
INTERNET-DRAFT Gopi Kurup
Expires: December 2003 Monash University CTIE
June 2003
Requirements for Mobile Multicast Clients
draft-daley-magma-mobile-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is an individual submission to the IETF. Comments
should be directed to the authors.
Definitions of requirements keywords are in accordance with the IETF
Best Current Practice - RFC2119 [KEYW-RFC]
Abstract
This document describes the existing systems available for mobile
devices to receive multicast data streams. It provides a case for
common handling of Network Attachment Detection for moving multicast
clients independent of global mobility signalling.
Table of Contents
Status of this Memo.......................................... 1
Abstract..................................................... 1
Table of Contents............................................ 1
Daley, Kurup draft-daley-magma-mobile-00.txt [Page 1]
INTERNET-DRAFT Mobile Multicast Client Requirements February 2003
1.0 Introduction............................................. 2
1.1 Terminology............................................. 2
2.0 Multicast Client Mobility................................ 3
2.1 Using Global Mobility Signalling for Multicast.......... 4
2.2 Joining a Group on a Visited Link...................... 5
2.3 Leaving a Visited Link.................................. 5
3.0 Proposal for Handling Multicast Client Movement.......... 6
3.1 Detecting Network Attachment............................ 6
3.2 Detecting Client Detachment............................. 6
3.3 Minimizing Multicast Routing Changes.................... 7
4.0 IANA Considerations...................................... 7
5.0 Security Considerations.................................. 7
Normative References......................................... 8
Non-Normative References..................................... 8
Acknowledgements............................................. 9
Authors' Address............................................. 9
1.0 Introduction
Multicast routing enables a set of applications which have
scalability benefits when many nodes on a subnet (or set of links)
wish to receive a common stream of data. This document describes the
existing systems available for mobile devices to receive multicast
data streams.
Most of the work which has been previously undertaken to provide
mobility support for hosts has relied upon unicast routing
[MIPv6-22,3GPP-MULT]. Work on these systems aims at principally at
isolating unicast address change from peer packet sources, or
providing direct path unicast routing through the use of unicast
care-of-addresses.
In the case where a mobile device does not require reception of
unicast packets, it may still have a requirement to receive multicast
streams as a client. One example environment is where commuters on
may be interested in updated weather or financial data, or local news
services.
In a dense user environment such as this, unicasting of these data
streams using mobility protocols will be inefficient and may lead to
excess bandwidth consumption[MULT-UMTS].
If multicast is employed as an alternative delivery mechanism to
mobile hosts, there are tasks which must be performed in order to
start receiving multicast data streams on a new link. Additionally,
issues arise from the mobility of multicast clients which mean that
group membership information held by routers is not up-to-date.
Daley, Kurup draft-daley-magma-mobile-00.txt [Page 2]
INTERNET-DRAFT Mobile Multicast Client Requirements February 2003
As will be described in this document, some of these issues are
common to other application domains and may be handled using
mechanisms in common with those systems.
1.1 Terminology
IP - Internet Protocol Version 6 (IPv6)[IP6-RFC].
DAD - Duplicate Address Detection [SAA-RFC]
MLD - Multicast Listener Discovery [MLD-RFC]
node - a device that implements IPv6.
router - a node that forwards IPv6 packets not explicitly
addressed to itself.
host - any node that is not a router.
link - a communication facility or medium over which nodes can
communicate at the link layer, i.e., the layer
immediately below IPv6. Examples are Ethernets (simple
or bridged); PPP links; X.25, Frame Relay, or ATM
networks; and internet (or higher) layer "tunnels",
such as tunnels over IPv4 or IPv6 itself.
address - an IPv6-layer identifier for an interface or a set of
interfaces.
querier - router on the subnet which actively queries MLD
state.
snooping - A mechanism whereby Link-Layer devices attempt to
infer multicast group membership by monitoring
MLD messages.
2.0 Multicast Client Mobility
MLD [MLD-RFC] defines mechanisms for joining Multicast groups on a
link. This protocol's goal is to provide a mechanism for determining
the presence or absence of hosts, in order that multicast routing
trees may be built to deliver streams of data to these clients.
Upon attaching to a link, a multicast client is instructed to send
MLD Reports for each of the multicast groups which it wishes to join.
When it receives a report, the Multicast Router requests a stream to
be sent to its own subnet if it is not already receiving that data.
Data will then arrive if multicast senders are transmitting for the
Daley, Kurup draft-daley-magma-mobile-00.txt [Page 3]
INTERNET-DRAFT Mobile Multicast Client Requirements February 2003
requested (S,G) pair[MLDv2-ID].
When the client is moving, there is no existing provision which
allows the host to detect if it has arrived on a network where these
streams already exist. Additionally, until it receives router
advertisement information[ND-RFC], it may not be aware even if it is
attaching to a link where it has already joined the multicast groups
(for example if the Link-Layer Access Point changed, but not the IP
subnet).
Movement of a mobile device away from a node is problematic in that
existing multicast systems propagate data on the link for a fixed
interval unless the host explicitly leaves all of its multicast
groups before moving to another link. While this may be possible in
some link technologies where planned handovers are common [MULT-
UMTS], in circumstances where this signalling is not possible,
trailing multicast group memberships are left by moving nodes.
2.1 Using Global Mobility Signalling for Multicast
Existing work on Mobile IPv6 attempts to avoid reliance on Multicast
routing in the access networks by providing MLD support over a tunnel
between a mobile multicast client and its Home Agent Router. The
Home Agent is principally a device which redirects unicast packets to
a host when it has moved away from its unicast Home Address' subnet.
Under this scheme, multicast packets are treated in the same fashion
as unicast packets and are encapsulated in IPv6 and IPSec headers
before delivery to the mobile multicast client. The addition of such
headers to multicast packets is problematic in that their final size
may exceed link MTUs. This may lead to loss of the complete data
stream since Multicast systems provide no mechanisms for resizing
packets for clients on links with small MTUs.
Additionally, if the multicast client happens to be on the same
subnet as another device receiving this multicast data stream, it
loses the scalability benefits of group membership, and each packet
will be transferred across the link many times[MULT-UMTS].
Conversely, if the mobile client population for this data stream is
sufficiently sparse, this may provide a reliable access to multicast
traffic, without undue burden to the visited access
network[MIPv6-22].
2.2 Joining a Group on a Visited Link
Tunneled Multicasting may be valid in situations where multicast data
is associated with the mobile client's home network, but is not valid
Daley, Kurup draft-daley-magma-mobile-00.txt [Page 4]
INTERNET-DRAFT Mobile Multicast Client Requirements February 2003
if information received is specific to the visited domain.
For these services, at least, it is important to join multicast
groups on the visited access network. This means that MNs arriving
on-link will be bound to send MLD group join messages as soon as they
are aware that they are on a new link. If the mobile client
discovers that it is receiving a multicast data stream, but has not
sent reports to join the group on this link, it is still required to
join the group since the device which reported may itself be mobile
and cause the group to be removed by moving to another link.
In each case, the mobile client should either determine that the link
is a new one, or transmit MLD group join (report) messages even if
the link is the same. This second method may cause excessive
multicast traffic on the link if there may be many Link-Layer
handovers without changing subnet.
A notable exception to this is when it is possible that MLD snooping
may be in use within the access network [SNOOP-07]. In this case
snooping networks will require MLD group join messages whenever the
multicast client changes its Link-Layer attachment.
Further investigation of the effects of MLD snooping on host mobility
is required before recommendations may be made in this regard.
2.3 Leaving a Visited Link.
It is worth noting that a mobile client will (by default) maintain
group membership until the MLD Multicast Listener Interval expires.
This entails failing to send in an MLD report after a periodic Group
Query from the MLD Querier Router [MLD-RFC,MLDv2-ID].
This may lead to the multicast router continuing to send packets
associated with a group to the mobile client, even if the this client
has moved, and it was the only member of the group.
If the mobile client is able to send an Multicast Listener Done
message, this issue does not occur, although this requires the client
to predict when it is about to move [FMIPv6-06,L2MANY-02]. Given
that this is not the case with most mobile devices today, it is
reasonable to expect that in some environments Multicast Routers may
have multiple groups for which data are transmitted onto a link for
absent clients. This would be a significant drain on wireless link
bandwidth resources, and could even be used to deny service.
Daley, Kurup draft-daley-magma-mobile-00.txt [Page 5]
INTERNET-DRAFT Mobile Multicast Client Requirements February 2003
3.0 Proposal for Handling Multicast Client Movement
Movement of multicast clients from subnet to subnet is likely to
cause significant routing disruption to multicast routing tables, or
additional bandwidth consumption. Here we outline three proposals
which may be of use in reducing link utilization and multicast
signalling.
3.1 Detecting Network Attachment
The role of joining a group is simply that of sending an MLD Report
and initiating timers. Even though this task is very simple to
perform, it is required for every group the multicast client is
interested in. Therefore it is valuable to avoid sending MLD reports
unless it has arrived at a link where its MLD group membership has
not been registered. This is particularly important if clients may
attach to a the same subnet many times as part of Link-layer handover
procedures.
There are existing reasons for detecting whether a host is attached
to a new link. For example in [MIPv6-22], mechanisms for detecting
movement have been defined which may be able to provide knowledge of
link identity using IPv6 Router Discovery[ND-RFC][MDO-01].
Similar requirements exist for hosts without mobility signalling, in
order to determine if a session is able to maintain connectivity with
currently selected addresses.
It may make sense to use Router Discovery to determine the current
configuration status of a link using a common method. This method
could then be used for all affected sessions on the host, whether
unicast or multicast.
Currently enough interest exists in this field to propose a BoF
Session for IETF57 on Detecting Network Attachment.
3.2 Detecting Client Detachment
Access Routers on a link may have access to additional information
about the presence of hosts attached to a link. This may take the
form of communication with Link-Layer devices (such as wireless
access points) on a link, or through communication to peer ARs within
a routing domain. It may be possible for access routers to remove
old multicast state when the router is certain that the mobile client
has departed.
For Link-Layer devices, it may be possible to associate an Link-layer
identifier with the identity of a multicast client. When a wireless
Daley, Kurup draft-daley-magma-mobile-00.txt [Page 6]
INTERNET-DRAFT Mobile Multicast Client Requirements February 2003
Access Point indicates the removal of this Simple hysteresis
mechanisms could ensure that routing state is not changed in the case
where a client momentarily disconnects due to Link-Layer
handover[L2TRIG-01].
Upon the multicast client's arrival at a new network, it may be
possible for the new access router to initiate a context transfer
with the old AR, which would remove the client's old multicast state.
While it is not seen as useful to initiate multicast services on a
new network using context transfer, it may be valid to remove
existing state on a previous network using such protocolsp[CTPPROB].
At this stage, the use of the Context Transfer Protocol between ARs
in a domain is ongoing within the SEAMOBY-WG of the IETF[CTP-02].
Additional protocols or mechanisms which define methods to
communicate Link-Layer connectivity within the local subnet are
underway, although no particular working group has ownership of this.
3.3 Minimizing Multicast Routing Changes
If mobile devices engender sparse Multicast Routing behaviour, there
may be significant cost in re-calculating and re-propagating
multicast trees, to support mobile client movements. It may be
necessary in some cases to defer multicast routing updates, by
adopting a local tunneling solution between pairs of Access
Routers[BETH,FMIPv6-06]. This would allow ARs to request data
streams from a router which is known to have access to a group,
without explicitly modifying global multicast routing. When routing
updates are completed, the new AR sends a Multicast Listener Done
message for the stream, across the tunnel.
This system would have similar MTU issues to the Unicast Mobility
systems described previously, except that the AR decapsulates packets
once they leave the tunnel before delivery on the access network.
Additionally, the role of the AR as arbiter of which groups arrive on
link is maintained.
At this stage, further analysis is required to determine if this
mechanism is actually useful in real networks.
4.0 IANA Considerations
N/A.
5.0 Security Considerations
This document describes a set of existing approaches which each have
their own security considerations.
Daley, Kurup draft-daley-magma-mobile-00.txt [Page 7]
INTERNET-DRAFT Mobile Multicast Client Requirements February 2003
Current work on Securing Neighbor Discovery [SENDIPSEC-01] may be
applicable to determine trust when undertaking router discovery
operations.
The proposal for edge multicast tunnel establishment handovers
Normative References
[KEYW-RFC] S. Bradner. Key words for use in RFCs to Indicate
Requirement Levels. Request for Comments (Best Current Practice)
2119 (BCP 14), Internet Engineering Task Force, March 1997
[ND-RFC] T. Narten, E.Nordmark, W. Simpson. Neighbor Discovery for
IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461,
Internet Engineering Task Force, December 1998.
[MLD-RFC] S. Deering, W. Fenner, B. Haberman. Multicast Listener
Discovery (MLD) for IPv6. Request for Comments (Proposed
Standard) 2710, Internet Engineering Task Force, October 1999.
[MLD-SRC] B. Haberman. "Source Address Selection for Multicast
Listener Discovery Protocol (RFC 2710)", Internet Draft (work in
progress), September 2002.
[SENDIPSEC-01] J. Arkko et al, "Secure Neighbor Discovery (SEND)",
Internet Draft (work in progress), June 2003.
[SNOOP-07] M. Christensen, K. Kimball, F. Solensky, "Considerations
for IGMP and MLD snooping switches", Internet Draft (work in
progress), April 2003.
Non-Normative References
[MIPv6-22] D. Johnson, C. Perkins, J. Arkko. Mobility Support in
IPv6. Internet Draft (work in progress), May 2003.
[MULT-UMTS] Mariann Hauge, Øyvind Kure,"Multicast in 3G Networks:
Employment of Existing IP Multicast Protocols in UMTS",
Proceedings of the 5th ACM international workshop on Wireless
mobile multimedia, 2002 , Atlanta, Georgia, USA
[3GPP-MULT] "Universal Mobile Telecommunications System (UMTS);
Multimedia Broadcast/Multicast Service (MBMS); Stage 1", 3GPP
TS 22.146 version 6.2.0 Release 6, 2002.
[MLDv2-ID] R. Vida et al. Multicast Listener Discovery Version 2
(MLDv2) for IPv6. Internet Draft (work in progress), June 2002.
Daley, Kurup draft-daley-magma-mobile-00.txt [Page 8]
INTERNET-DRAFT Mobile Multicast Client Requirements February 2003
[CTPPROB] J. Kempf (Ed.). "Problem Description: Reasons For
Performing Context Transfers Between Nodes in an IP Access
Network", RFC 3374 (Informational), September 2002.
[CTP-02] J. Loughney (Ed.). "Context Transfer Protocol", Internet
Draft (work in progress), June 2003.
[MDO-01] G. Daley, JinHyeock Choi. "Movement Detection Optimization
in Mobile IPv6", Internet Draft (work in progress), May 2003.
[FMIPv6-06] R. Koodli (Ed.). "Fast Handovers for Mobile IPv6",
Internet Draft (work in progress), Mar 2003.
[L2MANY-02] A. Yegin (Ed.). "Supporting Optimized Handover for IP
Mobility - Requirements for Underlying Systems", Expired
Internet Draft, June 2002, http://www.yegin.org/alper/draft-
manyfolks-l2-mobilereq-02.txt
[L2TRIG-01] A. Yegin "Link-layer Triggers Protocol", Internet Draft
(work in progress), June 2003.
Acknowledgements
Alper Yegin's Contributions to the DNA-BoF mailing list have helped
in describing MLD state removal mechanisms.
Authors' Address:
greg.daley@eng.monash.edu.au
Greg Daley
g.kurup@eng.monash.edu.au
Gopi Kurup
Centre for Telecommunications and Information Engineering
Department of Electrical and Computer Systems Engineering
Monash University
Clayton 3800
Victoria
Australia
This document expires in December 2003.
Daley, Kurup draft-daley-magma-mobile-00.txt [Page 9]