draft-ietf-dmm-mag-multihoming-02.txt		draft-ietf-dmm-mag-multihoming-03.txt
	DMM WG P. Seite		DMM WG P. Seite
	Internet-Draft Orange		Internet-Draft Orange
	Intended status: Standards Track A. Yegin		Intended status: Standards Track A. Yegin
	Expires: January 26, 2017 Samsung		Expires: December 2, 2017 Actility
	S. Gundavelli		S. Gundavelli
	Cisco		Cisco
	July 25, 2016		May 31, 2017
	MAG Multipath Binding Option		MAG Multipath Binding Option
	draft-ietf-dmm-mag-multihoming-02.txt		draft-ietf-dmm-mag-multihoming-03.txt
	Abstract		Abstract
	The document [RFC4908] proposes to rely on multiple Care-of Addresses		This specification defines extensions to the Proxy Mobile IPv6
	(CoAs) capabilities of Mobile IP [RFC6275] an Network Mobility (NEMO;		protocol for allowing a mobile access gateway to register more than
	[RFC3963]) to enable Multihoming technology for Small-Scale Fixed		one proxy care-of-address with the local mobility anchor and to
	Networks. In the continuation of [RFC4908], this document specifies		simultaneously establish multiple IP tunnels with the local mobility
	a multiple proxy Care-of Addresses (pCoAs) extension for Proxy Mobile		anchor. This capability allows the mobile access gateway to utilize
	IPv6 [RFC5213]. This extension allows a multihomed Mobile Access		all the available access networks for routing mobile node's IP
	Gateway (MAG) to register more than one proxy care-of-address to the		traffic.
	Local Mobility Anchor (LMA).
	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
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 January 26, 2017.		This Internet-Draft will expire on December 2, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4		2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
	2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4		2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5
	2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Example Call Flow . . . . . . . . . . . . . . . . . . . . 5		3.1. Example Call Flow . . . . . . . . . . . . . . . . . . . . 5
	3.2. Traffic distribution schemes . . . . . . . . . . . . . . 6		3.2. Traffic distribution schemes . . . . . . . . . . . . . . . 6
	4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 7		4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 7
	4.1. MAG Multipath-Binding Option . . . . . . . . . . . . . . 7		4.1. MAG Multipath-Binding Option . . . . . . . . . . . . . . . 7
	4.2. MAG Identifier Option . . . . . . . . . . . . . . . . . . 9		4.2. MAG Identifier Option . . . . . . . . . . . . . . . . . . 9
	4.3. New Status Code for Proxy Binding Acknowledgement . . . . 10		4.3. New Status Code for Proxy Binding Acknowledgement . . . . 10
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 11		6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	8.1. Normative References . . . . . . . . . . . . . . . . . . 11		8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
	8.2. Informative References . . . . . . . . . . . . . . . . . 13		8.2. Informative References . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	Using several links, the multihoming technology can improve		Using several links, the multihoming technology can improve
	connectivity availability and quality of communications; the goals		connectivity availability and quality of communications; the goals
	and benefits of multihoming are as follows:		and benefits of multihoming are as follows:
	o Redundancy/Fault-Recovery		o Redundancy/Fault-Recovery
	o Load balancing		o Load balancing
	skipping to change at page 3, line 5 ¶		skipping to change at page 3, line 26 ¶
	o Preferences settings		o Preferences settings
	According to [RFC4908], users of Small-Scale Networks can take		According to [RFC4908], users of Small-Scale Networks can take
	benefit of multihoming using mobile IP [RFC6275] and Network Mobility		benefit of multihoming using mobile IP [RFC6275] and Network Mobility
	(NEMO) [RFC3963] architecture in a mobile and fixed networking		(NEMO) [RFC3963] architecture in a mobile and fixed networking
	environment. This document is introducing the concept of multiple		environment. This document is introducing the concept of multiple
	Care-of Addresses (CoAs) [RFC5648] that have been specified since		Care-of Addresses (CoAs) [RFC5648] that have been specified since
	then.		then.
	In the continuation of [RFC4908], a Proxy Mobile IPv6 [RFC5213] based		In the continuation of c, a Proxy Mobile IPv6 [RFC5213] based
	multihomed achitecture could be defined. The motivation to update		multihomed achitecture could be defined to enable Multi-WAN support
	[RFC4908] with proxy Mobile IPv6 is to leverage on latest mobility		for Small-Scale Fixed Networks. The motivation to update [RFC4908]
	working group achievments, namely:		with proxy Mobile IPv6 is to leverage on latest mobility working
			group achievments, namely:
	o using GRE as mobile tuneling, possibly with its key extension		o using GRE as mobile tuneling, possibly with its key extension
	[RFC5845] (a possible reason to use GRE is given on Section 3.2).		[RFC5845] (a possible reason to use GRE is given on Section 3.2).
	o using UDP encapsulation [RFC5844] in order to support NAT		o using UDP encapsulation [RFC5844] in order to support NAT
	traversal in IPv4 networking environment.		traversal in IPv4 networking environment.
	o Prefix Delegation mechanism [RFC7148].		o Prefix Delegation mechanism [RFC7148].
	o Using the vendor specific mobility option [RFC5094], for example		o Using the vendor specific mobility option [RFC5094], for example
	skipping to change at page 4, line 31 ¶		skipping to change at page 4, line 36 ¶
	| | (_ _) Flow-3		| | (_ _) Flow-3
	| | '----' Flow-4		| | '----' Flow-4
	|Flow-3		|Flow-3
	|		|
	Flow0-4		Flow0-4
	Figure 1: Multihomed MAG using Proxy Mobile IPv6		Figure 1: Multihomed MAG using Proxy Mobile IPv6
	The current version of Proxy Mobile IPv6 does not allow a MAG to		The current version of Proxy Mobile IPv6 does not allow a MAG to
	register more than one proxy Care-of-Adresse to the LMA. In other		register more than one proxy Care-of-Adresse to the LMA. In other
	words, only one MAG/LMA link, i.e. IP-in-IP tunnel, can be used at		words, only one MAG/LMA link, i.e. IP-in-IP tunnel, can be used at
	the same time. This document overcomes this limitation by defining		the same time. This document overcomes this limitation by defining
	the multiple proxy Care-of Addresses (pCoAs) extension for Proxy		the multiple proxy Care-of Addresses (pCoAs) extension for Proxy
	Mobile IPv6.		Mobile IPv6.
	2. Conventions and Terminology		2. Conventions and Terminology
	2.1. Conventions		2.1. Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	2.2. Terminology		2.2. Terminology
	All mobility related terms used in this document are to be		All mobility related terms used in this document are to be
	interpreted as defined in [RFC5213], [RFC5844] and [RFC7148].		interpreted as defined in [RFC5213], [RFC5844] and [RFC7148].
	skipping to change at page 7, line 7 ¶		skipping to change at page 7, line 13 ¶
	managed either on a per-flow or on a per-packet basis:		managed either on a per-flow or on a per-packet basis:
	o Per-flow traffic management: each IP flow (both upstream and		o Per-flow traffic management: each IP flow (both upstream and
	downstream) is mapped to a given tunnel, corresponding to a given		downstream) is mapped to a given tunnel, corresponding to a given
	WAN interface. Flow binding extension [RFC6089] is used to		WAN interface. Flow binding extension [RFC6089] is used to
	exchange, and synchronize, IP flow management policies (i.e. rules		exchange, and synchronize, IP flow management policies (i.e. rules
	associating traffic selectors [RFC6088] to a tunnel).		associating traffic selectors [RFC6088] to a tunnel).
	o Per-packet management: the LMA and the MAG distribute packets,		o Per-packet management: the LMA and the MAG distribute packets,
	belonging to a same IP flow, over more than one bindings (i.e.		belonging to a same IP flow, over more than one bindings (i.e.
	more than one WAN interface). When operating at the IP packet		more than one WAN interface). Packet distribution can be done
	level, different packets distribution algorithms are possible.		either at the transport level, e.g. using MPTCP or at When
	For example, the algorithm may give precedence to one given		operating at the IP packet level, different packets distribution
	access: the MAG overflows traffic from the primary access, e.g.		algorithms are possible. For example, the algorithm may give
	WLAN, to the second one, only when load on primary access reaches		precedence to one given access: the MAG overflows traffic from the
	a given threshold. The distribution algorithm is left to		primary access, e.g. WLAN, to the second one, only when load on
	implementer but whatever the algorithm is, packets distribution		primary access reaches a given threshold. The distribution
	likely introduces packet latency and out-of-order delivery. LMA		algorithm is left to implementer but whatever the algorithm is,
	and MAG shall thus be able to make reordering before packets		packets distribution likely introduces packet latency and out-of-
	delivery. Sequence number can be can be used for that purpose,		order delivery. LMA and MAG shall thus be able to make reordering
	for example using GRE with sequence number option [RFC5845].		before packets delivery. Sequence number can be can be used for
	However, more detailed considerations on reordering and IP packet		that purpose, for example using GRE with sequence number option
	distribution scheme (e.g. definition of packets distribution		[RFC5845]. However, more detailed considerations on reordering
	algorithm) are out the scope of this document.		and IP packet distribution scheme (e.g. definition of packets
			distribution algorithm) are out the scope of this document.
	Because latency introduced by per-packet can cause injury to some		Because latency introduced by per-packet can cause injury to some
	application, per-flow and per-packet distribution schemes could be		application, per-flow and per-packet distribution schemes could be
	used in conjunction. For example, high throughput services (e.g.		used in conjunction. For example, high throughput services (e.g.
	video streaming) may benefit from per-packet distribution scheme,		video streaming) may benefit from per-packet distribution scheme,
	while latency sensitive applications (e.g. VoIP) are not be spread		while latency sensitive applications (e.g. VoIP) are not be spread
	over different WAN paths. IP flow mobility extensions, [RFC6089] and		over different WAN paths. IP flow mobility extensions, [RFC6089] and
	[RFC6088], can be used to provision the MAG with such flow policies.		[RFC6088], can be used to provision the MAG with such flow policies.
	4. Protocol Extensions		4. Protocol Extensions
	skipping to change at page 11, line 39 ¶		skipping to change at page 11, line 50 ¶
	and the MAG Identifier option. These options are carried like any		and the MAG Identifier option. These options are carried like any
	other mobility header option as specified in [RFC5213]. Therefore,		other mobility header option as specified in [RFC5213]. Therefore,
	it inherits security guidelines from [RFC5213]. Thus, this		it inherits security guidelines from [RFC5213]. Thus, this
	specification does not weaken the security of Proxy Mobile IPv6		specification does not weaken the security of Proxy Mobile IPv6
	Protocol, and does not introduce any new security vulnerabilities.		Protocol, and does not introduce any new security vulnerabilities.
	7. Acknowledgements		7. Acknowledgements
	The authors of this draft would like to acknowledge the discussions		The authors of this draft would like to acknowledge the discussions
	and feedback on this topic from the members of the DMM working group.		and feedback on this topic from the members of the DMM working group.
			The authors would also like to thank Jouni Korhonen, Jong Hyouk Lee,
			Dirk Von-Hugo, Seil Jeon and Carlos Bernardos for their review
			feedback.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
	DOI 10.17487/RFC2119, March 1997,		RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.		[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
	Thubert, "Network Mobility (NEMO) Basic Support Protocol",		Thubert, "Network Mobility (NEMO) Basic Support Protocol",
	RFC 3963, DOI 10.17487/RFC3963, January 2005,		RFC 3963, DOI 10.17487/RFC3963, January 2005,
	<http://www.rfc-editor.org/info/rfc3963>.		<http://www.rfc-editor.org/info/rfc3963>.
	[RFC5094] Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6		[RFC5094] Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6
	Vendor Specific Option", RFC 5094, DOI 10.17487/RFC5094,		Vendor Specific Option", RFC 5094, DOI 10.17487/RFC5094,
	December 2007, <http://www.rfc-editor.org/info/rfc5094>.		December 2007, <http://www.rfc-editor.org/info/rfc5094>.
	[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,		[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
	Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",		Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
	RFC 5213, DOI 10.17487/RFC5213, August 2008,		RFC 5213, DOI 10.17487/RFC5213, August 2008,
	<http://www.rfc-editor.org/info/rfc5213>.		<http://www.rfc-editor.org/info/rfc5213>.
	[RFC5648] Wakikawa, R., Ed., Devarapalli, V., Tsirtsis, G., Ernst,		[RFC5648] Wakikawa, R., Ed., Devarapalli, V., Tsirtsis, G., Ernst,
	T., and K. Nagami, "Multiple Care-of Addresses		T., and K. Nagami, "Multiple Care-of Addresses
	Registration", RFC 5648, DOI 10.17487/RFC5648, October		Registration", RFC 5648, DOI 10.17487/RFC5648,
	2009, <http://www.rfc-editor.org/info/rfc5648>.		October 2009, <http://www.rfc-editor.org/info/rfc5648>.
	[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy		[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
	Mobile IPv6", RFC 5844, DOI 10.17487/RFC5844, May 2010,		Mobile IPv6", RFC 5844, DOI 10.17487/RFC5844, May 2010,
	<http://www.rfc-editor.org/info/rfc5844>.		<http://www.rfc-editor.org/info/rfc5844>.
	[RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung,		[RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung,
	"Generic Routing Encapsulation (GRE) Key Option for Proxy		"Generic Routing Encapsulation (GRE) Key Option for Proxy
	Mobile IPv6", RFC 5845, DOI 10.17487/RFC5845, June 2010,		Mobile IPv6", RFC 5845, DOI 10.17487/RFC5845, June 2010,
	<http://www.rfc-editor.org/info/rfc5845>.		<http://www.rfc-editor.org/info/rfc5845>.
	skipping to change at page 12, line 45 ¶		skipping to change at page 13, line 9 ¶
	DOI 10.17487/RFC6088, January 2011,		DOI 10.17487/RFC6088, January 2011,
	<http://www.rfc-editor.org/info/rfc6088>.		<http://www.rfc-editor.org/info/rfc6088>.
	[RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G.,		[RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G.,
	and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and		and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and
	Network Mobility (NEMO) Basic Support", RFC 6089,		Network Mobility (NEMO) Basic Support", RFC 6089,
	DOI 10.17487/RFC6089, January 2011,		DOI 10.17487/RFC6089, January 2011,
	<http://www.rfc-editor.org/info/rfc6089>.		<http://www.rfc-editor.org/info/rfc6089>.
	[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility		[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
	Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July		Support in IPv6", RFC 6275, DOI 10.17487/RFC6275,
	2011, <http://www.rfc-editor.org/info/rfc6275>.		July 2011, <http://www.rfc-editor.org/info/rfc6275>.
	[RFC7148] Zhou, X., Korhonen, J., Williams, C., Gundavelli, S., and		[RFC7148] Zhou, X., Korhonen, J., Williams, C., Gundavelli, S., and
	CJ. Bernardos, "Prefix Delegation Support for Proxy Mobile		CJ. Bernardos, "Prefix Delegation Support for Proxy Mobile
	IPv6", RFC 7148, DOI 10.17487/RFC7148, March 2014,		IPv6", RFC 7148, DOI 10.17487/RFC7148, March 2014,
	<http://www.rfc-editor.org/info/rfc7148>.		<http://www.rfc-editor.org/info/rfc7148>.
	8.2. Informative References		8.2. Informative References
	[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in		[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
	IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,		IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
	December 1998, <http://www.rfc-editor.org/info/rfc2473>.		December 1998, <http://www.rfc-editor.org/info/rfc2473>.
	[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms		[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
	for IPv6 Hosts and Routers", RFC 4213,		for IPv6 Hosts and Routers", RFC 4213, DOI 10.17487/
	DOI 10.17487/RFC4213, October 2005,		RFC4213, October 2005,
	<http://www.rfc-editor.org/info/rfc4213>.		<http://www.rfc-editor.org/info/rfc4213>.
	[RFC4908] Nagami, K., Uda, S., Ogashiwa, N., Esaki, H., Wakikawa,		[RFC4908] Nagami, K., Uda, S., Ogashiwa, N., Esaki, H., Wakikawa,
	R., and H. Ohnishi, "Multi-homing for small scale fixed		R., and H. Ohnishi, "Multi-homing for small scale fixed
	network Using Mobile IP and NEMO", RFC 4908,		network Using Mobile IP and NEMO", RFC 4908, DOI 10.17487/
	DOI 10.17487/RFC4908, June 2007,		RFC4908, June 2007,
	<http://www.rfc-editor.org/info/rfc4908>.		<http://www.rfc-editor.org/info/rfc4908>.
	Authors' Addresses		Authors' Addresses
	Pierrick Seite		Pierrick Seite
	Orange		Orange
	4, rue du Clos Courtel, BP 91226		4, rue du Clos Courtel, BP 91226
	Cesson-Sevigne 35512		Cesson-Sevigne 35512
	France		France
	Email: pierrick.seite@orange.com		Email: pierrick.seite@orange.com
	Alper Yegin		Alper Yegin
	Samsung		Actility
	Istanbul
	Turkey		Turkey
	Email: alper.yegin@partner.samsung.com		Email: alper.yegin@actility.com
	Sri Gundavelli		Sri Gundavelli
	Cisco		Cisco
	170 West Tasman Drive		170 West Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	Email: sgundave@cisco.com		Email: sgundave@cisco.com
End of changes. 20 change blocks.
	66 lines changed or deleted		67 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/