< draft-vonhugo-multimob-cxtp-extension-02.txt		draft-vonhugo-multimob-cxtp-extension-03.txt >
	MULTIMOB Group D. von Hugo		MULTIMOB Group D. von Hugo
	Internet-Draft Telekom Innovation Laboratories		Internet-Draft Telekom Innovation Laboratories
	Expires: February 16, 2013 H. Asaeda		Intended status: Experimental H. Asaeda
	Keio University		Expires: August 16, 2013 NICT
	August 15, 2012		February 12, 2013
	Context Transfer Protocol Extension for Multicast		Context Transfer Protocol Extension for Multicast
	draft-vonhugo-multimob-cxtp-extension-02		draft-vonhugo-multimob-cxtp-extension-03
	Abstract		Abstract
	This document describes an extension of the Context Transfer Protocol		This document describes an extension of the Context Transfer Protocol
	(CXTP) to support seamless IP multicast services with Proxy Mobile		(CXTP) to support seamless IP multicast services with Proxy Mobile
	IPv6 (PMIPv6).		IPv6 (PMIPv6).
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on February 16, 2013.		This Internet-Draft will expire on August 16, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 3, line 16 ¶		skipping to change at page 3, line 16 ¶
	This document describes an extension of the Context Transfer Protocol		This document describes an extension of the Context Transfer Protocol
	(CXTP) [9] to provide seamless handover for multicast communications		(CXTP) [9] to provide seamless handover for multicast communications
	operated with Proxy Mobile IPv6 (PMIPv6) [2]. When a mobile node		operated with Proxy Mobile IPv6 (PMIPv6) [2]. When a mobile node
	receiving multicast data detaches from the current MAG and attaches		receiving multicast data detaches from the current MAG and attaches
	to a new MAG, the node should be able to continuously receive the		to a new MAG, the node should be able to continuously receive the
	multicast data through the new MAG just after the node completed		multicast data through the new MAG just after the node completed
	handover without any MLD signaling on the new wireless link. This		handover without any MLD signaling on the new wireless link. This
	procedure is multicast context transfer that provides multicast		procedure is multicast context transfer that provides multicast
	session continuity and avoids extra packet loss and session		session continuity and avoids extra packet loss and session
	disruption. Multicast context transfer will be the required function		disruption. Multicast context transfer is proposed as the required
	to support seamless handover, while for its effective procedure,		function to support seamless handover, while for its effective
	interaction with multicast communication protocols should be taken		procedure, interaction with multicast communication protocols should
	into account.		be taken into account.
	The Context Transfer Protocol (CXTP) specification [9] describes the		The Context Transfer Protocol (CXTP) specification [9] describes the
	mechanism that allows better support for minimizing service		mechanism that allows better support for minimizing service
	disruption during handover. In this document, CXTP is extended for		disruption during handover. In this document, CXTP is extended for
	the multicast context transfer protocol in PMIPv6. "Multicast-		the multicast context transfer protocol in PMIPv6. "Multicast-
	Context Transfer Data (M-CTD)" is defined for transferring multicast		Context Transfer Data (M-CTD)" is defined for transferring multicast
	membership state from a previously attached MAG (p-MAG) to a newly		membership state from a previously attached MAG (p-MAG) to a newly
	attached MAG (n-MAG) for PMIPv6. The context transfer is either		attached MAG (n-MAG) for PMIPv6. The context transfer is either
	started from the n-MAG on its own after attachment of the mobile node		started from the n-MAG on its own after attachment of the mobile node
	or initiated by the p-MAG after being informed by the access network		or initiated by the p-MAG after being informed by the access network
	of the planned handover. For data exchange between p-MAG and n-MAG a		of the planned handover. For data exchange between p-MAG and n-MAG a
	dedicated tunnel is assumed to be in place. Whether this p-MAG -		dedicated tunnel is assumed to be in place. Whether this p-MAG -
	n-MAG tunnel has already been set up in advance or will be initiated		n-MAG tunnel has already been set up in advance or will be initiated
	during handover by either p-MAG or n-MAG will impact the overall		during handover by either p-MAG or n-MAG will impact the overall
	session delay. Details of this set-up procedure are out of scope of		session delay. Details of this set-up procedure are out of scope of
	this document.		this document.
	An approach to apply CXTP to multicast for client-based mobile IPv6		An approach to apply CXTP to multicast for client-based mobile IPv6
	had been proposed in [13].		had been proposed in [13].
			Similarily to other approaches for increasing the efficiency of
			mobile multicast handover such as [14] describing the mechanism of
			Subscription Information Acquisition through the LMA (SIAL) for
			PMIPv6 the procedure described within this draft assumes that both
			the current and the new MAG are assigned to the same LMA. An
			extension for inter-LMA handover is topic for further study.
	2. Conventions and Terminology		2. Conventions and Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in		"SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in
	this document are to be interpreted as described in RFC 2119 [1].		this document are to be interpreted as described in RFC 2119 [1].
	The following terms used in this document are to be interpreted as		The following terms used in this document are to be interpreted as
	defined in the Proxy Mobile IPv6 specification [2]; Mobile Access		defined in the Proxy Mobile IPv6 specification [2]; Mobile Access
	Gateway (MAG), Local Mobility Anchor (LMA), Mobile Node (MN), Proxy		Gateway (MAG), Local Mobility Anchor (LMA), Mobile Node (MN), Proxy
	Mobile IPv6 Domain (PMIPv6-Domain), LMA Address (LMAA), Proxy Care-of		Mobile IPv6 Domain (PMIPv6-Domain), LMA Address (LMAA), Proxy Care-of
	Address (Proxy-CoA), Mobile Node's Home Network Prefix (MN-HNP),		Address (Proxy-CoA), Mobile Node's Home Network Prefix (MN-HNP),
	Mobile Node Identifier (MN-Identifier), Proxy Binding Update (PBU),		Mobile Node Identifier (MN-Identifier), Proxy Binding Update (PBU),
	and Proxy Binding Acknowledgement (PBA).		and Proxy Binding Acknowledgement (PBA).
	skipping to change at page 5, line 49 ¶		skipping to change at page 5, line 49 ¶
	3. Source addresses and multicast addresses - indicates the address		3. Source addresses and multicast addresses - indicates the address
	pairs the MN has joined.		pairs the MN has joined.
	The M-CTD message MUST contain the 'A' bit set as defined for the CTD		The M-CTD message MUST contain the 'A' bit set as defined for the CTD
	message format in [9] for to initiate the transmission of a reply		message format in [9] for to initiate the transmission of a reply
	message by the new MAG.		message by the new MAG.
	The following information included in a reply to M-CTD (similar to		The following information included in a reply to M-CTD (similar to
	the CTDR message defined in [9]) is used to request the old MAG to		the CTDR message defined in [9]) is used to request the old MAG to
	store still incoming multicast data, to forward them to the new MAG,		store still incoming multicast data, to forward them to the new MAG,
	and finally to leave the multicast group after successful handover		and finally to terminate the multicast group subscription on behalf
	from n-MAG to p-MAG.		of the Mobile Node, i.e. to leave the multicast group when the
			handover from n-MAG to p-MAG has been successfully completed.
	1. Receiver address - indicates the address of the MN sending the		1. Receiver address - indicates the address of the MN sending the
	Current-State Report.		Current-State Report.
	2. Flag indicating the p-MAG to start (B) buffering the received		2. Flag indicating the p-MAG to start (B) buffering the received
	multicast data (in case the new connection is not yet fully set		multicast data (in case the new connection is not yet fully set
	up), to forward (F) the buffered data after successful handover,		up), to forward (F) the buffered data after successful handover,
	or to leave (L) the multicast groups unless there are still		or to leave (L) the multicast groups unless there are still
	other active subscriptions for the corresponding groups on the		other active subscriptions for the corresponding groups on the
	p-MAG.		p-MAG.
	skipping to change at page 11, line 7 ¶		skipping to change at page 11, line 7 ¶
	|<-------- Multicast data --------| |		|<-------- Multicast data --------| |
	| | | |		| | | |
	| |============== PIM Prune =============>|		| |============== PIM Prune =============>|
	| | | |		| | | |
	| | | |		| | | |
	Figure 2: MLD listener handover with CXTP and PIM-SM		Figure 2: MLD listener handover with CXTP and PIM-SM
	4. IANA Considerations		4. IANA Considerations
	TBD.		This document proposes to extent messages defined by the
			experimental Context Transfer Protocol [9], i.e. the Context
			Transfer Data (CTD) Message and the Context Transfer Data Reply
			(CTDR) Message to enable transfer of multicast related data, i.e.
			M-CTD and M-CTDR. The data consist of subscription states and
			flags indicating specific actions to the MAG. Such extensions
			in terms of options, flags, and new parameters as described in
			sect. 3, 3.1., and 3.2. of this draft shall be allocated by IANA
			according to the instructions given in [15].
	5. Security Considerations		5. Security Considerations
	TBD.		TBD.
	6. Acknowledgements		6. Acknowledgements
	Many of the specifications described in this document are discussed		Many of the specifications described in this document are discussed
	and provided by the MultiMob mailing-list. Detailed comments by Luis		and provided by the MultiMob mailing-list. Detailed comments by Luis
	Miguel Contreras Murillo are gratefully acknowledged.		Miguel Contreras Murillo are gratefully acknowledged.
	skipping to change at page 14, line 23 ¶		skipping to change at page 14, line 23 ¶
	and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.		and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
	[3] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,		[3] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
	"Protocol Independent Multicast - Sparse Mode (PIM-SM):		"Protocol Independent Multicast - Sparse Mode (PIM-SM):
	Protocol Specification (Revised)", RFC 4601, August 2006.		Protocol Specification (Revised)", RFC 4601, August 2006.
	[4] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2		[4] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
	(MLDv2) for IPv6", RFC 3810, June 2004.		(MLDv2) for IPv6", RFC 3810, June 2004.
	[5] Liu, H., Cao, W., and H. Asaeda, "Lightweight IGMPv3 and MLDv2		[5] Liu, H., Cao, W., and H. Asaeda, "Lightweight IGMPv3 and MLDv2
	Protocols", RFC 5790, February 2010.		Protocols", RFC 5790, August 2010.
	[6] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet		[6] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet
	Group Management Protocol (IGMP) / Multicast Listener Discovery		Group Management Protocol (IGMP) / Multicast Listener Discovery
	(MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")",		(MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")",
	RFC 4605, August 2006.		RFC 4605, August 2006.
	[7] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet Model: The		[7] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet Model: The
	Relationship between Links and Subnet Prefixes", RFC 5942,		Relationship between Links and Subnet Prefixes", RFC 5942,
	July 2010.		July 2010.
	skipping to change at page 14, line 47 ¶		skipping to change at page 14, line 47 ¶
	7.2. Informative References		7.2. Informative References
	[9] Loughney, Ed., J., Nakhjiri, M., Perkins, C., and R. Koodli,		[9] Loughney, Ed., J., Nakhjiri, M., Perkins, C., and R. Koodli,
	"Context Transfer Protocol (CXTP)", RFC 4067, July 2005.		"Context Transfer Protocol (CXTP)", RFC 4067, July 2005.
	[10] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base Deployment		[10] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base Deployment
	for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6)		for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6)
	Domains", RFC 6224, April 2011.		Domains", RFC 6224, April 2011.
	[11] Asaeda, H. and N. Leymann, "IGMP/MLD-Based Explicit Membership		[11] Asaeda, H., "IGMP/MLD-Based Explicit Membership Tracking
	Tracking Function for Multicast Routers",		Function for Multicast Routers",
	draft-ietf-pim-explicit-tracking-01.txt (work in progress),		draft-ietf-pim-explicit-tracking-04.txt (work in progress),
	April 2012.		January 2013.
	[12] Asaeda, H. and P. Seite, "Multicast Routing Optimization by		[12] Asaeda, H. and P. Seite, "Multicast Routing Optimization by
	PIM-SM with PMIPv6",		PIM-SM with PMIPv6",
	draft-asaeda-multimob-pmip6-extension-10.txt (work in		draft-asaeda-multimob-pmip6-extension-11.txt (work in
	progress), March 2012.		progress), October 2012.
	[13] Miloucheva, I. and K. Jonas, "Multicast Context Transfer in		[13] Miloucheva, I. and K. Jonas, "Multicast Context Transfer in
	mobile IPv6", draft-miloucheva-mldv2-mipv6-00.txt (work in		mobile IPv6", draft-miloucheva-mldv2-mipv6-00.txt (work in
	progress), June 2005.		progress), June 2005.
			[14] Contreras, LM., Bernardos, CJ., and I. Soto, "PMIPv6 multicast
			handover optimization by the Subscription Information
			Acquisition through the LMA (SIAL)",
			draft-ietf-multimob-handover-optimization-01.txt (work in
			progress), December 2012.
			[15] Kempf, J., "Instructions for Seamoby and Experimental Mobility
			Protocol IANA Allocations", RFC 4065, July 2005.
	Authors' Addresses		Authors' Addresses
	Dirk von Hugo		Dirk von Hugo
	Telekom Innovation Laboratories		Telekom Innovation Laboratories
	Deutsche-Telekom-Allee 7		Deutsche-Telekom-Allee 7
	D-64295 Darmstadt		D-64295 Darmstadt
	Germany		Germany
	Phone:
	Email: Dirk.von-Hugo@telekom.de		Email: Dirk.von-Hugo@telekom.de
	URI:
	Hitoshi Asaeda		Hitoshi Asaeda
	Keio University		National Institute of Information and Communications Technology
	Graduate School of Media and Governance		Network Architecture Laboratory
	5322 Endo		4-2-1 Nukui-Kitamachi
	Fujisawa, Kanagawa 252-0882		Koganei, Tokyo 184-8795
	Japan		Japan
	Email: asaeda@wide.ad.jp		Email: asaeda@nict.go.jp
	URI: http://www.sfc.wide.ad.jp/~asaeda/
End of changes. 17 change blocks.
	28 lines changed or deleted		51 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/