I. Miloucheva,
Internet Draft K. Jonas
Expires: December 10, 2005 SATCOM
June 8, 2005
Multicast Context Transfer in mobile IPv6
draft-miloucheva-mldv2-mipv6-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 December 10, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Protocol mechanisms for fast mobile multicast in IPv6 based on multicast
listening context transfer are proposed.
The focus is the context transfer for mobile multicast listeners using
Multicast Listener Discovery protocol Version 2 (MLDv2).
Multicast context transfer block and operational considerations for
optimised multicast context transfer based on Fast Handovers for Mobile
IPv6 and Candidate Access Router Discovery are described.
The requirements for MLDv2 context extension and operation at access
Miloucheva Expires December 10, 2005 [Page 1]
INTERNET-DRAFT Multicast context transfer in MIPv6 June 2005
routers to support multicast context transfer for mobile IPv6 are
specified.
Interactions of MLDv2 with Protocol Independent Multicast Sparse Mode
(PIM-SM) for multicast routing state update based on multicast
listening context transfer are overviewed.
Operational considerations for MLDv2 and PIM-SM to support multicast
receiver and source mobility based on context transfer are discussed.
Comparison with other multicast protocol proposals for Mobile IPv6
(MIPv6) is given.
Table of Contents
1. Introduction ................................................... 2
2. Terminology used in this document .............................. 3
3. Multicast context transfer ..................................... 4
3.1 Protocol overview ............................................. 4
3.2 Multicast context transfer block .............................. 6
3.3 Optimised multicast context transfer .......................... 7
3.3.1 Multicast context transfer for IPv6 Fast Handovers ....... 7
3.3.2 Multicast support with CARD protocol ..................... 9
4. Requirements for IPv6 listening and routing protocols .......... 10
4.1 Requirements for MLDv2 ........................................ 10
4.1.1. MLDv2 context extension ................................ 10
4.1.2 Operational considerations .............................. 11
4.2 Requirements for Multicast routing (PIM-SM) ................... 12
5. Comparison with other mobile multicast protocols for IPv6 ...... 12
6. IANA considerations .............................................. 13
7. Further work ..................................................... 13
References .......................................................... 13
Author's Addresses................................................... 15
1. Introduction
Context transfer is proposed for mobile nodes for quickly
re-establishment of their services when the nodes move and change their
access routers [13].
The Context Transfer protocol (CTP) [6] designed by the IETF
Seamoby WG as Experimental protocol for usage in Mobile IPv4 and MIPv6
environment is aimed to provide general mechanisms for exchange of
context data for moving mobile nodes between access routers.
In the Appendix B of CTP specification [6], an example for multicast
listener context transfer in IPv6 considering MLD [RFC2710] is given.
In this example, for each active multicast group at the access router
MLD context is established.
Because the access routers does not distinguish between MLD contexts of
individual nodes, all MLD contexts established for subscribed multicast
group addresses, which are attached to a given link at the previous
access router, are transferred to the next router during the handover.
Miloucheva Expires December 10, 2005 [Page 2]
INTERNET-DRAFT Multicast context transfer in MIPv6 June 2005
This causes additional network overhead and processing for creation of
multicast contexts and route trees at the next access routers for
multicast groups, which are not needed for the particular moving node.
The focus of the current draft is the efficient multicast context transfer
considering the Multicast Listener Discovery Protocol (MLDv2) in mobile
IPv6 (MIPv6) environment.
It is aimed to support seamless handover for mobile receivers using MLDv2
in case of Any Source [21] and Source Specific Multicast [24].
The work is based on the European project DAIDALOS [14], which goal is
heterogeneous mobile networking including DVB-T and unidirectional links
[15].
The multicast context transfer in DAIDALOS is designed to support
applications, such as:
- Multicast file and streaming distribution
- Multiparty conference scenarios
- Multicast audio and video transmission
- DVB-T.
Mobile multicast in this framework is based on MLDv2 context transfer for
mobile multicast receivers [17].
This Draft defines the multicast context transfer operations and data
structures required for MLDv2 service re-establishment in Mobile IPv6.
Facilities for optimised multicast context transfer based on the Fast
Handovers proposal for MIPv6 [5] and Candidate Access Router Discovery
(CARD) protocol [7] are overviewed.
Requirements for MLDv2 operation in case of context transfer and extension
of MLDv2 protocol context at access routers to track information per
individual nodes and their multicast groups are descried.
The interaction of MLDv2 and PIM-SM to support context transfer is
specified.
The fast mobile multicast using context transfer is compared with other
multicast solutions for IPv6 based on Fast Handovers for Mobile IPv6
[8] and Hierarchical Ipv6 Environment [9].
2. Terminology 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 [9].
Mobility related terminology is defined in [10].
The Internet Protocol (IP) multicast service model for any source multicast
(ASM) is defined in RFC 1112 [21]. Source specific multicast (SSM)
Miloucheva Expires December 10, 2005 [Page 3]
INTERNET-DRAFT Multicast context transfer in MIPv6 June 2005
provides network-layer support for one-to-many delivery only and is
defined in [19], [24], [23], [22].
Multicast Listener Discovery Version (MLDv2) for IPv6 is defined in [1] as
extension of MLD [2]. PIM-SM is specified in [3], [4].
Abbreviations used in the following text:
AR Access Router
MN Mobile Node
CTP Context Transfer Protocol
M-CTB Multicast Context Transfer Block
ASM Any Source Multicast
SSM Source Specific Multicast
FBU Fast Binding Update
3. Multicast context transfer
3.1. Protocol overview
The multicast context transfer is used in case of mobile node movement
(handover) to provide and install the listening and routing control data
for the multicast groups required for the active multicast services of
the mobile node.
Considering the Context Transfer Protocol's messages and signalling flows
[6], the context transfer for mobile multicast in IPv6 is defined.
Multicast listening in IPv6 is based on MLDv2 [1], which extends the MLD
protocol [2] for Source Specific Multicast [19].
For multicast routing, MLDv2 provides the information on the active
listeners of a particular multicast group to the multicast routing
protocol. In this draft, PIM-SM [3], [4] is considered.
Dependent on the time of the context transfer activation, the context
transfer could be based on:
- predictive signalling: context transfer starts before the handover,
when the mobile node is connected to the previous access network.
- reactive: context transfer starts after the connection of the mobile
node to the next access network.
The predictive and reactive strategies for usage of context transfer
protocol are described in [6].
In the predictive scenario for multicast context transfer described in
figure 1, the mobile node sends a message to the previous
access router to activate the context transfer.
Context transfer is started with the context activation by the mobile
node sending a message to the previous access router.
According [6], the context transfer initiation could also be based
on internally generated (link layer 2 triggers).
Miloucheva Expires December 10, 2005 [Page 4]
INTERNET-DRAFT Multicast context transfer in IPv6 June 2005
+----------------+ +-----------------+
|access network | |access network |
+----------------+ +-----------------+
| |
| |
previous AR v v next AR
+---------------+ +----------------+
| MLDv2 context | M-CTB | MLDv2 context |
| per node and | data | update |
context | aggregated | --------->| |
activate | |<--------- | |
+--> +---------------+ CT reply +----------------+
| | |
| |multicast | multicast
| | |
| MN v MN v
+-------------------+ +-------------------+
|MLDv2 socket state | handover |MLDv2 socket state |
|-------------------| ------> |-------------------|
| | | |
+-------------------+ +-------------------+
Figure 1: Predictive scenario for multicast context transfer
After the context activation, the multicast context transfer block
(M-CTB) is built at the previous access router in interaction with MLDv2.
The M-CTB includes the multicast addresses required for the multicast
services of the moving mobile node. M-CTB is sent from the previous
to the next access router in the Context Data message.
Receiving the context data message with the M-CTB, the next access router
provides it to the MLDv2 protocol for updating the multicast aggregated
context and establishement of an individual node MLDv2 context.
MLDv2 supplies the information from the M-CTB to the multicast routing
protocol to build the routing context for the multicast addresses.
This document focusses mainly on the fast multicast and the above
predictive scenario, when the context transfer is activated at the
previous access router.
Further strategies for proactive context transfer could be based on
sending a context activitate message to the next access router,
which uses a CTP's Request message to obtain the context for the
particular mobile node's multicast groups from the previous access
router.
Due additional message exchange, this kind of proactive context
transfer is not efficient for Fast Mobile Multicast.
Miloucheva Expires December 10, 2005 [Page 5]
INTERNET-DRAFT Multicast context transfer in IPv6 June 2005
Reactive scenarios are also slow for fast multicast and include
additional overhead.
In these scenarios, the mobile node sends context transfer activation
to the next access router after the handover [6].
To optimise context transfer of multicast services, this document
studies in section 3.3. further strategies for context activation
based on MIPv6 and its enhancements for Fast Handovers and
Candidate Access Router Discovery.
3.2. Multicast context transfer block
The multicast context transfer block (M-CTB) includes the information
required to re-establish the multicast listening and routing context
for the moving mobile node at the next access router.
The multicast context transfer block is designed considering MLDv2
multicast address records [1]. It has the following structure:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NmbRec| Access Point ID (M_AP) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| < ...... Multicast address records ........
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Multicast Context Transfer Block
M-CTB includes following information:
o NmbMrec - Number of following multicast address records for
the access point ID
o M_AP (48 Bit)û Access Point Identifier specifying the
IEEE MAC address of layer 2 device at the next access router
using which the mobile node will listen to the group.
o List of multicast address records.
The M-CTB is included in the Context Data Block of the CTP protocol [6]
as it is shown in figure 3:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Feature Profile Type (FTP) | Length |P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Presence Vector (if P = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Multicast Context Transfer Block (M-CTB) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Integration of M-CTB in CTP message
Miloucheva Expires December 10, 2005 [Page 6]
INTERNET-DRAFT Multicast context transfer in IPv6 June 2005
Considering the CTP specification [6], the fields in figure 3 are
defined:
o FPT - Identifies the type given for the Multicast Context
Transfer Block (M-CTB). The value is defined by IANA.
o Length (8-bit unsigned integer) - Message length in units of
8 octet words.
o 'P' bit 0 = No presence vector
1 = Presence vector present.
o Reserved - Reserved for future use.
o M-CTB - M-CTB as defined in this section with length defined
by the Length Field. If the data is not 64-bit
aligned, the data field is padded with zeros.
The M-CTB consists of number of multicast address records describing the
multicast listening state of the mobile node before moving the previous
access network.
Each multicast address record has the following structure:
+-+-+-+-+-+-+-+-+
| NmbS |F-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Multicast Address *
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Source Address [1] *
| |
* Source Address [2] *
. . .
* Source Address [N] *
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Multicast address record
The multicast address record is similar to the address record used
in the MLDv2 report messages [1]. It includes filter options (F-Types)
for source addresses and allows on this way to support SSM [25].
The Multicast record is defined by following descriptions:
o NmbS (4 bit unsigned integer) - Number of source addresses
specified for the multicast group. If the number is 0, then the
following FilterType is not checked.
o F-Type (4 bit unsigned integer) - specifies the filter type of
the source addresses specifed for the multicast grpup.
Miloucheva Expires December 10, 2005 [Page 7]
INTERNET-DRAFT Multicast context transfer in IPv6 June 2005
Value Name and Meaning
----- ----------------
1 MODE_IS_INCLUDE - defined in [1].
Indicates that the interface has a filter mode of INCLUDE
for the specified multicast address and source lists.
2 MODE_IS_EXCLUDE - defined in [1], Indicates that the
interface has a filter mode of EXCLUDE for the specified
multicast address and source lists.
o M_ADR (128 bit)û L3 (IPv6) multicast group address, to which the
mobile node will listen at the link attached to M_AP.
Multicast addresses for IPv6 architecture are defined in [20].
o SourceList û List of IPv6 source addresses (128 bit) to listen
on the multicast group.
The addresses are used as information for the multicast routing
protocol (PIM-SM) to perform source specific multicast and pruning.
3.3. Optimised multicast context transfer
The section describes optimised multicast context transfer
based on Fast Handovers MIPv6 environment and optimal next router
selection using the CARD protocol is described.
3.3.1 Multicast context transfer for IPv6 Fast Handovers
IPv6 Fast Handovers has been proposed [16] to minimize the interruption
in services experienced by a Mobile IPv6 node as it changes its point of
attachment to the Internet.
IPv6 Fast Handovers begins when a MN sends RtSolPr to its current
access router to resolve one or more Access Point Identifiers (AP-IDs)
to subnet-specific information. In response, the access router sends
a PrRtAdv message, which contains one or more [AP-ID, AR-Info] tuples.
With the AR-Info information included in the PrRTAdv
message, the mobile node formulates a prospective next Care-of address
establishing and sends Fast Binding Updates.
IPv6 Fast Handovers protocol integrates predictive and reactive handover
strategies for mobile node movement using FBUs.
The multicast context transfer could be triggered by reception of the
FBU Messages either at the previous or at the next access router:
- In the case of predictive handover, the FBU is sent to the previous
access router and triggers the context transfer activation.
- Using the reactive handover, the FBU message is sent to the next AR.
Miloucheva Expires December 10, 2005 [Page 8]
INTERNET-DRAFT Multicast context transfer in MIPv6 June 2005
It triggers a request for context transfer sent from the next access
router to the previous.
As result of this, the previous access router answers with the context
transfer data.
Predictive multicast context transfer triggered by FBU in Fast Handovers
MIPv6 is given in figure 5;
Mobile Node Prev-AR Next-AR
| | RtAdv |
| | <----------------|
|RtSolPr | |
|----------------> | |
| | |
| PrRtAdv | |
| <----------------| |
| | |
|FBU | |
|-----------------> | |
| M-CTB trigger*| Context Transfer(M-CTB) |
| | -----------------------> |
| | |
Figure 5: Predictive multicast context transfer in Fast Handovers MIPv6
Because the multicast context transfer is based on triggering using the
FBU message, it is similar to the proposal in [8]. The difference is that
[8] includes in the FBU the mobile node's multicast context data.
3.3.2 Multicast support with CARD protocol
The Candidate Access Router Discovery (CARD) protocol was designed
to support the acquisition of information about the possible next ARs
that are candidates for the mobile node's handover [7].
CARD protocol is used in EU project DAIDALOS [14] together
with the Context Transfer protocol [6] and IPv6 Fast Handovers
[16] for efficient handover aimed at optimization of service
re-establishment in case of MIPv6 node handover.
There are different issues for candidate access router discovery [13].
CARD could be used for the selection of a next router, which has
already established multicast listening and routing states for the
multicast groups, required by the mobile node.
For this purpose the multicast context as defined in section 3.2.
should be included as sub-option in the CARD Reply Signalling message
exchanged between access routers and mobile nodes.
The steps in usage of CARD for selection of optimal multicast router
are shown in figure 6:
Miloucheva Expires December 10, 2005 [Page 9]
INTERNET-DRAFT Multicast context transfer in IPv6 June 2005
Mobile Node Prev-AR Next-AR
| | |
| |AR-AR CARD Request |
| |------------------> |
| | |
| | AR-AR CARD Reply(M-CTB)|
| | <------------------ |
|MN-AR CARD Request | |
|------------------ > | |
| | |
| MN-AR CARD Reply(M-CTB)| |
| <-----------------------| |
|*selection of optimal CAR | |
|*based on multicast context | |
| | |
Figure 6: Selection of optimal multicast router based on CARD
4. Operational requirements for IPv6 Multicast protocols
4.1 Requirements for MLDv2
4.1.1. MLDv2 context extension
The following requirements concerns the operation and context maintained
at the "router" part of the MLDv2 protocol.
The "host" part of MLDv2 and its contexts per socket and interface remain
the same.
For multicast context transfer, MLDv2 must keep per node (host)
multicast group listener status on the interface.
Currently, the MLDv2 is designed to support the ASM [21] and SSM [19]
models.
The MLDv2 context at the multicast router keeps the aggregated
node information for multicast interfaces based on which the multicast
router knows that "at least one" node multicast on the attached link
is listening to packets for a particular multicast address.
Considerations for the MLDv2 routers to track per-host multicast listener
status on an interface are discussed in Appendix A.2 of the MLDv2
specification.
To provide Multicast Context Transfer in MIPv6, it is a requirement for
MLDv2 to build a multicast listener context per host (node) at the
multicast access router in order to supply information for the building
of the Multicast Control block.
Figure 7 shows an entry of the context per mobile node extending the
current aggregated MLDv2 context per given interface.
Miloucheva Expires December 10, 2005 [Page 10]
INTERNET-DRAFT Multicast context transfer in MIPv6 June 2005
+-+-+-+-+
| |
|Nb-MRef|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
* Mobile Node Address *
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
* MRef |...........................................*
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: MLDv2 context per node for a given link at the access router
The Multicast record is defined by following descriptions:
o Nb-MRef (4 bit unsigned integer) - Number of references of the
mobile node to entries in the aggregated MLDv2 context at AR.
Each entry specifies a multicast group to which the mobile node
is listening.
o M-Adr (128 bit unsigned integer) - specifies the IPv6 address
of the mobile node listening to the multicast groups and interfaces
specified by MRef.
o MRef - specifies the memory address of the entry in the
aggregated MLDv2 context.
The proposed structures for extension of MLDv2 does not change the current
aggregated context per interface and allow interoperation with existing
MLDv2 implementations.
4.1.2 Operational considerations
Based on the multicast listener context per node, MLDv2 builds the M-CTB,
as result of context transfer activation or triggering.
The M-CTB is supplied by MLDv2 to the Context transfer Protocol entity at
the previous access router. It builds a valid context transfer data
message and sends it to the next router.
Receiving the CTP message with the M-CTB, the CTP entity, the next AR
supplies the M-CTB to the MLDv2 for further processing.
The processing of the M-CTB requires that MLDv2 changes the multicast
context data at the next AR and invokes PIM-SM for building of multicast
routing updates.
4.2 Requirements for multicast routing (PIM-SM)
Using the multicast context block, MLDv2 provides information to the
Miloucheva Expires December 10, 2005 [Page 11]
INTERNET-DRAFT Multicast context transfer in IPv6 June 2005
particular multicast routing protocol to build the routes and establish
the routing context to the multicast addresses as required by the node.
If routes already exist, nothing is done. Otherwise, the actions depend
on the used multicast routing protocol.
In case of PIM-SM, there are different tasks for routing context
establishment considering the M-CTB information.
- In case that in M-CTB a multicast group address (G) without sources is
specified, the PIM-SM routing is required to perform (*, G) Join actions.
This means a join to a route for all sources of the group.
- In case that M-CTB includes the option "INCLUDE" for a particular group
address (G) and the source list (S), PIM-SM translates it in (S,G) join
and uses the specification [4] to provide source-specific join.
- When M-CTB includes an multicast address record with the option "EXCLUDE"
for the particular multicast group address (G) and source list (S),
the (S,G,rpt) source-specific pruning actions should be performed as
specified in [4].
5. Comparison with other IPv6 mobile multicast protocols
Mobility for IPv6 defines the multicast services for mobile nodes [5].
The proposed solution is slow, because it is based on the forwarding of
the multicast packets by the Home Agents via the tunnel to the mobile
nodes.
Multicast solutions extending mobile IPv6 multicast [5] are proposed for
Fast Handover [16] and Hierarchical Mobile IPv6 environments [18].
The multicast protocol for Fast Handover MIPv6 [8] is based on integration
of multicast flag in PrRtAdv message and multicast option in the Fast
Binding Update. This option includes information describing the active
multicast groups of the mobile node, for which the new access router
should establish multicast listening and routing context.
The fast mobile multicast in the framework of Hierarchical Mobile IPv6
(H-MIPv6) and MIPv6 mechanisms is proposed in [9].
The multicast distribution is based on Mobility Anchor Points defined
for the H-MIPv6 architectures. In M-HMIPv6, a mobile multicast node uses
its local MAP as anchor point for multicast communication.
All multicast traffic is directed through this MAP using the Regional
Care-of Address.
Traffic forwarding between MN and its MAP is done using a bi-directional
tunnel. If a MN changes location within its MAP domain, it only
registers its new Care-of Address with the MAP [D-HMIPv6], which does
not affect multicast routing trees.
Miloucheva Expires December 10, 2005 [Page 12]
INTERNET-DRAFT Multicast context transfer in IPv6 June 2005
When entering a new MAP domain, a MN will be eager to sustain multicast
connectivity via its previously established MAP.
Multicast handover procedures will occur, only if the MN changes into a
new M-HMIPv6 enabled MAP domain, and will then shift multicast traffic
from the previous to the current MAP.
In H-MIPv6, MLDv2 reports are extended with attendance code field to
support multicast routing optimisation. The two approaches are based on
extensions of specific protocols for seamless mobile handover in IPv6.
Compared with these approaches, multicast context transfer as proposed
in the current Draft could be integrated in different mobile IP
architectures as it is shown in section 3.1 and 3.3.
Because of the individual contexts at the ARs, a scalability problem
dependent on the number of receiving mobile nodes arises.
In case of great number of mobile nodes using a particular access
router for mobile multicast, performance degradation is possible, which
should be considered in the design and implementation.
6. IANA considerations
IANA should record a value for identification of multicast context
transfer block (M-CTB).
7. Further work
This draft specifies the multicast receiver mobility based on context
transfer. It is intended for mobile nodes listening to multicast groups
based on ASM model or subscribed to multicast channels using SSM.
Multicast source mobility in the context of SSM needs further work and
specification.
References
[1] R. Vida, and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004.
[2] S. Deering, W. Fenner, and B. Haberman, "Multicast Listener Discovery
(MLD) for IPv6", RFC 2710, October 1999.
[3] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley,
V. Jacobson, C. Liu, P. Sharma, L. Wei,"Protocol Independent
Multicast-Sparse Mode (PIM-SM): Protocol Specification",
RFC 2362, Experimental, June, 1998
[4] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol Independent
Multicast-Sparse Mode (PIM-SM): Protocol Specification (Revised)",
draft-ietf-pim-sm-v2-new-10.txt, July 2004, Work in Progress
[5] D. Johnson, C. Perkins, J. Arkko, Mobility Support in IPv6,
RFC 3775, June 2004
Miloucheva Expires December 10, 2005 [Page 13]
INTERNET-DRAFT Multicast context transfer in IPv6 June 2005
[6] J. Loughney, M. Nakhjiri, C. Perkins, R. Koodli, Context Transfer
Protocol, draft-ietf-seamoby-ctp-11.txt, August, 2004
[7] M. Liebsch, A. Singh, H. Chaskar, D. Funato, E. Shim, Candidate Access
Router Discovery, IETF Seamoby Working Group, Internet Draft,
draft-ietf-seamoby-card-protocol-08.txt, September 2004
[8] K.Suh, D-H. Kwon, Y-J. Suh, Y. Park, Fast Multicast Protocol
for Mobile Ipv6 in the fast handovers environment,
draft-suh-mipshop-fmcast-mip6-00.txt, January 2004, Work in Progress
[9] T.C. Schmidt, M. Waehlisch. Seamless Multicast Handover in a
Hierarchical Mobile Ipv6 Environemnt (M-HMIPv6),
draft-schmidt-waehlisch-mhmipv6-03.txt, April 2005, Work in Progress
[10] S.Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[11] J. Manner, M. Kojo, Ed., "Mobility Related Terminology", Network
Working Group, RFC 3753, Informational, June 2004
[12] S. Bradner, V. Paxson, "IANA Allocation Guidelines For Values In the
Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000.
[13] J. Kempf et al., "Problem Description: Reasons For Performing Context
Transfers Between Nodes in an IP Access Network", RFC 3374, May 2001.
[14] Designing Advanced Interfaces for the Delivery and Administration
of Location independent Optimised personal Services, DAIDALOS
EU IST project, www.ist-daidalos.org
[15] I. Miloucheva, O. Menzel, Support of mobile nodes with unidirectional
links in MIPv6, Internet Draft, June 2005, Work in Progress
[16] R. Koodli (ed.), Fast Handovers for Mobile Ipv6, November 2004,
Internet Draft, Work in Progress
[17] M.Vieth, O.Menzel, I.Miloucheva, K.Jonas, J.Plßcido, H.Santos,
E. Guainella, Learning for efficient handover of QoS based mobile
multicast services CITSA Conference, July 2005
[18] H.Soliman, C. Catelluccia, K.Malki, L. Bellier, Hierarchical Mobile
IPv6 mobility management(HMIPv6), Internet Draft, December 2004
[19] [D-HC 04a] Holbrook, H. and B. Cain, "Source-Specific Multicast",
Interet Draft, September 2004, Work in Progress.
[20] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture, RFC 3513, April 2003.
Miloucheva Expires December 10, 2005 [Page 14]
INTERNET-DRAFT Multicast context transfer in IPv6 June 2005
[21] Deering, S., "Host Extensions for IP Multicasting," RFC 1112,
August 1989.
[22] D. Thaler, B. Fenner, and B. Quinn, Socket Interface Extensions
for Multicast Source Filters. RFC 3678, January 2004.
[23] H. Holbrook and B. Cain, "IGMPv3/MLDv2 for SSM", Internet Draft,
Work in Progress, June 2004.
[24] S. Bhattacharyya, An Overview for Source-Specific Multicast (SSM),
RFC 3569, July 2003
Author's Addresses
Ilka Miloucheva
Fraunhofer Institute
SATCOM FOKUS,Schloss Birlinghoven Phone: +49-2241-14-3471
53757 Sankt Augustin, Germany email: ilka@fokus.fraunhofer.de
Karl Jonas
Fraunhofer Institute
SATCOM FOKUS,Schloss Birlinghoven Phone: +49-2241-14-1599
53754 Sankt Augustin, Germany Email: karl.jonas@ieee.org
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Miloucheva Expires December 10, 2005 [Page 15]
INTERNET-DRAFT Multicast context transfer in IPv6 June 2005
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Miloucheva Expires December 10, 2005 [Page 16]